Graby has stored XSS via iframe srcdoc Attribute in htmLawed Sanitization Config
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:
htmLawed($html, [
'safe' => 1, // removes <iframe>
'elements' => '*+iframe-meta', // re-adds <iframe>, 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 <iframe> without also blocking the dangerous srcdoc attribute.
Proof of Concept
Input to cleanupXss():
<iframe srcdoc="<script>alert(document.domain)</script>"></iframe>
Output (unchanged — htmLawed passes it through):
<iframe srcdoc="<script>alert(document.domain)</script>"></iframe>
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:
'elements' => '*-iframe-meta',
Or explicitly deny the srcdoc attribute:
'deny_attribute' => 'style srcdoc',
Credit
Discovered by @tikket1, 2026-03-25. Redirected from wallabag/wallabag advisory by @j0k3r.
Software afectado
Haz clic en una tecnología para ver todas sus vulnerabilidades.
| Plataforma | Paquete | Versiones vulnerables | Corregida en |
|---|---|---|---|
| Paquete de Composer | j0k3r/graby | < 2.5.1 | 2.5.1 |
Referencias
- Vector CVSS
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N/E:P- Debilidad (CWE)
CWE-79- Plataforma
- Composer
- Paquete
j0k3r/graby- Publicada
- 31.03.2026
- Actualizado
- 11.10.2026 10:22
Fuentes y licencias
OSV / GitHub Advisory Database - GHSA-3h6j-9x8m-rg3g - CC BY 4.0
Historial de vulnerabilidades: j0k3r/graby
Todas las vulnerabilidades publicadas de este paquete (Paquete de Composer), de la más reciente a la más antigua. Muestra si es un fallo aislado o un paquete que hay que vigilar.
Esta es la única vulnerabilidad conocida de este paquete.
Identifica las vulnerabilidades de tu aplicación
Con la integración de DockRay y el inventario de software activado, DockRay compara las versiones notificadas de los componentes con las vulnerabilidades conocidas y avisa de las coincidencias confirmadas. La cobertura depende de la tecnología compatible y de los avisos disponibles.