Summary
SVGO's opt-in removeScripts plugin did not inspect executable HTML content inside SVG <foreignObject> elements. Applications that used this plugin as their only protection for untrusted SVG input could produce SVGs containing active HTML and 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
Although the plugin removed SVG and XHTML <script> elements, it left other HTML execution paths inside <foreignObject> unchanged. These included:
- event-handler attributes such as
onload and onbeforetoggle;
srcdoc documents, including on <iframe> elements;- executable URLs in HTML attributes such as
action, data, formaction, href, and src.
An attacker could place one of these payloads in an SVG. If an application optimized the untrusted SVG with removeScripts and then served the result in an active browser context, the payload could execute in the viewer's origin.
Impact
Successful exploitation could allow script execution in the context where the optimized SVG is rendered. 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 removeScripts 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 preserves visual HTML inside SVG <foreignObject> elements while removing event attributes, srcdoc, and executable URL values from active HTML URL attributes.
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. As defense in depth, applications can reject or remove <foreignObject> content and avoid serving user-controlled SVGs in an active same-origin context.
References
Summary
SVGO's opt-in
removeScriptsplugin did not inspect executable HTML content inside SVG<foreignObject>elements. Applications that used this plugin as their only protection for untrusted SVG input could produce SVGs containing active HTML and 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
Although the plugin removed SVG and XHTML
<script>elements, it left other HTML execution paths inside<foreignObject>unchanged. These included:onloadandonbeforetoggle;srcdocdocuments, including on<iframe>elements;action,data,formaction,href, andsrc.An attacker could place one of these payloads in an SVG. If an application optimized the untrusted SVG with
removeScriptsand then served the result in an active browser context, the payload could execute in the viewer's origin.Impact
Successful exploitation could allow script execution in the context where the optimized SVG is rendered. 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
removeScriptsare 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 preserves visual HTML inside SVG
<foreignObject>elements while removing event attributes,srcdoc, and executable URL values from active HTML URL attributes.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. As defense in depth, applications can reject or remove
<foreignObject>content and avoid serving user-controlled SVGs in an active same-origin context.References