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:
- 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.
- 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
NotAFlightRisk Reporter
Summary
SVGO's opt-in
removeScriptsplugin 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
removeScriptsis maintained for consumers that already rely on it to remove common script execution paths.Details
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 executablehrefor namespaced*:hrefvalues remained intact.java	script:could remain executable after bypassing the plugin'sjavascript:check.Anchors in unrelated custom namespaces are not executable SVG anchors and remain untouched.
Impact
If an application optimized attacker-controlled SVGs with
removeScriptsand 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:
removeScriptElementremoveScriptElementremoveScriptsThe 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