GHSA-3h6j-9x8m-rg3g Graby has stored XSS via iframe srcdoc Attribute in htmLawed Sanitization Config

• Packagist j0k3r/graby: < 2.5.1 → fixed in 2.5.1

Summary Graby's `cleanupXss()` function configures htmLawed with conflicting settings: `safe=1` (which removes ``) combined with `'elements' => '*+iframe-meta'` (which re-enables ``). htmLawed does not sanitize the `srcdoc` attribute, allowing injection of arbitrary JavaScript that executes when the content is rendered via `|raw` in templates. Root Cause `src/Graby.php` lines 1038-1048: ```php htmLawed($html, [ 'safe' => 1, // removes 'elements' => '*+iframe-meta', // re-adds , overrides safe=1 'deny_attribute' => 'style', // srcdoc is NOT denied ]); ``` The `safe=1` and `+iframe` combination is a conflict: `safe` mode is designed to strip dangerous elements, but the elements override re-enables `` without also blocking the dangerous `srcdoc` attribute. Proof of Concept Input to `cleanupXss()`: ```html ``` Output (unchanged — htmLawed passes it through): ```html ``` When rendered via `{{ content|raw }}` in a template, `srcdoc` executes in an `about:srcdoc` frame with the same origin as the page. Confirmed via Puppeteer/Chromium headless: `alert(document.domain)` fires. Validated on Wallabag (which uses Graby) via Docker: entry created via API with iframe-only content body triggers Readability failure → falls through to `cleanupXss()` path. Impact • Stored XSS in any application rendering Graby-sanitized content via `|raw` • In Wallabag: affects both authenticated views and public share pages (unauthenticated) • No CSP headers in default Wallabag config — no secondary mitigation Suggested Fix Either remove `+iframe` from the elements config to keep iframes blocked: ```php 'elements' => '*-iframe-meta', ``` Or explicitly deny the `srcdoc` attribute: ```php 'deny_attribute' => 'style srcdoc', ``` Credit Discovered by @tikket1, 2026-03-25. Redirected from wallabag/wallabag advisory by @j0k3r.