Vaadin Flow EUVD-2026-120893

Requires an application that passes an attacker-influenced, untrusted file name to DownloadEvent.setFileName(String) or (from Vaadin 25.0) inline(String) - the canonical case being re-serving a file under the original name it was uploaded with. The crafted name must be pure US-ASCII and contain a double quote to break out of filename="..." and append an attacker-controlled filename* parameter. Limiting factors: the attacker cannot change the attachment/inline disposition and cannot split the header (no CRLF injection); a victim must actively trigger the download (UI:A); the attacker needs a path to inject the file name (PR:L); and only Vaadin 24.8 and later are affected (the DownloadEvent API does not exist below 24.8, and inline() is affected only from 25.0). Applications that do not feed untrusted names to these methods are not exploitable.

This is a genuine but modest-severity output-encoding flaw (CWE-116), not a high-priority emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:A/VC:N/VI:N/VA:N/SC:N/SI:L/SA:N, score 4.8/Medium) tells a consistent story: network-reachable and low-complexity, but it requires some privilege (PR:L - the attacker must get an untrusted file name into the system), active user interaction (UI:A - a victim must actually download the file), and the only impact is low integrity on the downloading user's system (SI:L), with no confidentiality (VC:N) or availability impact. No EPSS score, KEV listing, or SSVC automatable flag was supplied; absence of these is not evidence of safety but does mean there is no signal of mass exploitation. The vuln.today decision label is 'this_month' (not act_now/emergency), aligning with the medium rating. Crucially, exploitation is gated on an application-side coding pattern (passing an untrusted file name to DownloadEvent.setFileName/inline), so this is not exploitable against a default Vaadin install - it depends on how the application uses the API. Note the input 'Information Disclosure' tag conflicts with the CVSS VC:N (no confidentiality impact); the real impact is file-name/extension spoofing (integrity), so that tag appears mislabeled. Treat this as a scheduled-patch item, not a drop-everything issue.

An attacker uploads (or otherwise supplies) a file whose name contains a double quote plus an injected filename* parameter, e.g. a name that closes the quoted filename early and appends filename*=UTF-8''evil.exe. When a victim later downloads that file through an application that re-serves it under its stored name via the vulnerable DownloadEvent method, the browser prefers the attacker-controlled filename* and saves the file under a name and extension of the attacker's choosing, defeating the application's extension restrictions. No public exploit identified at time of analysis; the only linked code is the vendor fix PR.