EasyAdmin EUVD-2026-77677

Exploitation requires three concrete conditions all being true: (1) the application uses EasyAdmin's FileField or ImageField and the developer has configured the upload directory inside the public web root (the documented example configuration), so files are served inline from the backend origin; (2) an attacker holds an account with permission to submit a form containing one of these upload fields; and (3) a privilege gap exists - a more-privileged administrator later opens the uploaded file. The attack is limited by the CVSS UI:R requirement (a victim admin must actively click/open the malicious .html or .svg file - it does not fire automatically) and by PR:L (the attacker must be an authenticated form-using user, not anonymous). It is further bounded to stored XSS only: it cannot yield RCE because Symfony's guessExtension() never produces .php/.phtml. Deployments that store uploads outside the web root or serve them with Content-Disposition: attachment are not exploitable.

The vendor CVSS 3.1 score is 7.6 (High) with vector AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:L/A:N - network vector, low attacker privileges, but requiring user interaction (an admin opening the file) and a scope change (script runs in the victim admin's context). Real-world risk is materially lower than the raw score suggests because exploitation is gated by two conditions the CVSS AC:L rating arguably understates: the developer must store uploads inside the public web root, and there must be a privilege gap between the uploading user and the viewing administrator - I would rate attack complexity as High for this reason. No EPSS score, POC, or KEV entry was provided, so there is no evidence of active or automated exploitation; this is a targeted, interaction-dependent stored XSS rather than a mass-exploitable flaw. It is a genuine priority for multi-tenant or public-facing EasyAdmin deployments where untrusted users can upload files, but low priority for single-trusted-admin installations or those already storing uploads outside the web root.

A low-privileged content editor uploads a malicious file named report.html (via FileField) or logo.svg (via ImageField) containing JavaScript that reads the admin session cookie or CSRF token. When a higher-privileged administrator later clicks the inline link to view that upload, the file is served same-origin as a top-level document and the script runs in the admin's authenticated session, exfiltrating tokens or performing privileged actions on their behalf. No public exploit code was identified, and success depends on the admin opening the file.