Grav CMS CVE-2026-62237

Two conditions must both be true for exploitation: (1) The Grav security setting security.twig_content.process_enabled must be set to true - this is explicitly disabled by default and requires deliberate administrator action to enable. (2) The attacker must hold at least a page-editor-level account on the target Grav installation (CVSS PR:L). There is no path to unauthenticated exploitation. Exploitation is further limited to the regex_replace Twig filter/function specifically, which is the allowlisted entry point into PCRE. What limits exploitation: the non-default configuration gate is the primary hard barrier - most Grav deployments are not affected without specific configuration changes; additionally, editor-level authentication prevents anonymous exploitation. PHP's max_execution_time setting will eventually terminate a runaway preg_replace() call but does not prevent the DoS within that window.

The CVSS 4.0 score of 6.0 is fair and appropriately modulated by AT:P (attack requirements present), reflecting that the non-default Twig content processing setting must be enabled. The network attack vector and low privilege requirement mean exploitation is straightforward for anyone holding a page-editor account on an affected instance - no complex payload delivery or privilege escalation is needed beyond that baseline. EPSS data was not provided, but the gating conditions (non-default config + authenticated editor) substantially reduce the realistic exploitation population. No KEV listing and no known POC further suggest opportunistic mass exploitation is not occurring. The practical risk is highest for multi-tenant Grav installations - hosted CMS platforms or educational/agency environments - where untrusted users may hold page-editor roles and where Twig content processing has been intentionally enabled. Single-operator personal sites are lower risk by posture even if technically vulnerable. The CVSS vector is internally consistent with the description; no conflicting signals are present.

An attacker with a page-editor account on a Grav instance where security.twig_content.process_enabled: true is configured submits a page containing a regex_replace call with a PCRE pattern designed for catastrophic backtracking - for example, a pattern like /(a+)+$/ against a long non-matching string. When Grav processes the page, PHP's preg_replace() enters exponential backtracking, consuming 100% of a CPU core for the duration of the request or until the PHP execution time limit is hit; repeated requests across multiple editor accounts or rapid re-submission can exhaust all worker processes and render the site unavailable. No public proof-of-concept has been identified, but the technique is well-understood and trivially reproducible from published ReDoS literature.