Live › vulnerability › CVE-2026-84370
Go to dashboardSVGO's opt-in removeScripts plugin leaves some executable SVG links in place when the anchor uses a namespace prefix or the URL scheme contains tab or newline characters. If an application optimizes untrusted SVGs with this plugin and serves the output in an active browser context, a victim who follows a link can run script in the SVG's origin.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-26 23:54 UTC, 0h before NVD. All times on this page are UTC.
Applications that run SVGO's removeScripts (or removeScriptElement on v2 and v3) over attacker-controlled SVG files and then serve the result in an active browser context are exposed. The plugin is opt-in, so projects that do not enable it are not relying on the affected behavior. Typical local optimization of trusted SVG files is not affected.
| Product | Ecosystem | Affected | Fixed in |
|---|---|---|---|
| svgo | npm | >= 1.0.0, < 2.8.4 | 2.8.4 |
| svgo | npm | >= 3.0.0, < 3.3.5 | 3.3.5 |
| svgo | npm | >= 4.0.0, < 4.1.0 | 4.1.0 |
npm ls svgo to list the installed SVGO versions and find which ones are below 2.8.4, 3.3.5 or 4.1.0.removeScripts or removeScriptElement to see whether the plugin is enabled in the SVGO config.2.8.4 on the v2 line, 3.3.5 on the v3 line, or 4.1.0 on the v4 line.Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
SVGO's opt-in removeScripts plugin failed to remove some executable links. Namespace-prefixed SVG anchors and URL schemes containing ASCII tabs or newlines could bypass its checks. Applications that used this plugin as their only protection for untrusted SVG input could expose users to cross-site scripting (XSS).
SVGO is an optimizer rather than a comprehensive sanitization library, but removeScripts is maintained for consumers that already rely on it to remove common script execution paths.
Two related bypasses were present:
<a> elements but did not recognize namespace-prefixed SVG anchors such as <svg:a> when the prefix was bound to the SVG namespace. Their executable href or namespaced *:href values remained intact.java	script: could remain executable after bypassing the plugin's javascript: check.Anchors in unrelated custom namespaces are not executable SVG anchors and remain untouched.
If an application optimized attacker-controlled SVGs with removeScripts and then served the result in an active browser context, a victim could follow a link that executes script in the SVG's origin. Depending on the embedding and origin configuration, this could expose cookies or local storage, modify content, or perform actions as the victim.
The plugin is opt-in, so consumers that do not enable it are not relying on the affected behavior. Typical local optimization of trusted SVG files is not affected.
Upgrade to one of the following releases for the maintained release line in use:
| Release line | Patched version | Plugin |
|---|---|---|
| v2 | 2.8.4 | removeScriptElement |
| v3 | 3.3.5 | removeScriptElement |
| v4 | 4.1.0 | removeScripts |
The fix makes SVG anchor handling namespace-aware and strips ASCII tabs, line feeds, and carriage returns before checking executable URL schemes.
SVGO v1 is no longer maintained. Users of v1 should upgrade to a supported release line.
For hostile input, use a dedicated SVG sanitization tool before passing the SVG to SVGO. Applications can also reject links from untrusted SVG input and avoid serving user-controlled SVGs in an active same-origin context.
This page as .md · .json · in your agent: get_signal("CVE-2026-84370")
GitHub Advisory Database, CC-BY 4.0 · NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.