Grav CMS CVE-2026-42609

Exploitation requires the attacker to hold a valid Grav CMS account with the admin.users.create permission explicitly granted. This permission is not assigned to normal users by default; a super-admin must have previously delegated user-creation rights to the attacker's role. Attack targets Grav installations where permission delegation follows a multi-tier model (e.g., junior admins can create users but lack super-admin rights). Default single-admin deployments where only the root account holds admin.users.create are not exploitable unless the admin has manually created and misconfigured lower-privilege accounts. The vulnerability affects all Flex storage backends (file, database, custom FlexStorageInterface implementations) in vulnerable versions. Attack vector is network-accessible admin panel (AV:N) with low complexity (AC:L)-no race conditions, no cryptographic weaknesses, just a single POST request. No user interaction required beyond the attacker's own authenticated session (UI:N). Limiting factor: attacker must already be authenticated with a specific non-default permission grant, making this primarily an insider-threat or shared-hosting scenario rather than internet-wide exploitation risk.

CVSS 8.1 (High) reflects network attack vector, low complexity, low privileges required, and high integrity/availability impact with no confidentiality compromise. EPSS score not provided in input data. No CISA KEV listing, but a working video PoC is published in the vendor's own security advisory (GHSA-rr73-568v-28f8), meaning exploit code is publicly available. Real-world risk depends heavily on deployment configuration: only Grav installations that delegate admin.users.create permission to non-admin roles are exploitable-environments following least-privilege best practices (not granting user-creation rights to low-privilege accounts) are immune. Attack complexity is low (single HTTP POST to admin panel), but the attacker must already hold valid credentials and the specific admin.users.create permission, limiting the attack surface. The impact is severe where exploitable: complete administrative lockout constitutes availability impact (DoS) and integrity impact (unauthorized permission modification). SSVC framework: exploitation is publicly available (PoC confirmed), automatable (simple HTTP request), technical impact is total (admin lockout), but preconditions are non-default (requires misconfigured permission delegation). This is a real priority for multi-tenant Grav installations or shared hosting where non-admin users have create-user rights, but lower risk for single-admin deployments. No conflicting data across sources-GitHub advisory, commit messages, and CVE description align.

An authenticated low-privilege user with admin.users.create permission (e.g., a junior editor in a multi-tenant CMS) logs into the Grav Admin Panel and navigates to User Accounts → Add. They fill the username field with 'root0' (the super-admin's username) and arbitrary values for email/fullname, then click Save. The vulnerable create-or-update logic overwrites /user/accounts/root0.yaml with the attacker's low-privilege permission set, replacing the super-admin's access grants. The legitimate administrator is locked out on next login, unable to access admin functions or restore the account without filesystem-level intervention. The attacker gains no elevated privileges themselves (cannot assign admin.super to their input due to existing permission-escalation guards) but achieves denial-of-service and effectively disables platform governance. Video PoC demonstrates full attack chain from login to admin lockout (https://github.com/user-attachments/assets/047cb44e-0279-402b-b4fb-12bf5d427a5e).