CVE-2026-84370: SVGO: removeScripts allows executable links through namespace and control-character bypasses
Summary
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.
Details
Two related bypasses were present:
1. The plugin inspected unprefixed SVG <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. 2. The URL check did not account for ASCII tab, line-feed, or carriage-return characters embedded in a scheme. Browsers remove these characters before parsing the scheme, so values such as 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.
Impact
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.
Patches
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.
Workarounds
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.
References
- v4 fix: https://github.com/svg/svgo/pull/2268 - related executable URL hardening: https://github.com/svg/svgo/pull/2263 - v3 backport: https://github.com/svg/svgo/pull/2269 - v2 backport: https://github.com/svg/svgo/pull/2272 - v4.1.0 release: https://github.com/svg/svgo/releases/tag/v4.1.0 - v3.3.5 release: https://github.com/svg/svgo/releases/tag/v3.3.5 - v2.8.4 release: https://github.com/svg/svgo/releases/tag/v2.8.4
Other sources
SVGO, short for SVG Optimizer, is a Node.js library and command-line application for optimizing SVG files. From version 1.0.0 until versions 2.8.4, 3.3.5, and 4.1.0, the opt-in removeScripts plugin, named removeScriptElement in versions 2 and 3, incompletely filters executable links in plugins/removeScripts.js and lib/svgo/tools.js. The plugin does not recognize namespace-prefixed SVG anchor elements such as svg:a with href or namespaced :href values, and it does not remove ASCII tab, line-feed, or carriage-return characters before checking URL schemes. Browsers remove those characters before parsing a scheme, allowing an executable link to pass the plugin's check. When an application processes attacker-controlled SVG input and serves the result in an active browser context, a victim who activates the surviving link can execute script in the SVG's origin, expose data, modify content, or perform actions as the victim. This issue is fixed in versions 2.8.4, 3.3.5, and 4.1.0.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/svgoto a version that resolves this vulnerability.Fixed in 4.1.0 - Upgrade
Upgrade
npm/svgoto a version that resolves this vulnerability.Fixed in 3.3.5 - Upgrade
Upgrade
npm/svgoto a version that resolves this vulnerability.Fixed in 2.8.4 - Upgrade
Upgrade
svgoto a version that resolves this vulnerability.Fixed in 2.8.4 - Upgrade
Upgrade
svgoto a version that resolves this vulnerability.Fixed in 3.3.5 - Upgrade
Upgrade
svgoto a version that resolves this vulnerability.Fixed in 4.1.0 - Compensating control
For hostile input, use a dedicated SVG sanitization tool before passing the SVG to SVGO.
- Compensating control
Applications can reject links from untrusted SVG input and avoid serving user-controlled SVGs in an active same-origin context (where a clicked/executed link could expose cookies/local storage or modify content).
Event History
Frequently Asked Questions
Who is exposed to this issue?
Applications are exposed if they process attacker-controlled SVG files with SVGO's opt-in removeScripts plugin (called removeScriptElement in versions 2 and 3) and then serve the optimized SVG in an active browser context. Exploitation also requires a victim to activate the surviving link.
Is the default SVGO configuration affected?
The affected functionality is an opt-in plugin. The provided information identifies exposure when removeScripts or removeScriptElement is enabled; it does not state that default configurations enable it.
What input patterns can bypass the plugin's filtering?
Namespace-prefixed SVG anchors such as svg:a with href, namespaced *:href attributes, and URL schemes containing ASCII tab, line-feed, or carriage-return characters can bypass the checks. Browsers remove those control characters before interpreting the URL scheme.
What should be done if an upgrade is not immediately possible?
Do not rely on the affected plugin to sanitize attacker-controlled SVGs before serving them in an active browser context. Prevent untrusted SVG uploads from being served as active browser content until a fixed version can be deployed.
Which versions contain fixes?
Fixed versions are 2.8.4, 3.3.5, and 4.1.0. The issue affects versions starting at 1.0.0 up to those fixed releases.