The CVSS 7.5 rating for this dompdf vulnerability obscures a genuinely dangerous attack vector. The 12× memory amplification per request, combined with zero authentication requirements and a self-contained attack surface using data URIs, creates efficiency that most CVEs at this score cannot match. A single HTTP request can exhaust significant server memory — no multi-step chains, no authenticated access, no attacker infrastructure required.
The exploitation pathway is invisible to most threat models. Security teams auditing dompdf deployments focus on file upload endpoints or remote resource fetching. They rarely treat HTML rendering of untrusted content as an attack surface requiring the same scrutiny. But this vulnerability surfaces wherever dompdf processes attacker-controlled HTML — comment systems, invoice generators, templating pipelines that accept user markup. The data URI mechanism means no file ever touches the filesystem in a way traditional upload hardening would catch.
The technical root cause is imagecreatetruecolor() being called with attacker-controlled dimensions from BMP headers without validating declared dimensions against actual image data. This is a trust assumption pattern, not an isolated flaw. The fix in version 3.16 almost certainly added a bounds check specifically to the BMP handler rather than auditing every imagecreatetruecolor call across PNG, JPEG, GIF, WEBP, and TIFF handlers. The historical pattern across image processing libraries suggests siblings likely exist.
Operationally, treat this as a 9.0+ priority despite the 7.5 CVSS. The availability impact of memory exhaustion at 12:1 amplification is structurally undervalued by CVSS, which was designed around confidentiality/integrity impact. Your deployment scope includes any endpoint passing user-supplied HTML to dompdf — not just explicit file uploads. Inventory templating pipelines, invoice generators, and comment-to-PDF workflows. Apply the same input sanitization rigor you'd apply to file uploads, not just HTML parsing.