CVE-2026-73650 exposes a fundamental mismatch between what the SVGO removeScripts plugin appears to do and what it actually achieves. The plugin removes basic script elements, but it fails to catch namespaced SVG script elements (using xmlns: namespaces) and case-sensitive URI schemes like javascript: vs JavaScript:. If you're processing untrusted SVG input and depend on this plugin for security, you're not protected.
The more dangerous problem isn't the technical gap—it's the false confidence the plugin creates. Its name implies comprehensive script removal, which has likely led developers to skip compensating controls like Content Security Policy headers, sandbox attributes, or forcing Content-Disposition: attachment. The plugin became a de facto standard in an era before dedicated SVG sanitizers existed, and that institutional momentum means many applications still rely on it years after DOMPurify and other purpose-built sanitizers became available.
Before patching, audit whether your application actually needs SVGO's optimization pipeline or whether you should switch to a dedicated sanitizer like DOMPurify. If you must use SVGO, treat removeScripts as a supplementary control, not a primary defense—layer CSP headers and consider sandboxing untrusted SVG content. The patch exists in versions 2.8.3, 3.3.4, and 4.0.2, but the deeper issue is whether your architecture ever should have relied on an optimization tool for security in the first place.