CVE-2026-59941 in Dompdf
Summary
by MITRE • 07/29/2026
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.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 07/29/2026
The dompdf library vulnerability represents a critical resource exhaustion flaw that exploits improper input validation during image processing operations. This vulnerability affects versions 3.15 and prior of the HTML to PDF conversion tool, where the system accepts BMP image files without performing adequate bounds checking against declared dimensions. The flaw specifically manifests when the library processes a BMP file whose header contains inflated width and height values that significantly exceed the actual file size. The core technical issue stems from how dompdf handles image dimension validation within its processing pipeline, particularly in the GD library integration where imagecreatetruecolor() function is called with potentially malicious dimensions before any bounds verification occurs.
The operational impact of this vulnerability extends beyond simple memory consumption as it enables attackers to perform resource exhaustion attacks through minimal HTTP requests. The vulnerability allows for a 169-byte malicious BMP payload to trigger approximately 412 MB peak memory allocation during PDF rendering, representing roughly 12 times the memory consumption of a legitimate request. This amplification factor makes the vulnerability particularly dangerous in environments where computational resources are constrained or where resource limits are enforced. The attack vector is remarkably simple as it requires only a single HTTP request containing an inline data URI with base64-encoded malicious BMP content, eliminating the need for file uploads, remote fetching, or system-level access. This characteristic aligns with ATT&CK technique T1203 (Exploitation for Client Execution) and CWE-400 (Uncontrolled Resource Consumption).
The vulnerability's exploitability is further enhanced by its unauthenticated nature and the ability to execute the attack through web-based input processing without requiring special privileges or system-level access. The memory amplification effect occurs during the PDF rendering process when dompdf converts HTML containing the malicious image data, making it particularly dangerous in web applications that process user-controlled content. The fix implemented in version 3.16 addresses this issue by introducing proper bounds checking before image dimension processing and ensuring that header dimensions are validated against actual file size constraints. This remediation approach aligns with security best practices for input validation and resource management as outlined in industry standards such as CWE-704 (Incorrect Type Conversion or Cast) and follows established principles for preventing resource exhaustion attacks. The vulnerability demonstrates the critical importance of proper input validation in image processing libraries and highlights how seemingly benign file format handling can lead to severe resource consumption issues when dimension validation is bypassed.