Grav CMS CVE-2026-64850

Exploitation requires an authenticated Grav CMS account holding either the admin.pages or api.pages.write permission - these are the specific permission strings that gate access to page frontmatter editing. The attacker must be able to create or modify page content including YAML frontmatter. The embedded command is not executed at write time; it fires when the page is rendered, meaning a separate HTTP request to the page URL is required to trigger execution (the attacker can make this request themselves, so victim interaction is not strictly required). Unauthenticated exploitation is not possible: Grav does not expose page editing to anonymous users by default. The privilege bar is the primary limiting factor - deployments where admin.pages or api.pages.write is restricted to a small set of fully trusted internal accounts are substantially less exposed than those where it is granted broadly.

The CVSS 4.0 score of 8.7 (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H) accurately captures the threat profile: network-reachable, low exploitation complexity, requiring only a low-privilege page-editor account, with full confidentiality, integrity, and availability impact on the vulnerable system. The PR:L requirement is the single critical limiting factor - this is not an unauthenticated pre-auth exploit. No EPSS data is present in the provided intelligence; exploitation probability cannot be quantified from available signals. The vulnerability is not listed in CISA KEV and no standalone POC exploit code has been identified, though the attack technique is comprehensively described in the GitHub advisory, lowering the barrier for any motivated actor who already holds a page-editor account. Real-world risk is strongly tied to how broadly page-editing permissions are granted: organizations that issue admin.pages or api.pages.write to external contributors, freelancers, or automated integrations face substantially elevated exposure. The absence of KEV listing and the authenticated prerequisite argue against treating this as a mass-exploitation crisis, but the full RCE impact and a clearly documented attack chain make patching to 2.0.7 a genuine priority for any Grav deployment where editor accounts are not exclusively held by fully trusted internal staff.

A Grav contributor account with admin.pages permission edits a page and embeds a malicious data-options@ blueprint directive in the YAML frontmatter, specifying Grav\Common\Utils::arrayFilterRecursive as the provider and system as a callable argument carrying an OS command such as a reverse-shell one-liner. When any subsequent HTTP request causes Grav to render that page - whether by the attacker themselves, an authenticated user, or an automated crawler - Blueprint::dynamicData() invokes call_user_func_array() with the trampoline chain intact, executing the command as the web server user (e.g., www-data). No standalone POC exploit code is publicly identified beyond the advisory's detailed technique description.