Vaadin Framework CVE-2026-110803

Requires a target running Vaadin Framework 8 in the vulnerable range (com.vaadin:vaadin-server 8.16.0-8.32.1, or vaadin-server-mpr-jakarta 8.18.0-8.32.1) reachable over HTTP. The only prerequisite is a valid session cookie, which any unauthenticated client obtains from a single initial request; no login, privileges, or user interaction are needed. Exploitation is strictly limited to Framework 8 - Vaadin Framework 7 and Vaadin 10+/Flow are not affected because Flow releases the lock in a finally block and does not read v-uiId there. The practical limiting factor is therefore product version: only Vaadin 8 deployments in the stated range are at risk.

This is a network-reachable, unauthenticated denial-of-service flaw (CWE-667, improper lock release) in Vaadin Framework 8. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) with pure availability impact (VA:H, VC:N/VI:N/VA only) is internally consistent with the description: a single non-numeric v-uiId parameter leaks the session lock, and repetition exhausts the container thread pool. The 8.7 score is availability-only - there is no confidentiality or integrity exposure, so despite the 'High' rating this is strictly an uptime/resilience risk, not data compromise. No EPSS score, CISA KEV listing, or public POC is present in the input, so exploitation likelihood signals are absent; no public exploit identified at time of analysis. The low attack complexity and lack of authentication make weaponization trivial if an actor targets a known-vulnerable Vaadin 8 deployment, but real-world urgency is tempered by the framework's moderate footprint and the DoS-only (recoverable) impact. Note the input Tag 'Information Disclosure' directly contradicts the CVSS vector (VC:N) and the description - this is an availability/DoS issue, not disclosure; treat that tag as erroneous.

An attacker makes one ordinary request to obtain a session cookie, then replays requests carrying that cookie with a non-numeric v-uiId value (e.g. v-uiId=abc). Each such request triggers an Integer.parseInt exception in VaadinService.requestEnd() while the session lock is held, permanently leaking the lock; the session then blocks forever and repeated requests tie up container threads until the thread pool is exhausted and the application stops serving. No authentication and no user interaction are required (AV:N/AC:L/PR:N/UI:N); no public exploit identified at time of analysis.