CVE-2026-72826 is a privilege flaw in the Grav API plugin. The createApiKey function did not check that a new key's scopes were a subset of the caller's, so an empty scope list produced an unscoped super key. The record scores it 8.8, High. Upgrade getgrav/grav-plugin-api to 1.0.13.
What's affected
The record says the getgrav/grav-plugin-api Composer package is affected before 1.0.13. The GitHub advisory lists affected versions as 1.0.12 and earlier, with 1.0.13 as the patched release.
The advisories share one root cause. The plugin enforces its API key scope limits in a single place, inside a permission check that runs before the super user shortcut. Several controllers instead use a bare super user check that reads the account setting directly and never looks at the key's scopes. A least privilege key created on a super account therefore passes any of those bare checks and its scope limit is skipped. In this advisory the gap is in key creation. For a self target, createApiKey requires only the baseline api.access scope, and the new key's scopes come straight from the request body with no subset check. An empty scope list means full access, because the cap guard only runs when the list is not empty. On a super account, that gives a full uncapped super key from nothing more than the baseline scope. The record says this also enables chains such as configuration write leading to code execution.
The weakness class is CWE-266, incorrect privilege assignment.
How to check if you're exposed
Check the version of the Grav API plugin on every site.
composer show getgrav/grav-plugin-api
If you installed the plugin through the Grav package manager instead of Composer, read the version from the plugin's own files or the plugin list in the Grav admin. Any version up to 1.0.12 is affected. Then check whether you have issued scoped API keys. The advisory explains that the weakness depends on a key with limited scopes that was created on a super user account, or on an account that holds the api.users.write permission in its access list. If nobody uses API keys, your exposure is smaller, but upgrade anyway.
List the API keys on your super accounts and look for keys with an empty or very broad scope list that you did not create on purpose.
What to do now
- Upgrade getgrav/grav-plugin-api to 1.0.13 or later.
- Review every API key on super accounts, and delete any key with an empty scope list that you cannot explain.
- Create replacement keys with explicit narrow scopes after the upgrade.
- Rotate keys that were handed to third party tools or scripts.
- Check logs for calls to the key creation route from keys that should not need it.
- Limit who can reach the API at the network level while you patch.
Why it matters
The advisories share one root cause. The plugin enforces its API key scope limits in a single place, inside a permission check that runs before the super user shortcut. Several controllers instead use a bare super user check that reads the account setting directly and never looks at the key's scopes. A least privilege key created on a super account therefore passes any of those bare checks and its scope limit is skipped.
The detail here is a small design choice with large effect. Treating an empty scope list as unlimited is a risky default, because a request that says nothing gets everything. Secure designs treat missing input as no access, and require a caller to list what it needs.
The record scores this High under CVSS 3.1. The GitHub advisory also labels it High, while VulnCheck lists it as critical under CVSS 4.0 with a score of 9.3. If you use scoped API keys as a security control, read the VulnCheck rating as the more accurate one. No source reports exploitation in the wild, and the CVE is not in the CISA KEV catalog. The advisory also notes that an earlier fix, for CVE-2026-65897 and CVE-2026-65895, covered only four controllers, which shows that this class of mistake can recur when each controller carries its own check.
Quick check
Why does an empty scope list matter?
The cap check only runs when the list is not empty, so an empty list gives full access, according to the advisory.
Who can use this?
Someone holding a minimal scope API key on a super account, per the record.
Sources
Last reviewed: 18 October 2026.