Librsvg use-after-free in XInclude parsing patched across multiple versions

Librsvg, a Rust library for rendering SVG files, contains a high-severity vulnerability that triggers a use-after-free error. The flaw occurs when the library processes SVG documents containing nested XInclude directives alongside XML entity declarations with duplicate names. This specific combination causes the underlying libxml2 parser to free memory that is still in active use by the outer parsing context, leading to a use-after-free condition.

The risk

The vulnerability, identified as CVE-2026-96889, arises from how Librsvg manages entity maps during complex XML parsing operations. According to the GitHub advisory, when libxml2 expands an internal entity, a recursive XInclude can parse another document that declares an entity with the same name. Both parsing operations share the same `XmlState` entity map on the Librsvg side. This shared state creates a conflict where the `entity_insert()` function replaces the first entry, triggering a `Drop` implementation that calls `xmlFreeNode()`.

Who is exposed

Multiple version lines of the Rust Librsvg package are vulnerable to this issue. Versions prior to 2.57.5 are affected, with 2.57.5 providing the fix. For the 2.60 branch, versions from 2.60.0-beta.0 up to 2.60.3 are vulnerable, with 2.60.3 being the patched release. Similarly, versions >= 2.61.0 and < 2.61.5 are exposed, with 2.61.5 resolving the issue. The 2.62 branch requires updating to 2.62.4, and the 2.63 branch requires 2.63.2.

Cost and compliance

The GitHub advisory assigns a high severity rating to CVE-2026-96889. The technical root cause involves the outer `xmlCtxtParseEntity()` function continuing to use a freed 144-byte `xmlEntity` pointer after the inner parse has released it. The fix, implemented in commit 8a1b0cd319e9af2d1e9cf878081dd77f227a0504, ensures that Librsvg no longer frees `xmlEntity` pointers that libxml2 is still actively using. This change prevents the use-after-free error described in the advisory.

What to watch

Security teams should verify which version of Librsvg their applications depend on, particularly if they process untrusted SVG files. Organizations using Rust-based image processing pipelines should prioritize updating to the patched versions listed in the advisory. Monitoring for unusual memory access patterns or crashes in services that render SVG content can help identify exploitation attempts before they escalate.

Signals worth monitoring

Teams usually detect this type of memory corruption through application crashes or segmentation faults in services processing SVG files. Check whether logs show unexpected termination of rendering processes or repeated restarts of image-handling services. Look for anomalous memory usage spikes in applications that parse complex XML structures. First containment moves involve isolating affected services and restricting input to trusted sources only. Verify that error logs contain references to `xmlFreeNode` or entity parsing failures. Ensure that monitoring tools capture detailed stack traces for any crashes related to XML parsing libraries.

What to do and how to stay safe: Librsvg

• Audit your Rust dependencies to identify if you are using a vulnerable version of Librsvg.
• Update to the patched versions (2.57.5, 2.60.3, 2.61.5, 2.62.4, or 2.63.2) as soon as possible.
• Restrict SVG input to trusted sources to reduce the risk of processing malicious files.
• Monitor application logs for crashes or errors related to XML entity parsing or memory access violations.

Step-by-step guide: Vulnerability Prioritization: Fix What Actually Matters First

General security guidance from the SecOps Signal newsroom. It is not confirmed advice from the organisations named in this story.

Frequently asked questions

What is the CVE ID for this Librsvg vulnerability?

The CVE ID for this vulnerability is CVE-2026-96889.

Which versions of Librsvg are patched?

Patched versions include 2.57.5, 2.60.3, 2.61.5, 2.62.4, and 2.63.2.

What causes the use-after-free error in Librsvg?

The error is caused by nested XIncludes with duplicate XML entity names, leading to premature memory freeing.