GHSA-4vpr-x523-8j87: XSS
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.
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 - Configuration
For SVGO usage that optimizes hostile/untrusted SVG and serves it in an active browser context, enable the opt-in `removeScripts` plugin so executable HTML execution paths inside SVG `<foreignObject>` elements are removed (notably event-handler attributes like `onload`/`onbeforetoggle`, `srcdoc` documents, and executable URL values in HTML attributes such as `action`, `data`, `formaction`, `href`, and `src`).
SVGO removeScripts = enabled - Compensating control
As defense in depth, reject or remove `<foreignObject>` content from untrusted SVG input and avoid serving user-controlled SVGs in an active same-origin context (so cookie/localStorage exposure and in-origin actions are prevented).
- Compensating control
For hostile input, use a dedicated SVG sanitization tool before passing the SVG to SVGO (SVGO is an optimizer rather than a comprehensive sanitization library).
Event History
Frequently Asked Questions
Which applications are exposed to this issue?
Applications are exposed if they accept untrusted SVGs, process them with SVGO's opt-in removeScripts plugin as their only protection, and serve the resulting SVG in an active browser context. The plugin is not a comprehensive SVG sanitization mechanism.
What does an attacker need to exploit it?
An attacker needs to supply a crafted SVG containing a foreignObject with executable HTML content, then cause a user to view the optimized output in an active browser context. The payload can use HTML event-handler attributes, srcdoc content, or executable URLs in attributes such as action, data, formaction, href, or src.
Are deployments using SVGO without removeScripts affected in the same way?
The described weakness is specifically in the opt-in removeScripts plugin and affects consumers relying on that plugin as their only protection for untrusted SVG input. The provided information does not establish exposure for other SVGO configurations.
What is the impact if exploitation succeeds?
A successful payload can execute script in the origin where the optimized SVG is viewed. This can expose the confidentiality and integrity of that browser context.