CVE-2026-59941

Dompdf, a PHP HTML-to-PDF converter, in versions 3.15 and earlier trusts the dimensions declared in a BMP image header and never bounds width x height before allocating a pixel canvas through GD (imagecreatetruecolor), so a tiny BMP can trigger outsized allocations (CWE-400, uncontrolled resource consumption). An attacker triggers it by embedding an inlined data:image/bmp;base64 URI in HTML that the application converts with dompdf — no upload, remote fetch, or chroot-reachable file is required — and a ~170-byte request was measured to drive ~412 MB peak memory and ~4.8 seconds of CPU versus ~34 MB for a benign request, roughly 12x amplification per request. The attacker gains no code execution or data access, but can repeatedly exhaust memory and CPU on the PDF-rendering path, degrading service or, with enough concurrent requests, causing denial of service (CVSS 4.0 rates availability impact as low, with no confidentiality or integrity impact). Any PHP application that converts attacker-controlled HTML to PDF using dompdf 3.15 or earlier is affected. No in-the-wild exploitation is currently known; a public security advisory with proof-of-concept measurements exists, and the issue is fixed in version 3.16.

What to do: Upgrade dompdf to version 3.16 or later. If upgrading is not immediately possible, sanitize or restrict image sources in HTML sent to dompdf (especially data: image URIs), validate and bound BMP dimensions before rendering, and limit concurrent PDF-render processes to contain memory spikes. Audit whether your application converts user-supplied HTML (invoices, uploads, generated reports) through dompdf, since only those attacker-reachable flows expose you to this flaw.