Grav CMS EUVD-2026-46183

Exploitation requires an authenticated account possessing the Grav admin.pages permission or the api.pages.write permission to inject a malicious 'Class::method' callable directive into a page's frontmatter; this privileged write is the essential prerequisite and the primary limiting factor. Once planted, execution requires only that the affected page be accessed - this second step needs no authentication and can be triggered by any visitor or by the attacker directly, with no user interaction beyond a normal page load. The exploit is confirmed against Grav 2.0.4; deployments that restrict page-write permissions to a single trusted administrator sharply limit who can stage the attack.

The vendor-assigned CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H, base 9.3) rates this as critical and unauthenticated, but that PR:N reflects only the trigger stage - an unauthenticated visitor rendering the poisoned page - not the injection stage, which requires an authenticated account with the admin.pages or api.pages.write permission. In practice this is a two-stage flaw: a privileged authenticated write plants the payload, then unauthenticated execution occurs on access. That materially lowers real-world exploitability versus a pure pre-auth RCE, so treating it strictly as PR:N overstates ease of initial compromise; my independent assessment uses PR:H to reflect the required elevated content-management privilege. Impact is nonetheless full compromise of the web-server context (C/I/A all High). No EPSS score, SSVC decision, KEV listing, or public POC was provided, so exploitation-probability signals are absent - prioritize on the trust model: if untrusted or low-trust users can obtain page-write permissions this is high priority, whereas single-trusted-admin deployments carry lower practical risk.

An attacker with a low-trust editor account (holding admin.pages or api.pages.write) creates or edits a page and embeds a malicious Class::method callable and arguments in the frontmatter. The next time anyone loads that page - the attacker themselves or an unauthenticated site visitor - Blueprint::dynamicData() invokes the callable via call_user_func_array(), executing the attacker's command as the web-server user. No public POC was provided, but the low attack complexity and simple call_user_func_array() sink make exploitation straightforward once page-write access is obtained.