Your SVG Has No Scripts. Is It Safe to Process?

Two recent vulnerability reports

An application accepts an SVG icon, removes scripts and event handlers, then generates a preview. Has it made the file safe? It has addressed one category of risk. The next question is what happens inside the software that reads and renders the file. Two recent vulnerability reports show why that distinction matters for developers building icon importers, asset pipelines and preview services.

Bugs that do not need JavaScript

• librsvg - CVE-2026-96889
  Concerns nested XML inclusions with duplicate entity declarations. During processing, an XML entity could be freed while the parser was still using it: a use-after-free error. The RustSec advisory, issued on September 23, 2026, lists fixes in versions 2.63.2 and 2.62.4 for the respective release branches.

• NanoSVG - CVE-2026-88366
  Extreme arc radius values can make an intermediate calculation produce NaN - “not a number.” Converting that value to an integer without checking it introduces undefined behavior. The report demonstrates the problem with a runtime sanitizer; the associated CVE describes a potential denial of service. Neither mechanism requires JavaScript.

These are issues in specific implementations and versions. They do not establish that every SVG renderer is vulnerable. They do show why “contains no scripts” is an incomplete security test.

The file passes through more than one component

Consider a typical icon upload feature. Before an icon reaches the interface, it might pass through an XML parser, a sanitizer, an optimizer and a rasterizer that creates thumbnails. Each component processes input supplied by someone else. Even the sanitizer has to read the original file. A later filter cannot protect an earlier component that has already encountered a malicious input.

Four layers of defense

1. Sanitize for the intended use
   Define which elements, attributes and references your application needs. A static icon usually requires a smaller feature set than an interactive SVG document. Use a maintained sanitizer with an explicit policy. Sanitization remains useful, but its output should not be treated as proof that every downstream parser can safely process the file.

2. Track and patch the actual dependencies
   Identify what parses and renders SVGs in your deployed application, including libraries bundled inside converters or image-processing tools. Check affected versions and available fixes. Updating your own code does not necessarily update the library inside a thumbnail generator or conversion service.

3. Bound the work
   Set limits on upload size, rendering dimensions, execution time and memory. A small file is not necessarily cheap to process. Complex geometry or other expensive input can demand more work than its file size suggests. Limits help contain excessive resource consumption; they do not repair memory-safety bugs.

4. Isolate untrusted processing
   Where practical, run conversion and preview generation in a restricted worker with minimal permissions and no unnecessary network or filesystem access. Design the application to handle a failed worker without taking down the main service. Apply these protections from the first component that reads untrusted input, including sanitization.

Ask what happens when processing fails. These layers address different failure modes:

• Sanitization restricts content.
• Patches fix known defects.
• Limits bound resource use.
• Isolation reduces the consequences of a failure.

For an SVG icon pipeline, the useful question is broader than “Did we remove the scripts?” Which components read this file, and what happens if one of them fails?

Sources: RustSec: librsvg use-after-free advisory NanoSVG: original arc conversion bug report CVE-2026-88366 details