Grav CMS CVE-2025-66297

Requires an authenticated Grav account with admin panel access and page create/edit permission (admin.pages), such as a publisher or editor role - it is NOT exploitable by anonymous/unauthenticated users. The attacker must be able to enable Twig processing on a page (Advanced -> Process: Twig: true), which is not the default page setting but can be toggled by the page editor themselves. Because the Twig sandbox is not enforced in the page-render context, injected expressions gain full access to backend PHP objects under system/src/Grav/Common, enabling grav.user.update()/save() for privilege escalation and grav.scheduler.addCommand()/save()/run() for RCE. Limiting factor: the editor role must be a real trust boundary in the deployment; on single-admin installs the impact is negligible. For the privilege-escalation path specifically, the attacker must also be logged into the front-end site with the same account.

This is a genuine but access-gated risk. The official CVSS 4.0 vector (AV:N/AC:L/PR:L/UI:N/VC:H/VI:H/VA:H, base 7.4) and the GitHub advisory both confirm exploitation requires an authenticated Grav user who already holds admin panel access with page create/edit rights (admin.pages) - so this is NOT unauthenticated internet-wide RCE. The E:P flag in the vector aligns with the input signal that a full PoC is publicly available (GHSA-858q-77wx-hhx6 contains working privesc and RCE payloads), which raises operational risk for any environment where low-trust editors/publishers exist. EPSS is modest at 0.40% (60th percentile), and there is NO CISA KEV listing, indicating no confirmed mass exploitation - consistent with a vuln that requires prior authenticated foothold rather than one favored by opportunistic scanners. Net: real priority for multi-user Grav deployments that delegate page-editing to semi-trusted users (the flaw lets such a user become super admin and run OS commands), but lower urgency for single-admin installs where the editor already effectively controls the site. The signals are internally consistent - no conflicts to flag - the main caveat is that impact assumes the editor role is a meaningful trust boundary in the target deployment.

A publisher/editor with page-editing rights but no admin privileges logs into the Grav admin panel, creates or edits a page, and enables Twig processing (process: twig: true) in the frontmatter. They inject Twig calling grav.user.update()/save() to flip their own account to super admin, or grav.scheduler.addCommand()/save()/run() to execute arbitrary OS commands, then simply visit the page to trigger rendering. A public PoC with both payloads exists in the GitHub Security Advisory.