CVE-2026-59941: Dompdf: Uncontrolled resource consumption based on declared BMP dimensions

Severity: high (CVSS 7.5 v3.1)
Exploited in the wild: not listed in CISA KEV
EPSS: 0.6% probability of exploitation in the next 30 days
Public exploit or detection template: yes
Published: 2026-07-28 · updated 2026-08-04
Weakness: CWE-400

Description

Dompdf is an HTML to PDF converter for PHP. Versions 3.15 and prior accept a BMP image and generates a PDF-compatible PNG based only on its declared header dimensions and never bounds width × height before the image is converted through GD. A 58-byte BMP whose header declares e.g. 6000×6000 is accepted and later drives imagecreatetruecolor($width, $height) (and PHP's native BMP decoder) to allocate the full pixel canvas. A payload can fit in a single HTTP request: the BMP can be inlined as a data:image/bmp;base64,… URI inside attacker-controlled HTML, so no upload, no remote fetch, and no chroot-reachable file is required. I measured a 169-byte request driving a dompdf render to ~412 MB peak RSS and ~4.8 s of CPU/wall time, versus ~34 MB for an identically-sized benign request — roughly a 12× memory amplification per request, repeatable and unauthenticated. This issue has been fixed in version 3.16.

Affected products

dompdf: before 3.1.6 — fixed in 3.1.6
Packagist Dompdf/Dompdf: before 3.1.6; v0.6.0, v0.6.1, v0.6.2, v0.7.0, v0.7.0-beta, v0.7.0-beta2 (+33) — fixed in 3.1.6

How to fix

Upgrade to a fixed version: dompdf 3.1.6; Packagist Dompdf/Dompdf 3.1.6. Check the vendor advisory for mitigations.

References

Get alerted when CVE-2026-59941 or the next vulnerability affects your stack