svg-sanitizer EUVD-2026-110805

No special conditions beyond being able to submit an SVG: the vulnerable PHP-tag stripping loop runs in the DEFAULT configuration, before any XML parsing (loadXML), on every Sanitizer::sanitize() call, so any unauthenticated user who can upload/submit an SVG to an endpoint using svg-sanitize 0.5.3 through 1.0.0 can trigger it. The library does not bound input length, and because this is pre-parse string work the allowHugeFiles/setAllowHugeFiles setting is irrelevant and does not mitigate it. Limiting factors are narrow: the target must actually route attacker-supplied SVGs through sanitize(), and impact is confined to CPU/worker exhaustion (availability) - there is no auth, interaction, or non-default setting required, and no confidentiality or integrity impact. The only complete fix stated by the vendor is upgrading to 1.1.0.

The signals are consistent and point to a real but bounded priority. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) describes a remote, low-complexity, unauthenticated, no-interaction trigger, and the GHSA confirms the flaw sits in the pre-parse PHP-tag stripping loop that runs on every sanitize() call in the default configuration - so the ease-of-reach is corroborated by source evidence, not just the vector. However, impact is availability-only: VC:N/VI:N/VA:H means pure CPU-exhaustion denial of service, with no confidentiality or integrity loss and no code execution, which is why the 8.7 'high' score should not be read as a compromise-class issue. The vuln.today decision label is 'this_week', matching a serious-but-not-emergency DoS. A detailed public PoC generator with a measured quadratic timing table (0.16s at 32KB rising to 22.2s at 384KB) is published in the advisory, and the attack is scriptable/automatable, which raises practical likelihood. No EPSS score and no KEV status were provided in the input, so there is no evidence of active exploitation and no quantified exploitation probability - absence of these is not evidence of safety, but this is currently a disclosed-with-PoC DoS rather than a confirmed in-the-wild threat. Net: patch within the vendor/priority window, but triage below any RCE or data-exposure issue.

An attacker submits a crafted SVG (a few hundred KB to a few MB) to any unauthenticated upload endpoint whose backend runs svg-sanitize in default config. The file is built from many overlapping '<?p' openers and 'hp...?>' closers so the tag-stripping loop peels one tag and rescans the whole remaining string per pass, forcing quadratic preg_replace work that pins a PHP worker for tens of seconds to minutes. A handful of concurrent such requests exhausts the worker pool and takes the service offline; a detailed PoC generator and timing measurements are published in the GHSA advisory (not verified as turnkey working exploit code).