SVG Dimension Capping Bypass via XML Comment Injection in @dicebear/converter ensureSize()
Date: 2026-03
Affected: npm/@dicebear/converter
Attack vector: dos
Category: vulnerability-disclosure
Severity: High
CVE: CVE-2026-33418
CWE: CWE-185
CVSS: 7.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)

## Summary The `ensureSize()` function in `@dicebear/converter` used a regex-based approach to rewrite SVG `width`/`height` attributes, capping them at 2048px to prevent denial of service. This size capping could be bypassed by crafting SVG input that causes the regex to match a non-functional occurrence of `<svg` before the actual SVG root element. When the SVG is subsequently rendered via `@resvg/resvg-js` on the Node.js code path, it renders at the attacker-specified dimensions, potentially causing out-of-memory crashes. ## Details The vulnerable function used `String.prototype.replace()` with a non-global regex to find and rewrite the first `<svg` tag's dimensions. Since the regex does not distinguish between `<svg` appearing inside non-element XML constructs and the actual SVG root element, a crafted input can cause the regex to match a decoy instead of the real element, leaving the actual SVG dimensions unclamped. In the Node.js rendering path, `renderAsync` from `@resvg/resvg-js` was called without a `fitTo` constraint, so it would render at whatever dimensions the SVG element specified — potentially allocating gigabytes of memory. The browser code path is **not** vulnerable because it uses the clamped `size` return value from `ensureSize()` to set `canvas.width` and `canvas.height` directly. ## Impact Any application that passes untrusted or user-supplied SVG content through `@dicebear/converter`'s Node.js conversion functions (`toPng`, `toJpeg`, `toWebp`, `toA


Mitigations:

Architectural layers (MAESTRO):