CVE-2026-100671: Grav before 2.0.25 Session Cookie Theft via Twig Sandbox
Grav is a flat-file CMS. In versions 2.0.19 through 2.0.24 — and in 2.0.0 through 2.0.18 and 1.7.x only where content Twig has been explicitly enabled — page content authored by a user holding only page-write permission is rendered through a Twig sandbox that allowlists getcookie(), which returns any cookie sent with the current request, including the visitor's session cookie. Because the read occurs server-side via filterinput(INPUTCOOKIE, ...), the HttpOnly, Secure and SameSite attributes offer no protection. Grav then stores the finished post-Twig output in a page-content cache keyed only on page identity and the configuration checksum, with no session, user or request dimension and no bypass for authenticated visitors. A page published by a page-write user can therefore capture the session identifier of the next administrator who views it, after which the cached output serves that identifier to unauthenticated visitors, who can replay the cookie to authenticate as that administrator. Since 2.0.19, security.twigcontent.processenabled defaults to true and Security::applyTwigContentDefault() derives each page's process.twig flag from that gate, so content Twig runs on every page with no frontmatter or operator action. Fixed in 2.0.25; 1.7.x is outside the backport scope.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Gravto a version that resolves this vulnerability.Fixed in 2.0.25
Event History
Frequently Asked Questions
Which deployments are most likely exposed by default?
Grav 2.0.19 through 2.0.24 are affected because content Twig processing defaults to enabled in those releases. Earlier 2.0.x releases and 1.7.x are affected only when content Twig has been explicitly enabled.
What access and user interaction does an attacker need?
An attacker needs only page-write permission to publish crafted page content. They must wait for an administrator to view that page; the administrator's session identifier can then be exposed through the cached page output.
Do HttpOnly, Secure, or SameSite cookie settings prevent this attack?
No. The cookie is read server-side through filter_input(INPUT_COOKIE, ...), so browser-enforced cookie attributes do not prevent the value from being included in rendered content and cached.
Why can unauthenticated users become involved after an administrator views the page?
The page-content cache is keyed only by page identity and configuration checksum, without a session, user, or request dimension. Once the administrator's cookie is captured in cached output, unauthenticated visitors can receive it and replay it as the administrator.
What is the available fixed release?
The affected range is described as Grav versions before 2.0.25. Upgrading to 2.0.25 or later removes exposure to this issue.