SVG parser bugs in librsvg and NanoSVG show stripping scripts isn't enough

A recent dev.to article makes a pointed case for anyone who accepts SVG uploads: stripping scripts and event handlers from a file deals with only one category of risk, and leaves a second one untouched — the software that parses and renders the file in the first place.

The piece, titled "Your SVG Has No Scripts. Is It Safe to Process?", anchors its argument in two recent vulnerability reports, neither of which requires JavaScript to exploit.

Bugs that need no JavaScript

The first, tracked as CVE-2026-96889, affects librsvg. According to the dev.to write-up, the flaw involves nested XML inclusions carrying duplicate entity declarations; while processing such a file, the library could free an XML entity that the parser was still using, producing a use-after-free condition. A RustSec advisory dated September 23, 2026 lists fixes in librsvg 2.63.2 and 2.62.4 for the two affected release branches.

The second concerns NanoSVG and is recorded as CVE-2026-88366. The article describes how pathologically large arc radius values can push an intermediate calculation into producing NaN, the floating-point "not a number" value. Casting that value to an integer without first checking it introduces undefined behavior. The underlying bug report was demonstrated with a runtime sanitizer, and the CVE characterizes the practical impact as a potential denial of service.

As the author is careful to note, these are defects in specific implementations at specific versions, not evidence that every SVG renderer is broken. Together, though, they show that scanning a file for scripts is not a complete safety test.

One upload, many parsers

The typical icon pipeline sketched in the article passes a file through several components before a user ever sees a preview: an XML parser, a sanitizer, an optimizer and a rasterizer that generates thumbnails. Every one of them consumes input supplied by a stranger.

That ordering matters, because a filter applied later in the chain cannot retroactively protect a component that already read the malicious bytes — including the sanitizer itself, which must parse the original document in order to clean it.

Four layers of defense

The article lays out four measures for teams handling untrusted SVGs.

Sanitize with a purpose. Decide which elements, attributes and references the application actually needs — a static icon requires a far smaller feature set than an interactive document — and use a maintained sanitizer with an explicit policy. Even then, sanitized output is not proof that downstream parsers can handle the file safely.

Patch the real dependencies. Identify every library in the deployed stack that parses or renders SVGs, including ones bundled inside converters and image-processing tools. Updating your own code does nothing for a stale library baked into a thumbnail service.

Bound the work. Enforce limits on upload size, rendering dimensions, execution time and memory. A small file is not necessarily cheap to process; complex geometry can demand far more work than file size suggests. Limits contain excessive resource consumption but cannot repair memory-safety bugs.

Isolate the processing. Run conversion and preview generation in restricted workers with minimal permissions and no unneeded network or filesystem access, and design the application so a failed worker does not take the main service down with it. These protections should apply from the first component that touches untrusted input, including sanitization.

Why it matters

SVG is easy to treat as "just an image," and many upload features lean entirely on script-stripping sanitizers as their security boundary. These two bugs show that the parsers and rasterizers behind that boundary are themselves attack surface, with denial of service and memory corruption as concrete outcomes for icon importers, asset pipelines and preview services. The question worth asking, as the article puts it, is not whether the scripts were removed, but which components read this file — and what happens when one of them fails.