Grav API Plugin CVE-2026-42843
HIGHSeverity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Primary rating from GitHub Advisory · only source for this CVE.
CVSS VectorGitHub Advisory
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Lifecycle Timeline
2DescriptionGitHub Advisory
Summary
An insecure direct object reference and logic flaw in the Grav API plugin (UsersController::update) allows any authenticated user with basic API access (api.access) to modify their own permission configuration. An attacker can exploit this to escalate their privileges to Super Administrator (admin.super and api.super), leading to full system compromise and potential RCE.
Details
The vulnerability is located in user/plugins/api/classes/Api/Controllers/UsersController.php within the update method.
The API allows users to update their own profiles if they possess the basic api.access permission:
// UsersController.php -> update()
$isSelf = $currentUser->username === $username;
if (!$isSelf) {
$this->requirePermission($request, 'api.users.write');
} else {
// Self-edit only requires api.access
$this->requirePermission($request, 'api.access');
}However, when filtering the fields that are allowed to be updated via a PATCH request, the access field (which defines the user's role and permissions) is indiscriminately included in the $allowedFields whitelist for all users:
// Partial update - only update provided fields
$allowedFields = ['email', 'fullname', 'title', 'state', 'language', 'content_editor', 'access', 'twofa_enabled'];
foreach ($allowedFields as $field) {
if (array_key_exists($field, $body)) {
$user->set($field, $body[$field]);
}
}Because there is no secondary check to verify if the user attempting to modify the access field is already an administrator, any low-privileged user can overwrite their own access object with a malicious payload granting themselves super: true.
PoC
- Prerequisites: You need a low-privileged user account (eg.
user1) that possesses the basicapi.accesspermission. - Obtain JWT: Authenticate to the API to obtain your
access_token:
curl -X POST http://<target>/api/v1/auth/token \
-H "Content-Type: application/json" \
-d '{"username":"user1","password":"your_password"}'- Exploit: Send a
PATCHrequest to the user update endpoint.
curl -X PATCH http://<target>/api/v1/users/user1 \
-H "X-API-Token: <your_access_token>" \
-H "Content-Type: application/json" \
-d "{\"access\":{\"admin\":{\"login\":true,\"super\":true},\"api\":{\"access\":true,\"super\":true},\"site\":{\"login\":true}}}"- Verification: Log in to the Grav Admin panel using the user credentials. You will now have full Super Administrator privileges.
Impact
This is a vertical Privilege Escalation vulnerability. Any user with baseline API access can elevate themselves to Super Admin. Once Super Admin privileges are obtained, the attacker takes complete control over the CMS. They can modify content, alter configurations, upload malicious plugins, or edit Twig templates outside of the sandbox to achieve RCE on the server.
AnalysisAI
Privilege escalation in Grav API Plugin (versions < 1.0.0-beta.15) allows any authenticated user with basic 'api.access' permission to elevate themselves to Super Administrator by sending a crafted PATCH request to modify their own permission configuration. The vulnerability, confirmed by vendor GitHub Security Advisory GHSA-r945-h4vm-h736, stems from inadequate authorization checks in the UsersController::update method, which permits self-editing users to overwrite the 'access' field containing role definitions. Successful exploitation grants complete CMS control including the ability to edit Twig templates outside sandbox restrictions for remote code execution. A detailed proof-of-concept is publicly available, and vendor-released patch is confirmed in version 1.0.0-beta.15.
Technical ContextAI
The vulnerability resides in the Grav API Plugin's UsersController.php (PHP), specifically in the user profile update endpoint. The flaw combines an Insecure Direct Object Reference (IDOR) with broken authorization logic (CWE-863: Incorrect Authorization). The code correctly differentiates self-edit from admin-edit based on username comparison, requiring only 'api.access' permission for self-modification versus 'api.users.write' for editing other users. However, the $allowedFields whitelist unconditionally includes 'access' and 'state' fields for all PATCH operations, regardless of the requester's privilege level. The 'access' field is a nested object controlling user permissions including 'admin.super' and 'api.super' flags. By crafting a PATCH request with a malicious access payload, a low-privileged user can directly overwrite their own permission structure in the Grav user account system. The fix splits the field whitelist into self-editable fields (email, fullname, title, language, content_editor, twofa_enabled) and admin-only fields (state, access), explicitly rejecting PATCH attempts on privileged fields with HTTP 403 unless the requester holds 'api.users.write' or super-admin status.
RemediationAI
Upgrade the Grav API Plugin to version 1.0.0-beta.15 or later immediately, as confirmed by the vendor advisory at https://github.com/getgrav/grav/security/advisories/GHSA-r945-h4vm-h736 and the fixing commit at https://github.com/getgrav/grav-plugin-api/commit/26f529c7d438c73343e82311fb095caeaf1a6116. The patch implements authorization enforcement by splitting the field whitelist in UsersController::update into self-editable fields (email, fullname, title, language, content_editor, twofa_enabled) and admin-only fields (state, access), explicitly rejecting PATCH requests containing 'access' or 'state' fields from non-privileged users with HTTP 403 and error message 'Modifying [field] requires the api.users.write permission.' If immediate patching is not feasible, implement compensating controls with these trade-offs: (1) Disable the Grav API Plugin entirely via the Grav Admin Panel or by setting 'enabled: false' in user/config/plugins/api.yaml, which breaks all API functionality including legitimate integrations and headless CMS workflows. (2) Revoke 'api.access' permission from all non-administrative users via Admin Panel > Accounts, restricting API usage to super-admins only, which limits operational flexibility for content teams and developers requiring programmatic access. (3) Deploy a reverse proxy or web application firewall to inspect and block HTTP PATCH requests to paths matching /api/v1/users/* that contain 'access' or 'state' keys in the JSON body when the authenticated user lacks 'api.users.write' permission (requires custom rule development and testing to avoid blocking legitimate admin operations). All compensating controls degrade functionality and should be treated as temporary measures pending upgrade to 1.0.0-beta.15.
sapi/cgi/cgi_main.c in PHP before 5.3.12 and 5.4.x before 5.4.2, when configured as a CGI script (aka php-cgi), does not
(1) boardData102.php, (2) boardData103.php, (3) boardDataJP.php, (4) boardDataNA.php, and (5) boardDataWW.php in Netgear
ProjectSend versions prior to r1720 are affected by an improper authentication vulnerability. Rated critical severity (C
Roundcube Webmail contains a critical PHP object deserialization vulnerability (CVE-2025-49113, CVSS 9.9) that allows au
Util/PHP/eval-stdin.php in PHPUnit before 4.8.28 and 5.x before 5.6.3 allows remote attackers to execute arbitrary PHP c
Palo Alto Networks PAN-OS management web interface contains an authentication bypass allowing unauthenticated attackers
Nagios XI version xi-5.7.5 is affected by OS command injection. Rated high severity (CVSS 8.8), this vulnerability is re
Nagios XI version xi-5.7.5 is affected by OS command injection. Rated high severity (CVSS 8.8), this vulnerability is re
The get_referers function in /opt/ws/bin/sblistpack in Sophos Web Appliance before 3.7.9.1 and 3.8 before 3.8.1.1 allows
The Backup Migration plugin for WordPress is vulnerable to Remote Code Execution in all versions up to, and including, 1
NetAlertX (formerly PiAlert) versions 23.01.14 through 24.x before 24.10.12 allow unauthenticated command injection thro
The GiveWP - Donation Plugin and Fundraising Platform plugin for WordPress is vulnerable to PHP Object Injection in all
Same weakness CWE-863 – Incorrect Authorization
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today
GHSA-r945-h4vm-h736