Skip to content
Patch Next
Sign inAdd to your agent

← Public intelligence

Packagist package

j0k3r/graby

Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.

Open advisories

1 actionable advisory, newest first. Withdrawn advisories and news are excluded. Coverage is partial.

  1. Low, CVSS 2.1PackagistPublished

    Graby has stored XSS via iframe srcdoc Attribute in htmLawed Sanitization Config

    GHSA-3h6j-9x8m-rg3g

    Affected
    • Packagist j0k3r/graby <= 2.5.0
    Fixed in
    2.5.1· Vendor fix available
    Issue
    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…

    Recommended action: Upgrade to 2.5.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →