CVE-2026-42609

A business logic vulnerability in the Grav Admin Panel allows a low-privileged user (with only user creation permissions) to overwrite existing accounts, including the primary administrator. By creating a new user with a username that already exists, the system updates the existing account's metadata and permissions instead of rejecting the request. This leads to a Denial of Service (DoS) on administrative functions and Privilege De-escalation of the root account.

Details

The vulnerability stems from an insecure "Create or Update" logic within the user management module. When the admin-addon handles a user creation request, it does not strictly validate whether the username is already taken by a higher-privileged account. Instead of returning a "409 Conflict" or a validation error, the application logic proceeds to overwrite the existing user configuration file (e.g., user/accounts/root0.yaml) with the new, lower-privileged data provided by the attacker.
Because the attacker cannot assign higher permissions to themselves (due to existing fixes), the result is that the targeted account (the original Admin/Root) has its access levels wiped or replaced by the attacker's input, effectively locking the real administrator out of the system.

PoC

1. Log in as a Super User (e.g., root0) and create a low-privileged user (e.g., adminuser).
2. Assign adminuser the following specific permissions:
   admin.login
   admin.users.list
   admin.users.read
   admin.users.create
3. Log out and log back in as adminuser.
4. Navigate to User Accounts -> Add.
5. Fill in the form with the following details:
   Username: root0 (The exact username of the Super User)
   Email: [email protected]
   Fullname: Fake Root0
6. Click Save.
7. Observe that the account is successfully "created".
8. The original administrative permissions are gone, and the account is now restricted.

PoC video

https://github.com/user-attachments/assets/047cb44e-0279-402b-b4fb-12bf5d427a5e

Maintainer note, fix applied (2026-04-24)

Fixed in Grav core on the 2.0 branch: commit d904efc33, will ship in 2.0.0-beta.2.

What changed: UserObject::save already had a uniqueness guard (commit 19c2f8da7, November 2025) that blocks the PoC. This release tightens that guard:

1. strpos($key, '@@') → str_contains($key, '@@'). The previous form was falsy when the transient-key marker was at position 0 (e.g. @@hash), silently bypassing the check. str_contains returns a proper boolean.
2. The instanceof FileStorage gate was dropped so the uniqueness check runs for any FlexStorageInterface backend, not just the default file-per-user YAML one.

A low-privileged user with admin.users.create can no longer disrupt a super-admin account by submitting that admin's username through the "add user" form.

Files:

• system/src/Grav/Common/Flex/Types/Users/UserObject.php.
• tests/unit/Grav/Common/Security/UserOverwriteSecurityTest.php, 3 tests pinning the PoC, the @@-prefix edge case, and pass-through for free usernames.

This is a Privilege De-escalation and Account Disruption vulnerability.
Who is impacted: Any Grav installation where a non-admin user is granted permission to create other users.
Consequence: An attacker can effectively disable all administrative accounts on the platform, leading to a complete loss of management control over the CMS.

The application assigns, modifies, tracks, or checks privileges incorrectly, allowing a user to gain elevated access. Typical impact: privilege escalation beyond the intended level.

CVE-2026-42609 has a CVSS score of 8.1 (High). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (2.0.0-beta.2); upgrading removes the vulnerable code path.

Kodem intelligence

1. What is CVE-2026-42609? CVE-2026-42609 is a high-severity improper privilege management vulnerability in getgrav/grav (composer), affecting versions < 2.0.0-beta.2. It is fixed in 2.0.0-beta.2. The application assigns, modifies, tracks, or checks privileges incorrectly, allowing a user to gain elevated access.
2. How severe is CVE-2026-42609? CVE-2026-42609 has a CVSS score of 8.1 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of getgrav/grav are affected by CVE-2026-42609? getgrav/grav (composer) versions < 2.0.0-beta.2 is affected.
4. Is there a fix for CVE-2026-42609? Yes. CVE-2026-42609 is fixed in 2.0.0-beta.2. Upgrade to this version or later.
5. Is CVE-2026-42609 exploitable, and should I be worried? Whether CVE-2026-42609 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether CVE-2026-42609 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix CVE-2026-42609? Upgrade getgrav/grav to 2.0.0-beta.2 or later.