GHSA-q2j8-x8hf-63ch
Suggest an improvement- Source
- https://github.com/advisories/GHSA-q2j8-x8hf-63ch
- Import Source
- https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2026/09/GHSA-q2j8-x8hf-63ch/GHSA-q2j8-x8hf-63ch.json
- JSON Data
- https://api.osv.dev/v1/vulns/GHSA-q2j8-x8hf-63ch
- Aliases
- Published
- 2026-09-17T20:44:39Z
- Modified
- 2026-09-17T21:00:04Z
- Severity
-
- 5.4 (Medium) CVSS_V3 - CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N CVSS Calculator
- 5.1 (Medium) CVSS_V4 - 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 CVSS Calculator
- Summary
- Grav: Single invalid UTF-8 byte disables every rule in Security::detectXss(), bypassing the page-content XSS safety gate
- Details
-
Vulnerability Details
Component: getgrav/grav core File:
system/src/Grav/Common/Security.phpFunction:detectXss()(all six entries in the$patternsarray use the PCREumodifier), invoked fromGrav\Common\Data\Validation::checkSafety()(the save-time XSS gate for any non-security.xss_whitelistaccount's blueprint field, including the pagecontentfield) anddetectXssInEditorContent()(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:NRelationship 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
$patternsuses the PCREu(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 returnsfalsefor the entire call, withpreg_last_error() === PREG_BAD_UTF8_ERROR.detectXss()only checks truthiness (if (preg_match(...) || preg_match(...))), sofalseand "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 anywhereDirectly 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()==4Attack 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 invokesdetectXss()for accounts outsidesecurity.xss_whitelist(defaultadmin.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 returnedNULL(bypass), and an ordinary safe string returnedNULLas expected. Note: the JSON REST API (apiplugin, the path Admin2's SPA uses to save pages) happens to reject raw invalid UTF-8 before it reachesdetectXss(), because RFC 8259 requires JSON text to be valid UTF-8 and PHP'sjson_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 returnsNULL(no regression).A ready-to-apply fix branch is prepared locally against this repo's
developbranch (based on the2.0.13tag); happy to push it to a private fork once one is available for this advisory. - Database specific
{ "cwe_ids": [ "CWE-79" ], "github_reviewed": true, "github_reviewed_at": "2026-09-17T20:44:39Z", "nvd_published_at": null, "severity": "MODERATE" }- References
Affected packages
Packagist / getgrav/grav
Package
- Name
- getgrav/grav
- Purl
- pkg:composer/getgrav/grav
Affected ranges
- Type
- ECOSYSTEM
- Events
-
Introduced0 Unknown introduced version / All previous versions are affectedFixed2.0.14