Description

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 get_cookie(), which returns any cookie sent with the current request, including the visitor's session cookie. Because the read occurs server-side via filter_input(INPUT_COOKIE, ...), 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.twig_content.process_enabled 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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.0",
  "pubDate": "2026-09-26T14:16:50.743Z",
  "pubdate": "2026-09-26T14:16:50.743Z",
  "executiveSummary": "Grav CMS is vulnerable to a critical session hijacking vulnerability stemming from improper Twig sandboxing configurations. The flaw allows users with restricted 'page-write' permissions to execute arbitrary Twig template logic that leverages the 'get_cookie()' function to extract sensitive session identifiers. Because Grav caches the rendered output of these pages globally—without account-specific scoping—an attacker can induce the server to capture an administrator's session cookie and broadcast it to unauthenticated users via the shared page cache.\nThe vulnerability affects Grav versions 2.0.19 through 2.0.24, as well as versions 2.0.0 through 2.0.18 and 1.7.x when content Twig is explicitly enabled. The security implications are severe, as an attacker with limited privileges can effectively achieve full administrative account takeover. Exploitation is facilitated by the default enabling of 'security.twig_content.process_enabled' in modern versions, which applies Twig processing to page content automatically. The vulnerability is fixed in version 2.0.25; however, 1.7.x versions are considered end-of-life and will not receive backported security updates.",
  "technicalDetails": "The root cause of this vulnerability lies in the combination of an overly permissive Twig sandbox allowlist and the implementation of a globally scoped page-content cache. Within the Grav Twig environment, the 'get_cookie()' function is explicitly permitted, allowing Twig templates to access raw cookie data associated with the current HTTP request. Because this operation is performed server-side via 'filter_input(INPUT_COOKIE, ...)', the access is completely independent of client-side security headers such as 'HttpOnly', 'Secure', or 'SameSite'.\nThe attack flow begins when an attacker with 'page-write' permissions submits a page containing a crafted Twig payload designed to invoke 'get_cookie()' for the application's session identifier. When an administrator subsequently views this page, the server-side Twig engine executes the malicious code, retrieves the administrator’s active session cookie, and embeds it into the rendered HTML content of the page.\nCrucially, Grav stores the resulting rendered output in a system-wide cache. This cache mechanism is keyed only against the page identity and a configuration checksum; it lacks any awareness of the requesting user's session or authentication state. Once the page is rendered for the administrator, the malicious content—now containing the captured session cookie—is persisted in the cache. Subsequent requests for this page from any unauthenticated visitor will receive the cached response containing the administrator's stolen session token.\nThe attack impact is a full authentication bypass. An unauthenticated attacker can replay the exfiltrated cookie to impersonate the administrator, gaining full control over the CMS instance. The scope of the vulnerability is expanded by the configuration of 'security.twig_content.process_enabled', which, as of version 2.0.19, defaults to 'true'. By defaulting this to enabled, Grav automatically triggers Twig processing on pages, removing the need for explicit frontmatter configuration by the attacker. This ensures that even pages not intended to use dynamic Twig logic become viable vectors for this exploit.\nThe vulnerability is fully remediated in version 2.0.25, which presumably restricts access to sensitive functions within the sandbox or alters the caching mechanism to prevent the storage of user-specific session data. Versions in the 1.7.x branch remain inherently vulnerable as they fall outside the security backport scope."
}