CVE-2026-75834: Input Sanitization Bypass leading to Stored XSS in Grav CMS

The flat-file Content Management System Grav relies on a central input validation library to inspect, block, and clean potential security threats before they write to disk. This mechanism, implemented in Security::detectXss(), targets user input across all editable page structures. Under standard settings, the scanner flags cross-site scripting (XSS) indicators before any modifications parse into the physical markdown pages.

Because the underlying engine inspects markup on the server side prior to database-free file writes, any validation failure represents an instantaneous bypass of the platform's editor permissions. The vulnerability surface is accessible to any authenticated user with page-creation or page-modification roles. This includes authors and editors who typically lack unrestricted script execution capabilities.

By leveraging specific design gaps in PHP's PCRE execution model, malicious payloads can navigate through these safety checks without setting off the system's defensive alerts. The resulting injection results in high-integrity stored scripts that target admin and visitor sessions.

The root cause lies in how Grav's validation logic evaluates the output of PHP's standard PCRE regular expression execution engine. Specifically, preg_match returns 0 if no matching threat patterns are located, and 1 if a matching pattern is caught. However, if the evaluation itself cannot complete due to internal engine limitations or data structure mismatches, the function returns the boolean value false.

The logic used to evaluate this output performed a loose truthiness check. Because PHP treats both 0 (clean) and false (processing error) as falsy values, any operational error inside preg_match was treated as an assurance that the evaluated input string contained zero threats. This architecture represents a classic fail-open state, where error handling falls back to the least restrictive option.

Two independent paths trigger this fail-open state. First, the inclusion of the /u (UTF-8) modifier on all regex pattern definitions forces preg_match to immediately reject inputs containing structurally invalid UTF-8 byte sequences. Second, recursive backtracking limits during the evaluation of oversized markup blocks trigger PCRE JIT stack limit errors, which similarly crash the evaluation and return false.

The vulnerable implementation in system/src/Grav/Common/Security.php directly called preg_match inside a loop without checking for exact integer returns. Here is the conceptual vulnerable structure:

// Vulnerable evaluation logic in detectXss
foreach ($patterns as $name => $regex) {
    if (preg_match($regex, $string)) {
        return $name; // Threat flagged
    }
}
return null; // Treated as safe

The remediated approach resolves this by executing the validation within a specialized private helper, patternMatches. This function explicitly checks for strict boolean outcomes and defaults to a fail-closed response (true) if any matching errors occur. Below is the secure implementation:

private static function patternMatches(string $regex, string $subject): bool
{
    $result = preg_match($regex, $subject);
    if ($result !== false) {
        return (bool) $result;
    }
 
    if (preg_last_error() === PREG_JIT_STACKLIMIT_ERROR) {
        $jit = ini_get('pcre.jit');
        ini_set('pcre.jit', '0');
        $result = preg_match($regex[0] . '(?:)' . substr($regex, 1), $subject);
        ini_set('pcre.jit', (string) $jit);
        if ($result !== false) {
            return (bool) $result;
        }
    }
 
    // Fail closed if any other error (such as backtracking limits) occurs
    return true;
}

Exploitation requires an authenticated editor account or an API exposure that feeds user input into the Grav page parser. Attackers can leverage either the character encoding bypass or the JIT stack limit exhaustion vulnerability to deliver standard script vectors. The injection payload remains inactive on the server but is stored in its raw format inside the flat-file markdown content.

In the invalid UTF-8 attack vector, the attacker inserts a single bad byte (such as hex \x80) immediately before a functional HTML element. When the security validation layer parses this input, the internal regular expressions fail immediately. The engine returns false, causing the system to write the page content to disk. When the page is subsequently requested by a client, the browser decodes the malformed byte sequence into a Unicode replacement character (such as U+FFFD) and executes the remaining HTML and JavaScript normally.

In the JIT stack exhaustion attack vector, the attacker provides a highly nested or padded tag structure. The recursive validation expressions run out of JIT stack memory, generating a PREG_JIT_STACKLIMIT_ERROR. The regex matching halts, returns false, and permits the storing of the script payload. Upon page render, the browser disregards the excessive padding and executes the accompanying javascript attribute.

The impact of a stored Cross-Site Scripting vulnerability in a Content Management System like Grav is high. Because administrative actions in the dashboard can be executed via client-side requests, a successfully injected script targeting an administrator can automate high-privilege activities. This includes creating new admin users, altering configurations, or utilizing system-level integrations to compromise the hosting environment.

Furthermore, because the payload executes in the browsers of ordinary site visitors, it can be used for session hijacking, drive-by malware delivery, or phishing campaigns. The scope change metric in CVSS v3.1 (S:C) highlights this transition, indicating that the vulnerability allows the compromise of resources beyond the security boundaries of the target platform.

The vulnerability holds a CVSS v3.1 base score of 5.4. While it requires low privileges (PR:L), the potential for administrative takeover elevated by administrative views changes the practical threat landscape to a high risk level in typical production environments.

The recommended remediation path is to upgrade the Grav core system to version 2.0.14 or later. This version contains the fully patched Security::detectXss logic, replacing raw evaluation checks with robust fail-closed mechanics and handling invalid UTF-8 transformations safely at the entry point.

If instant upgrades are not feasible, teams should apply the code changes in the official patch commit 5192316f5bf0f033636f43561829d7fc13a4ab64. Administrators can also implement a Web Application Firewall (WAF) or local validation rules to strip malformed character byte strings (such as isolated non-ASCII characters) and restrict input sizes on page update endpoints.

To identify historical indicators of compromise, security teams should execute binary scans across the user/pages/ folder. Files failing UTF-8 compilation or containing excessively long HTML structures paired with Javascript event keywords should be flagged and manually validated.