Grav CMS EUVD-2026-87765

Attacker must hold page-write permission on the Grav instance and be able to publish/edit page content; an administrator (or higher-privileged user) must subsequently view the malicious page for their session cookie to be captured (UI:P). In versions 2.0.19-2.0.24 this works against default configurations because security.twig_content.process_enabled defaults to true and Security::applyTwigContentDefault() enables process.twig on every page. In 2.0.0-2.0.18 and 1.7.x, exploitation additionally requires that content Twig has been explicitly enabled (non-default). The shared page-content cache (keyed only on page identity plus config checksum, with no session/user/request dimension and no bypass for authenticated visitors) is what lets the captured cookie be replayed by unauthenticated visitors. 1.7.x receives no fix.

This is a genuine, high-priority issue for exposed Grav installs, not a paper-tiger high-CVSS. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:P, VC:H/VI:H/VA:H, base 8.6) is credible: a low-privileged page-write user needs only network access and low attack complexity, and the sole limiting factor is that an administrator must eventually view the malicious page (UI:P). Crucially, since 2.0.19 security.twig_content.process_enabled defaults to true, so the exploit path is live on default configurations of the vulnerable 2.0.19-2.0.24 range - content Twig runs on every page with no operator action. There is no EPSS score, no CISA KEV listing, and no public POC provided, so exploitation status is: no public exploit identified at time of analysis - this reflects targeted/latent risk rather than confirmed mass exploitation. The one signal tension worth noting: CWE-200 (information disclosure) undersells the outcome, since captured admin session cookies enable full account takeover (integrity/availability impact), which is why the vendor rated VI:H/VA:H alongside VC:H. Net: real priority wherever untrusted contributors hold page-write and admins browse the front end; patch to 2.0.25.

A user with only page-write permission publishes a page containing Twig that calls the sandbox-allowlisted get_cookie() to read whatever cookie the current request carries. When an administrator next views that page, the server-side read (via filter_input(INPUT_COOKIE, ...), bypassing HttpOnly/Secure/SameSite) captures the admin's session identifier and the post-Twig output is stored in a page cache keyed only on page identity plus config checksum; the cached page then serves that admin session cookie to unauthenticated visitors, who replay it to authenticate as the administrator. No public POC is referenced.