CVE-2026-72824 is an authorization flaw in the Grav API plugin. A key limited to page writes could still switch on Twig processing for a page, which allows server-side template injection and code execution. 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. Here the affected check is guardTwigContent in the pages controller. The admin.pages_twig permission is deliberately kept outside the api.pages scope, so a key that can write pages should not be able to turn Twig on. A bare super user check gave it back to any scoped key on a super account.
The record adds a condition. The attack works when security.twig_content.process_enabled is true and editor_enabled is false, so that Twig in content runs on the server.
The weakness class is CWE-862, missing authorization.
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.
Also read your Grav security settings.
grep -A4 'twig_content' user/config/security.yaml
If process_enabled is true and editor_enabled is false, you match the condition in the record.
What to do now
- Upgrade getgrav/grav-plugin-api to 1.0.13 or later.
- Review security.twig_content settings, and turn off process_enabled if you do not need Twig in page content.
- Audit API keys, delete unused ones, and keep scopes narrow on the rest.
- Search page content for unexpected Twig expressions or process.twig flags that you did not set.
- Check the web server user's permissions so that template code cannot reach secrets or write to the web root.
- Review recent page saves made through the API.
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.
Server-side template injection turns page text into running code. Grav keeps that power behind a separate permission for good reason. When a scope limit is meant to withhold it and a shortcut grants it back, a content writer becomes a code runner.
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
What setting combination does the record name?
security.twig_content.process_enabled set to true and editor_enabled set to false.
Which permission is meant to stop this?
admin.pages_twig, which sits outside the api.pages scope so a page write key should not hold it.
Sources
Last reviewed: 18 October 2026.
