GHSA-c3jg-qh8m-j3h2: Pip/cairosvg vulnerability
Summary
Rendering an untrusted SVG whose <path d="..."> contains many segments is O(n²) CPU. A single <path> under 1 MiB burns tens of seconds. Two independent O(n²) sites in cairosvg/path.py:
1. Tokenizer — the path-data parser consumes the d string with a while string: loop that repeatedly slices/re-scans the remaining string (each step is O(len remaining)), giving O(n²) over the whole attribute. 2. drawmarkers — marker handling drains node.vertices with while node.vertices: ... node.vertices.pop(0); list.pop(0) is O(n), so draining n vertices is O(n²).
Both are hit on a normal render path (svg2png/svg2pdf), attacker controls only the SVG document.
PoC (installed cairosvg 2.9.0)
python import cairosvg d = "M0 0 " + "L1 1 " 100000 svg = f'<svg xmlns="http://www.w3.org/2000/svg" width="10" height="10"><path d="{d}"/></svg>' cairosvg.svg2png(bytestring=svg.encode()) # ~4.4 s for a 488 KB doc
| path segments | SVG size | time | |---|---|---| | 50,000 | 244 KB | 1.14 s | | 100,000 | 488 KB | 4.36 s | | 200,000 | ~960 KB | ~18 s |
Doubling segments ≈ 4× time ⇒ quadratic. Sub-MiB input ⇒ ~18 s CPU; any service rendering user-supplied SVG (thumbnails, avatars, PDF export) is a DoS target.
Reachability
Public API svg2png / svg2pdf / svg2ps on an untrusted SVG string.
Suggested fix
Tokenize with a single forward scan / index (or re.finditer) instead of re-slicing the remainder; drain vertices with an index or collections.deque.popleft instead of list.pop(0). Optionally cap path-segment count.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pip/cairosvgto a version that resolves this vulnerability.Fixed in 2.9.1 - Compensating control
In cairosvg/path.py, tokenize path data with a single forward scan or re.finditer instead of repeatedly slicing and rescanning the remaining string; in draw_markers, drain node.vertices with an index or collections.deque.popleft instead of list.pop(0).
- Compensating control
Optionally cap the number of path segments accepted when rendering untrusted SVG documents.
Event History
Frequently Asked Questions
Which deployments are realistically exposed?
Services or applications that render user-supplied SVG documents with CairoSVG through normal svg2png or svg2pdf processing are exposed. An attacker only needs control of the SVG document.
Does exploitation require a large upload or special rendering option?
No. The demonstrated input uses a single path attribute with many segments; a document below 1 MiB can consume tens of seconds of CPU. The issue is reached on the normal render path.
What is the practical impact of repeated requests?
The work grows quadratically with the number of path segments, so increasing segment count can sharply increase CPU time. Repeated rendering of crafted SVGs can therefore exhaust rendering capacity or cause request delays.