GHSA-3h6j-9x8m-rg3g

Описание

Summary

Graby's cleanupXss() function configures htmLawed with conflicting settings: safe=1 (which removes <iframe>) combined with 'elements' => '*+iframe-meta' (which re-enables <iframe>). 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:

The safe=1 and +iframe combination is a conflict: safe mode is designed to strip dangerous elements, but the elements override re-enables <iframe> without also blocking the dangerous srcdoc attribute.

Proof of Concept

Input to cleanupXss():

Output (unchanged — htmLawed passes it through):

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:

Or explicitly deny the srcdoc attribute:

Credit

Discovered by @tikket1, 2026-03-25. Redirected from wallabag/wallabag advisory by @j0k3r.