GHSA-2P49-HGCM-8545
Vulnerability from github – Published: 2026-07-21 19:42 – Updated: 2026-07-21 19:42Summary
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
scriptelements, 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
import { optimize } from 'svgo';
/** Presume that this string was obtained in some other way, such as network. */
const original = `
<svg xmlns="http://www.w3.org/2000/svg" xmlns:svg="http://www.w3.org/2000/svg" xmlns:uwu="http://www.w3.org/1999/xlink" viewBox="0 0 100 100" version="1.1">
<a uwu:href="JavaScript:(() => { alert(document.cookie) })();"><text y="30">uwu</text></a>
<svg:script>
alert(document.cookie);
</svg:script>
</svg>
`;
optimize(original, {
plugins: ['removeScripts']
});
// Did not remove <svg:script> or uwu:href="JavaScript:…—still executed by browsers.
Impact
If you run SVGO on untrusted input (e.g., user uploads to a web application) and you depended on removeScripts, then some scripts may still be present. If that SVG was then opened directly by another user on the same domain, it could invoke scripts that could read local storage or cookies.
This may affect you if you have enabled one of the following:
| SVGO Version | Plugin Name |
|---|---|
| v4 | removeScripts |
| v3 | removeScriptElement |
| v2 | removeScriptElement |
| v1 | removeScriptElement |
It's unlikely to impact users who just use SVGO locally on their own SVGs or in build pipelines.
Patches
>= 3.0.0, <= 4.0.1
SVGO patched v4.0.2 and v3.3.4. Just upgrade the dependency using your preferred package manager! For example:
yarn up svgo
# or if SVGO is a nested dependency
yarn up -R svgo
The proposed fix is to improve our namespace-aware handling to explicitly act on the default namespace, SVG namespace, and XHTML namespace only. This handles all scripts that are executed by browsers, but will leave intact custom prefixes that happen to have an element called <*:script> which clients shouldn't treat as executable.
>= 2.0.0, <= 2.8.2
SVGO patched v2.8.3, however SVGO v2 explicitly only implements and documents that it will remove <script> elements and nothing more. It has the namespace aware handling for tags like <svg:script> or <xhtml:script>, but has not been updated to remove JavaScript URIs or event handlers like >= v3. If this is something you need, please upgrade to v4 or v3, or reach for one of the documented workarounds at the end.
>= 1.0.0, <= 1.3.2
SVGO v1 has been deprecated for a while now and won't be patched. Please upgrade to a more recent version! If something is preventing you from doing so, please reach out! We're happy to expand our migration guides or support you if you're having trouble.
Workarounds
If your motivation for enabling the plugin is SVG sanitization, consider reaching for a dedicated SVG sanitization tool and invoke it before passing the SVG to SVGO.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "svgo"
},
"ranges": [
{
"events": [
{
"introduced": "1.0.0"
},
{
"fixed": "2.8.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "svgo"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.3.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "svgo"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0"
},
{
"fixed": "4.0.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-184",
"CWE-79"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-21T19:42:04Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\n\nSVGO\u0027s 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.\n\n### Details\n\nSVGO has a plugin for removing scripts from an SVG, which removes:\n\n- `\u003cscript\u003e` elements\n- JavaScript URIs (v4 and v3 only)\n- `on\u2026` event handlers (v4 and v3 only)\n\nWhile SVGO is not a sanitization library, SVGO continues to maintain the plugin for those already using it for this purpose.\n\nHowever, there were two problems:\n\n- SVGO did not check namespaced/prefixed `script` elements, for example if one declared an explicit prefix for the SVG namespace ( `\u003csvg:script\u003e`) instead of using the default namespace ( `\u003cscript\u003e`), the `\u003csvg:script\u003e` tag would be left intact.\n- SVGO case sensitively matched JavaScript URIs, but it should\u0027ve been case-insensitive.\n\n#### Proof of Concept\n\n```js\nimport { optimize } from \u0027svgo\u0027;\n\n/** Presume that this string was obtained in some other way, such as network. */\nconst original = `\n \u003csvg xmlns=\"http://www.w3.org/2000/svg\" xmlns:svg=\"http://www.w3.org/2000/svg\" xmlns:uwu=\"http://www.w3.org/1999/xlink\" viewBox=\"0 0 100 100\" version=\"1.1\"\u003e\n \u003ca uwu:href=\"JavaScript:(() =\u0026gt; { alert(document.cookie) })();\"\u003e\u003ctext y=\"30\"\u003euwu\u003c/text\u003e\u003c/a\u003e\n \u003csvg:script\u003e\n alert(document.cookie);\n \u003c/svg:script\u003e\n \u003c/svg\u003e\n`;\n\noptimize(original, {\n plugins: [\u0027removeScripts\u0027]\n});\n// Did not remove \u003csvg:script\u003e or uwu:href=\"JavaScript:\u2026\u2014still executed by browsers.\n```\n\n### Impact\n\nIf you run SVGO on untrusted input (e.g., user uploads to a web application) and you depended on removeScripts, then some scripts may still be present. If that SVG was then opened directly by another user on the same domain, it could invoke scripts that could read local storage or cookies.\n\nThis may affect you if you have enabled one of the following:\n\n| SVGO Version | Plugin Name |\n|---|---|\n| v4 | removeScripts |\n| v3 | removeScriptElement |\n| v2 | removeScriptElement |\n| v1 | removeScriptElement |\n\nIt\u0027s unlikely to impact users who just use SVGO locally on their own SVGs or in build pipelines.\n\n### Patches\n\n#### \u003e= 3.0.0, \u003c= 4.0.1\n\nSVGO patched v4.0.2 and v3.3.4. Just upgrade the dependency using your preferred package manager! For example:\n\n```sh\nyarn up svgo\n\n# or if SVGO is a nested dependency\nyarn up -R svgo\n```\n\nThe proposed fix is to improve our namespace-aware handling to explicitly act on the default namespace, SVG namespace, and XHTML namespace only. This handles all scripts that are executed by browsers, but will leave intact custom prefixes that happen to have an element called `\u003c*:script\u003e` which clients shouldn\u0027t treat as executable. \n\n#### \u003e= 2.0.0, \u003c= 2.8.2\n\nSVGO patched v2.8.3, however SVGO v2 explicitly only implements and documents that it will remove `\u003cscript\u003e` elements and nothing more. It has the namespace aware handling for tags like `\u003csvg:script\u003e` or `\u003cxhtml:script\u003e`, but has **_not_** been updated to remove JavaScript URIs or event handlers like \u003e= v3. If this is something you need, please upgrade to v4 or v3, or reach for one of the documented workarounds at the end.\n\n#### \u003e= 1.0.0, \u003c= 1.3.2\n\nSVGO v1 has been deprecated for a while now and won\u0027t be patched. Please upgrade to a more recent version! If something is preventing you from doing so, please reach out! We\u0027re happy to expand our migration guides or support you if you\u0027re having trouble.\n\n### Workarounds\n\nIf your motivation for enabling the plugin is SVG sanitization, consider reaching for a dedicated SVG sanitization tool and invoke it before passing the SVG to SVGO.",
"id": "GHSA-2p49-hgcm-8545",
"modified": "2026-07-21T19:42:04Z",
"published": "2026-07-21T19:42:04Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/svg/svgo/security/advisories/GHSA-2p49-hgcm-8545"
},
{
"type": "WEB",
"url": "https://github.com/svg/svgo/commit/628e3bc7336625a30365d0a9b60185307d852466"
},
{
"type": "WEB",
"url": "https://github.com/svg/svgo/commit/72a23886b4698b27624b936f3a15a80afd36d75f"
},
{
"type": "WEB",
"url": "https://github.com/svg/svgo/commit/f529cfccc6c154d6f6eabe276ec637a8c5db6763"
},
{
"type": "PACKAGE",
"url": "https://github.com/svg/svgo"
},
{
"type": "WEB",
"url": "https://github.com/svg/svgo/releases/tag/v2.8.3"
},
{
"type": "WEB",
"url": "https://github.com/svg/svgo/releases/tag/v3.3.4"
},
{
"type": "WEB",
"url": "https://github.com/svg/svgo/releases/tag/v4.0.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "SVGO removeScripts plugin leaves some executable scripts intact"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.