CVE-2026-31899

What it actually does

CairoSVG resolves SVG <use> references in cairosvg/defs.py without adequate cycle detection or expansion bounds. A small SVG whose <use> graph is recursive or mutually referential is expanded exponentially during conversion, driving unbounded CPU use and stalling or killing the renderer. Confidentiality and integrity are unaffected (availability-only); any network-reachable conversion path inherits unauthenticated reachability because the flaw requires no privileges or user interaction.

Why it matters to the business

Any product that converts untrusted SVG with courtbouillon cairosvg (previews, thumbnails, document/PDF pipelines, CMS media) can have rendering workers pinned by a tiny file, causing timeouts, queue backup, and outages of image-processing features. Downstream Python applications inherit the same availability risk. The issue is not in CISA KEV, is not associated with ransomware, has no known exploit maturity, and EPSS remains low (~0.005, only +5% over 30 days), so mass exploitation is not indicated; residual risk is operational downtime wherever untrusted SVG is still converted and no listed patched release is available ~199 days after publication.

How an attack unfolds

An attacker who can submit SVG to a CairoSVG-backed converter crafts a compact document whose <use> elements reference definitions in a cyclic or rapidly amplifying way. On parse, defs.py recursively expands those references until the process saturates CPU or is killed by a timeout/OOM policy. If the conversion API, upload handler, or ingest worker is reachable without authentication, a single request can take a worker offline; repeating submissions sustains denial of service. No named threat actors or public exploit programs are associated with this CVE.

How to fix it

No fixed versions were published for courtbouillon cairosvg in the supplied advisory data—monitor upstream Kozea/CairoSVG for an official release that adds cycle detection and a hard recursion/expansion cap in defs.py, and upgrade as soon as it exists. Until then: do not convert untrusted SVG; sandbox conversion in isolated processes with strict CPU time, memory, and wall-clock limits; cap upload size; strip or reject documents with dense or self-referential <use> graphs at the edge; and, if you must fork, add visited-id tracking and a maximum expansion depth before resolving defs.

How to confirm the fix worked

Inventory Python environments and lockfiles for cairosvg/courtbouillon cairosvg and record versions. After a vendor patch exists, confirm the installed package meets that version and that cairosvg/defs.py contains cycle/visited-set and depth-limit guards. Verify conversion workers enforce timeouts and cgroup CPU/memory limits. Do not validate with malicious SVG samples; use version checks, code review of defs resolution, and load tests with benign SVGs only.

Typical attack path

1. Locate a service that renders or converts SVG with CairoSVG (upload, preview, thumbnail, or document ingest).
2. Submit a small SVG that uses recursive or cyclic <use> references against shared defs.
3. Trigger server-side conversion so cairosvg/defs.py expands the graph.
4. Consume CPU on the conversion worker until hang, timeout, or process death.
5. Repeat submissions as needed to keep the worker pool exhausted.

How to detect it

This is a resource-exhaustion event, not an implant: look for conversion workers stuck at high CPU, repeated restarts, or timeouts correlated with SVG uploads rather than new binaries or persistence. Review application and reverse-proxy logs for image/svg+xml (or .svg) requests followed by 5xx, gateway timeouts, or worker kill; process tables for python/cairosvg renderers at 100% CPU; and exception logs/stack traces mentioning cairosvg/defs.py, RecursionError, or conversion deadlines. Hunt historically around SVG ingest endpoints from the publication date onward; absence of malware IOCs does not rule out abuse.

• cairosvg/defs.py
• RecursionError
• image/svg+xml
• Content-Type: image/svg+xml
• <use
• xlink:href
• href="#
• cairosvg
• courtbouillon

What your security team should do

• Immediately stop converting untrusted SVG with unpatched CairoSVG, or isolate converters behind timeouts, CPU/memory cgroups, and process sandboxes.
• Inventory all uses of courtbouillon cairosvg (direct and transitive) and subscribe to upstream releases so you can upgrade the moment a fixed version is published.
• Add edge rejection for oversized SVGs and for documents with high <use> density or self-referential href/xlink:href targets.
• Prioritize internet-facing conversion/upload endpoints; this is availability-only, not KEV, and EPSS is low, so treat as operational hardening rather than emergency ransomware response.
• Ensure conversion failures, worker restarts, and CPU saturation on renderer pools generate alerts.