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

> Stored XSS in Graby library allows arbitrary JavaScript execution via unsanitized iframe srcdoc attributes when content is rendered raw.

- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Login needed:** Any signed-in user
- **Attackable:** Over the internet
- **Victim action needed:** A user has to click or open something
- **Fix available:** Yes
- **Published:** 31 Mar 2026

## What is GHSA-3h6j-9x8m-rg3g?

GHSA-3h6j-9x8m-rg3g is a cross-site scripting vulnerability in j0k3r/graby, published on 31 Mar 2026. Any signed-in user can exploit it over the network, and only if a user opens a file or follows a link.

### Official description

## 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:**
```php
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()`:
```html
<iframe srcdoc="&lt;script&gt;alert(document.domain)&lt;/script&gt;"></iframe>
```

Output (unchanged — htmLawed passes it through):
```html
<iframe srcdoc="&lt;script&gt;alert(document.domain)&lt;/script&gt;"></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:
```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.

## Which versions are affected by GHSA-3h6j-9x8m-rg3g?

2 open source packages ship an affected version, including j0k3r/graby.


| Package | Ecosystem | Affected | Fixed in |
| --- | --- | --- | --- |
| `j0k3r/graby` | Packagist | All versions | 2.5.1 |
| `j0k3r/graby` | Packagist | All versions | 2.5.1 |

## How do I fix GHSA-3h6j-9x8m-rg3g?

Upgrade j0k3r/graby to 2.5.1 or later.

## Is GHSA-3h6j-9x8m-rg3g being exploited?

There is no known exploitation of GHSA-3h6j-9x8m-rg3g in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for GHSA-3h6j-9x8m-rg3g and fix it if it is affected.

What it is: GHSA-3h6j-9x8m-rg3g is a cross-site scripting vulnerability in j0k3r/graby, published on 31 Mar 2026. Any signed-in user can exploit it over the network, and only if a user opens a file or follows a link.
Exploitation: There is no known exploitation of GHSA-3h6j-9x8m-rg3g in the wild and no public exploit code.

Affected packages and fixed versions:
- j0k3r/graby (Packagist): affected all versions; fixed in 2.5.1
- j0k3r/graby (Packagist): affected all versions; fixed in 2.5.1

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/GHSA-3h6j-9x8m-rg3g/ (Markdown: https://insights.sbomify.com/GHSA-3h6j-9x8m-rg3g/index.md)
```

## Sources

- OSV: https://osv.dev/vulnerability/GHSA-3h6j-9x8m-rg3g

---
From sbomify Insights: https://insights.sbomify.com/GHSA-3h6j-9x8m-rg3g/
Summaries are generated and may contain mistakes; the official description above is the record.