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
7 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
A crafted SVG bypasses enshrined/svg-sanitize's href validation and delivers a javascript: URL through the sanitizer unchanged. The bypass exploits a semantic mismatch between XML entity resolution (used during sanitization) and HTML5 Named Character Reference resolution (used by the browser when the SVG is rendered inline). This is a logic bug in svg-sanitize. It does NOT depend on any PHP ext/dom bug — it works on any PHP version. Affected installations: - enshrined/svg-sanitize: 45.2M Packagist downloads, 1.3M/month, 90+ dependents - WordPress Safe SVG plugin: 1M+ active installs (inline SVG rendering via themes) - TYPO3, Drupal and 90+ other Packagist dependents Vulnerability Details Mechanism 1. Attacker defines a DTD entity whose name collides with an HTML5 Named Character Reference: In XML, 	 expands to the literal string "#" (from the DTD definition). In HTML5, 	 is a Named Character Reference that resolves to U+0009 (TAB character). 2. The SVG uses this…
Recommended action: Upgrade to 1.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Resolver::processReferences() collects <use elements with the XPath predicate use[@href or @xlink:href], which is case sensitive. A <use element written as xlink:HrEf is therefore never added to the reference graph, so the nesting-DoS nullification never marks it for removal. Sanitizer::cleanHrefAttributes() then runs later in the same pass and rewrites xlink:HrEf back to the canonical xlink:href. The sanitizer hands back a fully live nesting bomb that it would have stripped completely had the input used canonical casing. This is the mirror image of CVE-2025-55166: that fix made href value checking case insensitive, but the <use reference graph still selects nodes case sensitively. Where it is src/ElementReference/Resolver.php:97-118, the case-sensitive node selection: src/Sanitizer.php:479-504, the normalization that happens afterwards and makes the attribute live again: Ordering is the whole bug. Sanitizer::sanitize() builds the resolver graph first and normalizes attribute…
Recommended action: Upgrade to 1.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A crafted SVG file (1009 bytes) crashes the PHP process when sanitized by enshrined/svg-sanitize (any version through 0.22.x). The sanitizer's cleanAttributesOnWhitelist() method calls DOMElement::removeAttribute() twice on the same attribute name — first removing the explicit attribute, then attempting to remove the DTD #FIXED default — triggering a PHP ext/dom type confusion that kills the PHP-FPM worker. Affected installations: - enshrined/svg-sanitize: 45.2M Packagist downloads, 1.3M/month, 90+ dependents - WordPress Safe SVG plugin: 1M+ active installs - TYPO3: svg-sanitize integrated into core since v9 - Drupal: community module wrapping svg-sanitize Vulnerability Details Trigger Flow Root cause in svg-sanitize: The sanitizer does not strip DOCTYPE/DTD declarations before processing. The cleanAttributesOnWhitelist() method at Sanitizer.php:303-330 has a double-removal pattern where the whitelist check and the href safety check can both call removeAttribute() on the same…
Recommended action: Upgrade to 1.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Problem The sanitization logic at https://github.com/darylldoyle/svg-sanitizer/blob/0.21.0/src/Sanitizer.php#L454-L481 only searches for lower-case attribute names (e.g. xlink:href instead of xlink:HrEf), which allows to by-pass the isHrefSafeValue check. As a result this allows cross-site scripting or linking to external domains. Proof-of-concept provided by azizk Credits The mentioned findings and proof-of-concept example were reported to the TYPO3 Security Team by the external security researcher azizk <medazizknani@gmail.com.
Recommended action: Upgrade to 0.22.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact SVG sanitizer library before version 0.15.0 did not remove HTML elements wrapped in a CDATA section. As a result, SVG content embedded in HTML (fetched as text/html) was susceptible to cross-site scripting. Plain SVG files (fetched as image/svg+xml) were not affected. Patches This issue is fixed in 0.15.0 and higher. Workarounds There is currently no workaround available without upgrading. For more information If you have any questions or comments about this advisory: Open an issue in Github Email us at daryll@enshrined.co.uk
Recommended action: Upgrade to 0.15.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
It is possible to bypass enshrined/svg-sanitize before 0.13.1 using the "xlink:href" attribute due to mishandling of the xlink namespace by the sanitizer.
Recommended action: Upgrade to 0.13.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
enshrined/svg-sanitize before 0.12.0 mishandles script and data values in attributes, as demonstrated by unexpected whitespace such as in the javascript	:alert substring.
Recommended action: Upgrade to 0.12.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.