GHSA-Q2J8-X8HF-63CH
Vulnerability from github – Published: 2026-09-17 20:44 – Updated: 2026-09-17 20:44Vulnerability Details
Component: getgrav/grav core
File: system/src/Grav/Common/Security.php
Function: detectXss() (all six entries in the $patterns array use the PCRE u modifier), invoked from Grav\Common\Data\Validation::checkSafety() (the save-time XSS gate for any non-security.xss_whitelist account's blueprint field, including the page content field) and detectXssInEditorContent() (the render-time backstop for GHSA-2c4f-86xc-cr74)
CWE: CWE-79 (Stored XSS), root-caused by CWE-20 (Improper Input Validation — fails open on malformed input)
Severity: High
CVSS: 8.0 — CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N
Relationship to prior advisories
This project's detectXss()/checkSafety() stack has been patched at least three times for the "page editor without super-admin rights stores an event handler that runs for site visitors" bug class: GHSA-9695-8fr9-hw5q / GHSA-c2q3-p4jr-c55f / GHSA-w8cg-7jcj-4vv2 (unquoted-attribute bypasses), GHSA-269c-h76q-8cxw (quoted-attribute-boundary bypass), GHSA-2c4f-86xc-cr74 (render-time Twig-assembled bypass). All three patched the regex logic. This is a different, lower-level defect: the PHP regex engine silently refuses to evaluate the pattern at all once the input contains one invalid UTF-8 byte, independent of what the regex logic says — no amount of regex-logic hardening fixes this.
Root Cause
Every pattern in $patterns uses the PCRE u (UTF-8) modifier. PHP's documented behavior: if the subject string contains even one byte sequence that is not valid UTF-8, preg_match() does not "skip" that byte or report "no match" — it returns false for the entire call, with preg_last_error() === PREG_BAD_UTF8_ERROR. detectXss() only checks truthiness (if (preg_match(...) || preg_match(...))), so false and "0 matches" are indistinguishable to the calling code. A single stray byte anywhere in a field's value — not even near the actual payload — makes every one of the six checks silently report "no XSS found".
Meanwhile, a real browser decoding the same bytes as UTF-8 (the encoding Grav serves pages as) does not fail open: it substitutes the invalid byte with one U+FFFD replacement character and renders the surrounding markup completely normally. The <img ... onerror=...> tag is untouched structurally; the payload still fires.
Vulnerable Code
$patterns = [
'on_events' => '#<(?:"[^"]*"|\'[^\']*\'|[^>"\'])*?(?:[\s\x00-\x20\"\'\/]|"[^"]*"|\'[^\']*\')on\s*[a-z]+\s*=#iu',
// ... five more, all with the /u modifier
];
foreach ($patterns as $name => $regex) {
if (!empty($enabled_rules[$name])) {
if (preg_match($regex, (string) $string) || preg_match($regex, $orig)) {
return $name;
}
// ...
}
}
return null; // reached even when the string contains <img onerror=...>,
// as long as it also contains one invalid UTF-8 byte anywhere
Directly reproducible against the exact regex:
$regex = '#<(?:"[^"]*"|\'[^\']*\'|[^>"\'])*?(?:[\s\x00-\x20\"\'\/]|"[^"]*"|\'[^\']*\')on\s*[a-z]+\s*=#iu';
var_dump(preg_match($regex, "<img src=x onerror=alert(1)>")); // int(1) -- caught
var_dump(preg_match($regex, "<img src=x \x80onerror=alert(1)>")); // bool(false), preg_last_error()==4
Attack Scenario
- Attacker holds a page-edit ("publisher") account without super-admin rights.
- Sets page content to
Hello world \x80<img src=x onerror=alert(document.cookie)>(a raw invalid UTF-8 byte, deliverable via any non-JSON submission path — e.g. the bundled Form plugin's multipart/urlencoded field, or any blueprint-validated field populated from a raw POST body —$_POSTvalues are not UTF-8-validated by PHP). Validation::checkSafety()runsdetectXss()on the value; everypreg_match()call returnsfalse, sodetectXss()returnsnull("no violation"). The payload saves unmodified.- Any visitor (including a super-admin browsing the public site) loads the page; the browser renders the intact
<img onerror=...>element, executing the attacker's JavaScript in the visitor's session.
Impact
- Type: Stored XSS (CWE-79)
- Auth required: Page-edit ("publisher") account, not super-admin
- Consequence: Arbitrary JavaScript execution in any visitor's browser, including a super-admin who views the page — a cross-trust-boundary escalation from publisher to admin-equivalent action capability.
Recommended Fix
public static function detectXss($string, ?array $options = null): ?string
{
if (null === $string || !is_string($string) || empty($string)) {
return null;
}
// Fail closed: mb_check_encoding() validates the whole string up front
// and returns a normal boolean — it never "fails open" the way a
// /u-flagged preg_match() does on malformed input.
if (!mb_check_encoding($string, 'UTF-8')) {
return 'invalid_encoding';
}
// ... rest unchanged
}
Validation::checkSafety() only invokes detectXss() for accounts outside security.xss_whitelist (default admin.super), so this introduces no behavior change for whitelisted accounts.
Verification
Dynamically confirmed on grav 2.0.13: called the live Security::detectXss() directly (bootstrapped through Grav's own service container, not a standalone regex copy) — a clean payload was correctly flagged ("on_events"), the same payload plus one invalid UTF-8 byte returned NULL (bypass), and an ordinary safe string returned NULL as expected. Note: the JSON REST API (api plugin, the path Admin2's SPA uses to save pages) happens to reject raw invalid UTF-8 before it reaches detectXss(), because RFC 8259 requires JSON text to be valid UTF-8 and PHP's json_decode() enforces this — that's an incidental protection of the JSON layer, not a fix, and any non-JSON submission path (e.g. the bundled Form plugin's multipart/urlencoded fields) remains exposed. After applying the fix above, the same bypass payload correctly returns "invalid_encoding" (a violation), while an ordinary safe string still returns NULL (no regression).
A ready-to-apply fix branch is prepared locally against this repo's develop branch (based on the 2.0.13 tag); happy to push it to a private fork once one is available for this advisory.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "getgrav/grav"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.0.14"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-75834"
],
"database_specific": {
"cwe_ids": [
"CWE-79"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-17T20:44:39Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Vulnerability Details\n\n**Component**: getgrav/grav core\n**File**: `system/src/Grav/Common/Security.php`\n**Function**: `detectXss()` (all six entries in the `$patterns` array use the PCRE `u` modifier), invoked from `Grav\\Common\\Data\\Validation::checkSafety()` (the save-time XSS gate for any non-`security.xss_whitelist` account\u0027s blueprint field, including the page `content` field) and `detectXssInEditorContent()` (the render-time backstop for GHSA-2c4f-86xc-cr74)\n**CWE**: CWE-79 (Stored XSS), root-caused by CWE-20 (Improper Input Validation \u2014 fails open on malformed input)\n**Severity**: High\n**CVSS**: 8.0 \u2014 CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N\n\n### Relationship to prior advisories\nThis project\u0027s `detectXss()`/`checkSafety()` stack has been patched at least three times for the \"page editor without super-admin rights stores an event handler that runs for site visitors\" bug class: GHSA-9695-8fr9-hw5q / GHSA-c2q3-p4jr-c55f / GHSA-w8cg-7jcj-4vv2 (unquoted-attribute bypasses), GHSA-269c-h76q-8cxw (quoted-attribute-boundary bypass), GHSA-2c4f-86xc-cr74 (render-time Twig-assembled bypass). All three patched the **regex logic**. This is a different, lower-level defect: the PHP regex *engine* silently refuses to evaluate the pattern at all once the input contains one invalid UTF-8 byte, independent of what the regex logic says \u2014 no amount of regex-logic hardening fixes this.\n\n### Root Cause\nEvery pattern in `$patterns` uses the PCRE `u` (UTF-8) modifier. PHP\u0027s documented behavior: if the subject string contains even one byte sequence that is not valid UTF-8, `preg_match()` does not \"skip\" that byte or report \"no match\" \u2014 it returns `false` for the **entire call**, with `preg_last_error() === PREG_BAD_UTF8_ERROR`. `detectXss()` only checks truthiness (`if (preg_match(...) || preg_match(...))`), so `false` and \"0 matches\" are indistinguishable to the calling code. A single stray byte anywhere in a field\u0027s value \u2014 not even near the actual payload \u2014 makes every one of the six checks silently report \"no XSS found\".\n\nMeanwhile, a real browser decoding the same bytes as UTF-8 (the encoding Grav serves pages as) does not fail open: it substitutes the invalid byte with one U+FFFD replacement character and renders the surrounding markup completely normally. The `\u003cimg ... onerror=...\u003e` tag is untouched structurally; the payload still fires.\n\n### Vulnerable Code\n```php\n$patterns = [\n \u0027on_events\u0027 =\u003e \u0027#\u003c(?:\"[^\"]*\"|\\\u0027[^\\\u0027]*\\\u0027|[^\u003e\"\\\u0027])*?(?:[\\s\\x00-\\x20\\\"\\\u0027\\/]|\"[^\"]*\"|\\\u0027[^\\\u0027]*\\\u0027)on\\s*[a-z]+\\s*=#iu\u0027,\n // ... five more, all with the /u modifier\n];\nforeach ($patterns as $name =\u003e $regex) {\n if (!empty($enabled_rules[$name])) {\n if (preg_match($regex, (string) $string) || preg_match($regex, $orig)) {\n return $name;\n }\n // ...\n }\n}\nreturn null; // reached even when the string contains \u003cimg onerror=...\u003e,\n // as long as it also contains one invalid UTF-8 byte anywhere\n```\n\nDirectly reproducible against the exact regex:\n```php\n$regex = \u0027#\u003c(?:\"[^\"]*\"|\\\u0027[^\\\u0027]*\\\u0027|[^\u003e\"\\\u0027])*?(?:[\\s\\x00-\\x20\\\"\\\u0027\\/]|\"[^\"]*\"|\\\u0027[^\\\u0027]*\\\u0027)on\\s*[a-z]+\\s*=#iu\u0027;\nvar_dump(preg_match($regex, \"\u003cimg src=x onerror=alert(1)\u003e\")); // int(1) -- caught\nvar_dump(preg_match($regex, \"\u003cimg src=x \\x80onerror=alert(1)\u003e\")); // bool(false), preg_last_error()==4\n```\n\n### Attack Scenario\n1. Attacker holds a page-edit (\"publisher\") account without super-admin rights.\n2. Sets page content to `Hello world \\x80\u003cimg src=x onerror=alert(document.cookie)\u003e` (a raw invalid UTF-8 byte, deliverable via any non-JSON submission path \u2014 e.g. the bundled Form plugin\u0027s multipart/urlencoded field, or any blueprint-validated field populated from a raw POST body \u2014 `$_POST` values are not UTF-8-validated by PHP).\n3. `Validation::checkSafety()` runs `detectXss()` on the value; every `preg_match()` call returns `false`, so `detectXss()` returns `null` (\"no violation\"). The payload saves unmodified.\n4. Any visitor (including a super-admin browsing the public site) loads the page; the browser renders the intact `\u003cimg onerror=...\u003e` element, executing the attacker\u0027s JavaScript in the visitor\u0027s session.\n\n### Impact\n- **Type**: Stored XSS (CWE-79)\n- **Auth required**: Page-edit (\"publisher\") account, not super-admin\n- **Consequence**: Arbitrary JavaScript execution in any visitor\u0027s browser, including a super-admin who views the page \u2014 a cross-trust-boundary escalation from publisher to admin-equivalent action capability.\n\n### Recommended Fix\n```php\npublic static function detectXss($string, ?array $options = null): ?string\n{\n if (null === $string || !is_string($string) || empty($string)) {\n return null;\n }\n\n // Fail closed: mb_check_encoding() validates the whole string up front\n // and returns a normal boolean \u2014 it never \"fails open\" the way a\n // /u-flagged preg_match() does on malformed input.\n if (!mb_check_encoding($string, \u0027UTF-8\u0027)) {\n return \u0027invalid_encoding\u0027;\n }\n\n // ... rest unchanged\n}\n```\n`Validation::checkSafety()` only invokes `detectXss()` for accounts outside `security.xss_whitelist` (default `admin.super`), so this introduces no behavior change for whitelisted accounts.\n\n### Verification\nDynamically confirmed on grav 2.0.13: called the live `Security::detectXss()` directly (bootstrapped through Grav\u0027s own service container, not a standalone regex copy) \u2014 a clean payload was correctly flagged (`\"on_events\"`), the same payload plus one invalid UTF-8 byte returned `NULL` (bypass), and an ordinary safe string returned `NULL` as expected. Note: the JSON REST API (`api` plugin, the path Admin2\u0027s SPA uses to save pages) happens to reject raw invalid UTF-8 before it reaches `detectXss()`, because RFC 8259 requires JSON text to be valid UTF-8 and PHP\u0027s `json_decode()` enforces this \u2014 that\u0027s an incidental protection of the JSON layer, not a fix, and any non-JSON submission path (e.g. the bundled Form plugin\u0027s multipart/urlencoded fields) remains exposed. After applying the fix above, the same bypass payload correctly returns `\"invalid_encoding\"` (a violation), while an ordinary safe string still returns `NULL` (no regression).\n\nA ready-to-apply fix branch is prepared locally against this repo\u0027s `develop` branch (based on the `2.0.13` tag); happy to push it to a private fork once one is available for this advisory.",
"id": "GHSA-q2j8-x8hf-63ch",
"modified": "2026-09-17T20:44:39Z",
"published": "2026-09-17T20:44:39Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/getgrav/grav/security/advisories/GHSA-q2j8-x8hf-63ch"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-75834"
},
{
"type": "PACKAGE",
"url": "https://github.com/getgrav/grav"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/grav-before-stored-xss-via-invalid-utf-8-byte"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Grav: Single invalid UTF-8 byte disables every rule in Security::detectXss(), bypassing the page-content XSS safety gate"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.