grav-plugin-api CVE-2026-75829

Exploitation requires the attacker to hold a valid credential or API token with the api.pages.write permission in the grav-plugin-api. This is the hard prerequisite - unauthenticated actors cannot exploit this vulnerability. Additionally, the malicious page must be rendered after persistence (either by the attacker triggering a request or by waiting for a victim or crawler to load it), and the page must have the process.twig flag enabled, which the attacker can set during the write operation if the API permits it. Exploitation is limited to Grav installations running grav-plugin-api below 1.0.15 and is not applicable to Grav core without the API plugin. There is no required user interaction beyond the initial write and a subsequent page render. The attack is network-accessible and requires no special timing or race conditions (AT:N). The key limiting factor is the api.pages.write permission gate: deployments that restrict this permission to trusted administrators significantly reduce realistic exploitation risk despite the high CVSS score.

The CVSS 4.0 score of 8.6 (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N) reflects a realistic threat model: network-accessible, no attack complexity or timing requirements, but gated behind PR:L because the api.pages.write permission is required. This permission gate is the primary real-world risk moderator - exploitation is limited to users or API tokens that have been granted write access to the Grav API. Deployments that restrict this permission to trusted administrators carry materially lower risk than those where it is granted to contributors or third-party integrations. No EPSS data was provided, and no CISA KEV entry exists, indicating no confirmed active exploitation campaigns at analysis time. No proof-of-concept code has been identified. Despite the high CVSS score, this should be treated as a medium-urgency priority for most deployments: critical only when the api.pages.write permission is granted to semi-trusted or untrusted parties. The absence of an availability impact component (VA:N/SC:N) is notable - while SSTI-driven RCE typically implies full system compromise including availability, the provided vector does not score it, and no contradicting vendor data is available to override this.

An attacker with a valid API token scoped to api.pages.write submits a POST request to the translate() endpoint with a Twig payload such as {{['id']|map('system')|join}} embedded in the content or header parameters, persisting a page with process.twig: true. When any user or automated process subsequently requests the rendered page, the Twig engine evaluates the directive server-side, returning command output or facilitating further exploitation such as web shell deployment. No public proof-of-concept code has been identified, but the technique is well-understood for Twig SSTI and requires minimal attacker sophistication.