CVE-2026-84370 in SVGOinfo

Summary

by MITRE • 09/02/2026

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.

Once again VulDB remains the best source for vulnerability data.

Analysis

by VulDB Data Team • 09/02/2026

SVGO, widely recognized as an essential tool for optimizing Scalable Vector Graphics files within Node.js environments, contained a significant security flaw affecting its removeScripts plugin across multiple major releases from version 1.0.0 through specific patched versions including 2.8.4, 3.3.5, and 4.1.0. The core function of this plugin is to sanitize SVG content by stripping out potentially dangerous script elements to prevent cross-site scripting attacks when the optimized graphics are rendered in a browser context. However, the implementation suffered from incomplete filtering logic that failed to account for specific edge cases involving namespace-prefixed anchor elements and whitespace characters within URL schemes. This oversight created a bypass mechanism where malicious actors could embed executable JavaScript code inside SVG files that appeared safe according to SVGO's validation rules but remained active when processed by web browsers.

The technical root of the vulnerability lies in two distinct oversights within the filtering logic located in plugins/removeScripts.js and lib/svgo/tools.js. First, the plugin did not recognize namespace-prefixed SVG anchor elements, specifically those denoted as svg:a with href attributes or other namespaced variants using *:href values. Standard security filters often focus on generic a tags but may miss these XML-namespaced equivalents which are valid in SVG documents and can still trigger script execution if they contain event handlers or javascript: URIs. Second, the validation process failed to strip ASCII control characters such as tabs, line-feeds, and carriage returns before evaluating URL schemes. This is critical because modern web browsers automatically normalize URLs by removing these whitespace characters prior to parsing the scheme. Consequently, an attacker could obfuscate a malicious url like javascript:alert(1) by inserting invisible newline or tab characters within it, such as java\nscript:alert(1). SVGO would see this string and potentially classify it as safe because its internal check did not account for browser normalization behavior, allowing the script to survive the optimization process.

When an application utilizes a vulnerable version of SVGO to process user-uploaded or attacker-controlled SVG files, these obfuscated scripts remain intact in the output file. If the resulting optimized SVG is then served and rendered within an active browser context where it shares origin with other sensitive web applications, any victim who interacts with the graphic can trigger the embedded script. This interaction typically requires a click or hover event on the anchor element, but once triggered, the consequences are severe. The executed code runs in the security context of the SVG's origin, granting attackers the ability to execute arbitrary JavaScript commands. This capability allows for comprehensive cross-site scripting attacks where sensitive data such as session cookies, authentication tokens, or personal information can be exfiltrated to an attacker-controlled server. Furthermore, it enables content modification and unauthorized actions performed on behalf of the victim, effectively compromising the integrity and confidentiality of the web application.

This vulnerability is classified under CWE-79, which covers Improper Neutralization of Input During Web Page Generation commonly known as Cross-site Scripting (XSS). It also aligns with MITRE ATT&CK technique T1059, specifically sub-technique 007 for JavaScript execution, illustrating how attackers leverage legitimate file formats to deliver malicious payloads. The impact is particularly acute in environments where SVG images are dynamically generated or processed server-side before being displayed to users, as the optimization step provides a false sense of security while actually preserving dangerous code due to the logic gap described. Organizations relying on SVGO for image processing pipelines must ensure they have upgraded past the affected versions to mitigate this risk.

To remediate this issue, developers and system administrators should immediately upgrade SVGO to version 2.8.4, 3.3.5, or 4.1.0 and later releases where these filtering gaps have been closed. The fix involves enhancing the removeScripts plugin to properly handle namespace-prefixed anchor elements and implementing robust normalization of URL strings by stripping whitespace characters before scheme validation. Additionally, defense-in-depth strategies should be employed, such as validating SVG content against a strict allowlist of permitted attributes and events rather than relying solely on blacklist-based removal plugins. Implementing Content Security Policy headers can also help mitigate the impact of any residual XSS vulnerabilities by restricting script execution sources. Regular security audits of image processing libraries are recommended to ensure that optimizations do not inadvertently introduce or preserve security flaws in rendered content.

Responsible

GitHub M

Reservation

09/01/2026

Disclosure

09/02/2026

Moderation

accepted

CPE

ready

EPSS

0.00000

KEV

no

Activities

very low

Sources

Do you want to use VulDB in your project?

Use the official API to access entries easily!