CVE-2026-100671 in Grav
Summary
by MITRE • 09/26/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/26/2026
The vulnerability identified involves a critical session hijacking flaw within Grav, a popular flat-file content management system. This issue affects versions ranging from 2.0.0 through 2.0.24, with specific conditions applying to earlier releases where Twig processing for page content was explicitly enabled via configuration or frontmatter directives. The core of the vulnerability lies in how user-authored page content is processed and cached when rendered using the Twig templating engine. Specifically, the implementation allows a Twig sandbox filter named get_cookie() which permits access to any cookie sent with an HTTP request. This includes sensitive session identifiers that are typically protected by security attributes such as HttpOnly, Secure, and SameSite because these protections operate at the browser level during client-side script execution. However, since this specific function executes server-side using PHP's filter_input mechanism to read cookies directly from the superglobal array, standard browser-based mitigations offer no protection against extraction of session data by malicious templates or scripts embedded within page content.
The operational impact is severe due to how Grav handles caching and authentication states. When a user with only page-write permissions publishes a page containing malicious Twig code that invokes get_cookie(), the system processes this content on behalf of any visitor who views it, including administrators. The resulting HTML output, which now contains the extracted session cookie value from the administrator's request, is stored in Grav’s page-content cache. Crucially, this cache key is derived solely from the page identity and a configuration checksum, ignoring user-specific dimensions such as session ID or authentication status. Consequently, once an authenticated administrator views the compromised page, their session identifier becomes embedded in the cached output associated with that specific URL path. This creates a persistent backdoor where subsequent requests to view the same page by unauthenticated users will receive the cached response containing the stolen administrative session cookie.
Attackers can exploit this condition through simple credential replay attacks. By obtaining the captured session token from the cache, an attacker can inject it into their own browser or HTTP client and authenticate as the administrator without needing valid credentials such as a password. This effectively bypasses all authentication controls for any user who has page-write privileges to create or edit content on the site. The risk is further amplified in versions 2.0.19 and later, where security.twig_content.process_enabled defaults to true. In these versions, Security::applyTwigContentDefault() automatically enables Twig processing for every page regardless of frontmatter settings, meaning that any user with write access can inadvertently or intentionally trigger this vulnerability on all pages they edit without needing explicit configuration changes by the site administrator.
This flaw aligns with CWE-613, which describes insufficient session expiration, and more accurately maps to CWE-798 regarding use of hardcoded credentials if one considers the static nature of the cached session token as a form of persistent unauthorized access mechanism. From an ATT&CK perspective, this vulnerability facilitates Initial Access via Valid Accounts through Session Hijacking (T1528) and potentially Persistence if the attacker maintains control over the compromised account for further lateral movement or data exfiltration. The lack of per-user caching dimensions means that a single malicious page can compromise multiple administrative sessions over time as different admins view it, creating a widespread impact across the organization’s infrastructure managed by Grav.
Mitigation strategies must prioritize immediate patching to version 2.0.25 where this issue is resolved. For environments unable to upgrade immediately due to compatibility constraints or operational downtime requirements, administrators should disable Twig processing for page content entirely if not strictly required for site functionality. This can be achieved by setting security.twig_content.process_enabled to false in the system configuration file. Additionally, implementing strict Content Security Policy headers may help mitigate some client-side exploitation vectors but does not address the server-side cookie extraction flaw directly. Regular auditing of user permissions is also recommended to ensure that only trusted individuals have page-write capabilities, reducing the attack surface for potential insider threats or compromised low-privilege accounts. Monitoring access logs for unusual patterns in session usage can aid in detecting ongoing exploitation attempts while remediation efforts are underway.