/

CVE-2026-100671

Severity:

HIGH RISK

(8.0)

Sensitive Data Exposure (CWE-200) in Grav CMS Twig

CVE-2026-100671

Deferred

Vulnerability type

Category:

Sensitive Data Exposure

CWE:

CWE-200

Impact:

Session Hijacking and Account Takeover

Severity:

HIGH RISK

(8.0)

CVSS version:

3.1

Catch this CVE while code is being written

Detect vulnerable code directly in pull requests, so CVEs are fixed before merge.

Summary

Grav can expose an administrator's session identifier when user-authored page content is processed through Twig and the rendered result is cached without a user or request boundary. An attacker with page-write permission may cause a later administrator's cookie value to be included in cached content, allowing unauthorized visitors to obtain and potentially replay the session identifier.

Affected context

The issue can occur in Grav deployments where page content Twig processing is enabled and page-write users can publish content. It is especially risky when the Twig sandbox exposes request cookie values and the resulting output is cached using only page identity and configuration state, without separating authenticated and unauthenticated requests. Affected behavior includes Grav 2.0.19 through 2.0.24, while earlier 2.0.x and 1.7.x releases require content Twig to have been explicitly enabled.

Exploit preconditions

  • Attack surface: User-authored page content, Twig processing, and page-content caching
  • Required access: Permission to write or publish page content, plus a later administrator visit to the affected page
  • Trigger point: Server-side rendering of page content when the administrator's request includes a session cookie
  • Why exploitation is possible: The Twig sandbox can read request cookies, and the rendered output is cached without session, user, or request separation
  • Additional exposure condition: An unauthenticated party must be able to retrieve the cached page output

Why this happens

The vulnerability results from combining excessive data access in a content-rendering sandbox with an improperly scoped cache. A Twig function allowlisted for page content can return arbitrary cookies from the current request, including session identifiers, while the cache stores the resulting output without a security-context dimension. This maps to CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, because a secret associated with one request is made available through content served to other users.

Potential impact

  • An administrator session identifier may be disclosed
  • An unauthenticated visitor could potentially replay the exposed session and impersonate an administrator
  • Administrative functions and sensitive CMS content may be accessed
  • Site content, configuration, or users could be modified
  • The compromise could enable further application or infrastructure abuse

General mitigation guidance

Mitigation generally focuses on reducing trust in user-authored templates, preventing sensitive request data from entering rendered content, and enforcing security-aware cache boundaries.

Common defensive patterns include:

  • Removing cookie, session, and other credential-bearing request data from content-accessible template functions
  • Restricting content Twig to a narrowly defined, safe expression set or disabling it where it is not required
  • Separating administrative and public rendering contexts
  • Preventing cache reuse across authenticated and unauthenticated requests when output can depend on request data
  • Avoiding caching of pages whose output contains security-sensitive or user-specific values
  • Applying least privilege to page authors and requiring review for content that enables executable templating
  • Rotating potentially exposed sessions and reviewing administrative activity when disclosure is suspected

How teams detect issues like this

Detection approaches can include:

  • Static analysis for template functions that expose cookies, headers, session data, or other request secrets
  • Code review checks for caches keyed only by content identity while output depends on request or user state
  • Tests that compare rendered output across authenticated and unauthenticated requests
  • Policy enforcement preventing sensitive request values from being callable by user-authored templates
  • Monitoring for unusual administrative sessions, content changes, or access patterns following publication of Twig-enabled pages
  • Automated security review tools that flag sensitive-data flows into publicly cacheable responses

Sources

SourceLink
github.comgithub.com/getgrav/grav/security/advisories/GHSA-pp89-h475-7gj6
vulncheck.comvulncheck.com/advisories/grav-before-2.0.25-session-cookie-theft-via-twig-sandbox

Frequently asked

questions

The content publication step generally requires page-write permission. However, once sensitive output has been placed in a broadly accessible cache, an unauthenticated visitor may be able to retrieve the exposed session value.

No. The vulnerable read occurs on the server during request processing, so browser-side restrictions such as HttpOnly do not prevent the application from placing the cookie value into rendered output.

Do not expose cookies or session identifiers to user-authored templates, and ensure cached output is separated by the security context whenever rendering can depend on request-specific data.

Apply least privilege to content authors, limit template capabilities, test cache behavior across user roles, and enforce policies that prevent credentials or session data from flowing into public responses.

Find out what's already
exploitable in your codebase.