CVE-2026-72830 is an authorization flaw in the Grav API plugin. A key limited to configuration writes could still write scheduler jobs, which the system runs as operating system commands. The record scores it 8.8, High. Upgrade getgrav/grav-plugin-api to version 1.0.13 or later.
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. The config controller applies the scope cap only for api.config.write. Later gates for the scheduler and backups scopes, and for system, security and plugin settings, use a bare super user check. A key scoped to api.config.write on a super account passes them, and can write scheduler.custom_jobs command entries. The scheduler hands those commands to a Symfony Process, so they run as the web server user.
The weakness class is CWE-269, improper privilege management.
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.
Then look at the scheduler configuration for jobs you did not create.
grep -A10 'custom_jobs' user/config/scheduler.yaml
Any command in that list should be one that you can explain.
What to do now
- Upgrade getgrav/grav-plugin-api to 1.0.13 or later.
- Inspect scheduler.custom_jobs and remove any job you did not add.
- Review config files for unexpected changes, including security and plugin settings.
- Delete unused API keys and keep scopes narrow on the rest.
- Run the web server as a low privilege user and limit its write access.
- If you find an unknown job, treat the host as compromised and follow your incident process.
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.
This one shows how a limited key turns into command execution. Configuration write sounds like a content level right, but in a system with a job scheduler, config is code. Anything that lets a caller write a command string that a scheduler later runs is a path to the operating system.
The sources differ on rating. The record scores it 8.8 High under CVSS 3.1. The GitHub advisory labels it High, and VulnCheck labels it critical but scores it 8.7 under CVSS 4.0, which is the lowest of the five Grav items. All of them agree that fixing the plugin is the main step. 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.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Where do the injected commands run?
The advisory says the scheduler passes custom job commands to a Symfony Process, so they run as the web server user.
How do I look for signs of abuse?
Inspect scheduler.custom_jobs for entries you did not create, and review recent configuration changes.
Sources
Last reviewed: 18 October 2026.
