CVE-2026-75834 in Grav
Summary
by MITRE • 08/18/2026
Grav before 2.0.14 contains a stored cross-site scripting vulnerability in the Security::detectXss() function (system/src/Grav/Common/Security.php). All XSS detection patterns use the PCRE /u (UTF-8) modifier, so a single invalid UTF-8 byte anywhere in page content causes preg_match() to return false for every pattern, silently bypassing the save-time XSS safety gate (Validation::checkSafety()). An authenticated attacker with page-edit permissions (without the security.xss_whitelist privilege) can store malicious JavaScript that executes in the browser of a visitor who views the affected page.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/18/2026
The vulnerability identified in Grav versions prior to 2.0.14 represents a critical failure in input validation logic, specifically within the Security::detectXss() function located in system/src/Grav/Common/Security.php. This flaw allows for stored cross-site scripting attacks by exploiting how PHP handles invalid UTF-8 sequences during regular expression matching. The core technical issue stems from the use of the PCRE /u modifier on all XSS detection patterns. When this modifier is active, the preg_match() function expects valid UTF-8 encoded strings. If an attacker injects a single byte that does not form part of a valid multi-byte character sequence into page content, PHP's regex engine encounters an illegal encoding error and immediately returns false for every pattern check. This behavior effectively bypasses the save-time XSS safety gate implemented in Validation::checkSafety(), as the system interprets the failure to match any patterns as a clean result rather than a validation error or rejection of malicious input.
From a classification perspective, this vulnerability aligns with CWE-79 Improper Neutralization of Input During Web Page Generation commonly known as Cross-site Scripting and more specifically relates to CWE-184 Incomplete List of Valid Characters which describes the failure to properly handle character encoding boundaries. The attack vector is classified under ATT&CK technique T1059 Command and Scripting Interpreter with a focus on JavaScript, allowing an attacker to execute arbitrary scripts in the context of the victim's browser session. Because the vulnerability occurs during the save operation rather than at runtime input processing, it persists in the database until manually corrected or overwritten by another edit, making it particularly dangerous for long-term site integrity and user safety.
The operational impact is severe because an authenticated attacker with page-edit permissions can permanently embed malicious JavaScript payloads into published content pages. This does not require administrative privileges but only standard editing rights, which are often granted to multiple users such as editors or contributors who may have lower security awareness. When a visitor views the affected page, their browser will execute the stored script within the context of the Grav website domain. Depending on the payload injected, this can lead to session hijacking through cookie theft, credential harvesting via fake login forms, defacement of the user interface, redirection to malicious sites for phishing attacks, or even lateral movement if combined with other vulnerabilities like CSRF tokens being bypassed due to same-origin policy violations triggered by the script execution.
Mitigation strategies must focus on both immediate patching and long-term defensive coding practices. The primary remediation is upgrading Grav to version 2.0.14 or later where this specific UTF-8 handling flaw has been addressed in the security module. For environments unable to upgrade immediately, administrators should restrict page-edit permissions to only trusted individuals with strong security hygiene and enable additional server-side filtering that validates input encoding before it reaches the PHP regex engine. Implementing Content Security Policy headers can also help mitigate the impact of successful XSS attacks by restricting script sources and preventing inline execution unless explicitly allowed through nonces or hashes, thereby reducing the effectiveness of any stored scripts injected via this vulnerability.