Grav: Stored XSS via quoted-attribute bypass in detectXss

A page editor without admin.super can bypass Grav's stored-content XSS check and save a page containing malicious JavaScript. The script runs in the site's origin when someone views the page, including an unauthenticated visitor.

Check composer.lock for getgrav/grav versions from 1.5.2 through 2.0.12 inclusive; 2.0.13 is fixed. Review whether users have admin.login and admin.pages without admin.super, allowing them to save page content. Also review security.xss_whitelist, whose default is admin.super, since the affected check protects page saves by editors outside that whitelist.

The advisory suggests using an HTML tokenizer or sanitiser that rejects event-handler attributes on parsed elements. If retaining the existing detector, make its tag scan quote-aware.

Summary

A page editor without admin.super can place an event handler after a > inside a quoted attribute. Grav accepts and stores the page, then executes the handler in the application origin when a visitor opens it.

Details

Security::detectXss() (system/src/Grav/Common/Security.php:253) anchors the on_events scan at < and uses [^>]*?, which cannot cross the first literal >. When that character is inside a quoted value, the browser keeps the tag open and parses the later onerror attribute, so the detector and browser disagree. AdminController::savePage() relies on this detector when saving content from page editors outside the admin.super whitelist.

PoC

I reproduced this with getgrav/grav 2.0.11 (ad9709f865b09b68798fb1ac375b484a8cc1d892), Admin 1.10.52, and Quark 2 1.1.4.

1. Sign in as a user with admin.login and admin.pages, but without admin.super.
2. Create or edit /xsstest and save this page body:

<img src=x title=">" onerror=alert(document.domain)>

3. Open /xsstest in a private browser window.

The save succeeds and the visitor sees an alert containing the site domain. With the body changed to <img src=x onerror=alert(1)>, the same endpoint rejects it with XSS issue detected and does not store it.

Impact

A page editor can execute JavaScript in the origin of every user who views the stored page, including unauthenticated visitors.

Anticipated objection and response

Although the detectXss() docblock describes it as a heuristic that cannot catch every XSS, this check is the storage-time boundary for page editors outside the default security.xss_whitelist of admin.super. The same endpoint rejects a plain handler but accepts this executable form, allowing a lower-trust editor to cross the boundary the check is intended to enforce.

Suggested fix

Prefer an HTML tokenizer or sanitizer that rejects event-handler attributes on parsed elements. If the existing tripwire remains, make its tag scan quote-aware instead of treating every > as a boundary. Add double-quoted and single-quoted regression cases plus the rejected plain-handler control.