Vaadin Spreadsheet EUVD-2026-89952

Exploitation requires: (1) an application built on an affected Vaadin/Vaadin-Spreadsheet version that actually renders a spreadsheet component to users; (2) the target sheet must have sheet protection enabled (the flaw is the failure to enforce that protection for the comment-write path); and (3) a valid authenticated session with the application (PR:L) - this is not remote-unauthenticated. There is no user-interaction requirement and complexity is low, but impact is confined to cell-comment integrity and phantom row/cell creation; no confidentiality or availability impact. Deployments that do not use the Spreadsheet component, do not enable sheet protection, or restrict spreadsheet access to trusted authenticated users face little practical risk.

This is a genuinely low-risk authorization flaw, and the multiple signals are consistent rather than conflicting. The vendor-assigned CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) requires an authenticated user (PR:L) and yields only a low integrity impact (VI:L) with no confidentiality (VC:N) or availability (VA:N) effect, giving a base score of 5.3 - which correctly reflects a limited-impact issue rather than a critical one. No EPSS score, no CISA KEV listing, and no public exploit code were provided; the GitHub links are the vendor's own fix pull requests (patch/test diffs), NOT weaponized proof-of-concept exploits, so they should not be read as evidence of exploitability in the wild. The realistic ceiling of this bug is that an already-authenticated application user can tamper with cell comments on a 'protected' sheet and cause phantom row/cell creation - a data-integrity nuisance, not data theft or code execution. This is a low-priority, patch-in-normal-cycle issue: the CVSS-to-real-risk relationship is honest here, with no inflation. The only mild caveat is that the tag labels this 'Authentication Bypass' when it is actually broken authorization (CWE-285) - no authentication step is defeated; a legitimately authenticated user simply exceeds their intended write permissions on protected cells.

An authenticated user of a Vaadin application that renders a spreadsheet with sheet protection enabled crafts or replays the client-side 'updateCellComment' RPC event targeting a locked cell (or an empty cell). The server-side handler applies the comment without checking the cell's locked/editable state, so the attacker adds or overwrites comments on protected cells and can even materialize new rows/cells that did not previously exist. No public exploit code is available; the referenced GitHub pull requests are the vendor's remediation, and exploitation requires an authenticated session (PR:L) but no user interaction or special complexity.