CVE-2026-62672 — grav
Fix: getgrav/grav@9071162CVE-2026-62672 is a CWE-1333 vulnerability in getgrav/grav. A fix is available for getgrav/grav — see the affected versions and patch details below.
Grav: Authenticated ReDoS via regex_replace in Twig Sandbox
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-62672.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
Real-World Exposure
getgrav/gravReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.
Description
Summary
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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | getgrav/grav | all versions | 2.0.4composer require getgrav/grav:^2.0.4 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for getgrav/grav, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update getgrav/grav to 2.0.4 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-62672 is resolved across your whole dependency graph.
Workarounds
Cap what an attacker can consume: apply request size, rate and timeout limits in front of the affected component, and run it with memory and CPU limits so exhaustion degrades one worker rather than the whole service.
Frequently Asked Questions
Is CVE-2026-62672 in your dependencies?
Find it across Packagist, including transitive dependencies.