Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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…
Recommended action: Upgrade to 4.1.0, 3.3.5 or 2.8.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 4.1.0, 3.3.5 or 2.8.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
SVGO's removeScripts plugin (disabled by default) removes scripts from the SVG, however executable scripts were left intact in some cases. If a consumer relied on this plugin for sanitization and served them to users, these SVGs could open up doors to XSS. Details SVGO has a plugin for removing scripts from an SVG, which removes: - <script elements - JavaScript URIs (v4 and v3 only) - on… event handlers (v4 and v3 only) While SVGO is not a sanitization library, SVGO continues to maintain the plugin for those already using it for this purpose. However, there were two problems: - SVGO did not check namespaced/prefixed script elements, for example if one declared an explicit prefix for the SVG namespace ( <svg:script) instead of using the default namespace ( <script), the <svg:script tag would be left intact. - SVGO case sensitively matched JavaScript URIs, but it should've been case-insensitive. Proof of Concept Impact If you run SVGO on untrusted input (e.g., user uploads to a…
Recommended action: Upgrade to 4.0.2, 3.3.4 or 2.8.3 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
SVGO accepts XML with custom entities, without guards against entity expansion or recursion. This can result in a small XML file (811 bytes) stalling the application and even crashing the Node.js process with JavaScript heap out of memory. Details The upstream XML parser (sax) doesn't interpret custom XML entities by default. We pattern matched custom XML entities from the DOCTYPE, inserting them into parser.ENTITIES, and enabled unparsedEntities. This gives us the desired behavior of supporting SVGs with entities declared in the DOCTYPE. However, entities can reference other entities, which can enable small SVGs to explode exponentially when we try to parse them. Proof of Concept Impact If SVGO is run on untrusted input (i.e., user uploaded to server-side application), then the untrusted SVG can effectively stall or crash the application with an SVG < 1 KB in size. It's unlikely to impact users who just use SVGO locally on their own SVGs or in build pipelines. Patches SVGO…
Recommended action: Upgrade to 4.0.1, 3.3.3 or 2.8.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.