This CVE exposes a design assumption in Grav CMS that authentication itself is the trust boundary — and that assumption never accounted for computational cost as a privilege boundary. The vulnerability is reachable through an authenticated editor account combined with the security.twig_content.process_enabled flag, which enables Twig template processing within page content. The regex_replace filter was allowlisted in security.yaml, presumably to prevent code execution or arbitrary function calls. What wasn't modeled: that a regex pattern with catastrophic backtracking (nested quantifiers like (a+)+b) can consume an entire PHP worker during a single request. An authenticated editor can publish such a pattern, and the computational cost is imposed on every site visitor who triggers the processed content — not on the editor themselves. This is "authenticated computational harm to third parties," a threat class that maps poorly to traditional access control thinking. The editor's role scope (editing their own content) has no logical connection to their computational blast radius (visitor CPU consumption). The 2.0.4 fix almost certainly removes regex_replace from the allowlist entirely rather than adding backtracking safeguards — that's the historical norm for ReDoS fixes because pattern complexity validation is difficult to maintain. If so, the flag still exists and someone will re-enable it in a future release, convinced the dangerous part is fixed. Your priority: audit any roles with twig_content.process_enabled and treat template processing access as a higher-threat boundary than a simple role permission. The architectural fix isn't just patching regex_replace — it's recognizing that authenticated users with template processing access have computational authority over visitor requests, and that authority was never governed by the role system. Consider whether any authenticated role should be able to trigger unbounded computational operations through content processing, regardless of the specific filter allowlist.
CVE-2026-62672
Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.
NVD · uneditedGrav is a file-based Web platform. Prior to 2.0.4, Grav allowlists the regex_replace filter and function in system/config/security.yaml, and GravExtension::regexReplace() passes an editor-controlled pattern directly to preg_replace(). When security.twig_content.process_enabled is enabled, an authenticated page editor can publish a catastrophically backtracking pattern that consumes PHP worker CPU and denies service to site visitors. This issue is fixed in version 2.0.4.
Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.
dbcve analysisA detailed technical summary for this CVE is being prepared.
CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.
From the vector- Attack vector
- Network
- Complexity
- High
- Privileges
- Low
- Authentication
- X
- User interaction
- None
- Scope
- X
CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.
dbcve · scoped2.0.4
- Upgrade Grav CMS to version 2.0.4 or later to resolve the ReDoS vulnerability in the regex_replace filter
Generated from the published advisory — verify against the referenced sources before acting.
Scan for this in your stack
Free · runs locallyCheck whether your project pulls in CVE-2026-62672 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.
References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.
Primary sourcesThis CVE exposes a design assumption in Grav CMS that authentication itself is the trust boundary — and that assumption never accounted for computational cost as a privilege boundary. The vulnerability is reachable through an authenticated editor account combined with the `security.twig_content.process_enabled` flag, which enables Twig template processing within page content. The `regex_replace` filter was allowlisted in security.yaml, presumably to prevent code execution or arbitrary function calls. What wasn't modeled: that a regex pattern with catastrophic backtracking (nested quantifiers like `(a+)+b`) can consume an entire PHP worker during a single request. An authenticated editor can publish such a pattern, and the computational cost is imposed on every site visitor who triggers the processed content — not on the editor themselves. This is "authenticated computational harm to third parties," a threat class that maps poorly to traditional access control thinking. The editor's role scope (editing their own content) has no logical connection to their computational blast radius (visitor CPU consumption). The 2.0.4 fix almost certainly removes `regex_replace` from the allowlist entirely rather than adding backtracking safeguards — that's the historical norm for ReDoS fixes because pattern complexity validation is difficult to maintain. If so, the flag still exists and someone will re-enable it in a future release, convinced the dangerous part is fixed. Your priority: audit any roles with ` twig_content.process_enabled` and treat template processing access as a higher-threat boundary than a simple role permission. The architectural fix isn't just patching regex_replace — it's recognizing that authenticated users with template processing access have computational authority over visitor requests, and that authority was never governed by the role system. Consider whether any authenticated role should be able to trigger unbounded computational operations through content processing, regardless of the specific filter allowlist.
Practitioner notes
ContributedPeer-ranked notes from engineers who’ve handled CVE-2026-62672 in production — separate from our analysis above.
The advisory tells you what broke. It rarely tells you what actually worked. If you’ve dealt with this one, that detail is what the next engineer is searching for.
- The version that genuinely resolved it — not the one the vendor claimed
- A config change or rule that shut the vector down
- A gotcha in the upgrade path that cost you an afternoon
A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.
- Verified mitigations, workarounds, and config changes
- Version or environment caveats, and links to real fixes
- No weaponised exploit code, or anything meant to cause harm
- No spam, self-promotion, credentials, or personal data