CVE-2026-59942: Dompdf Resource Exhaustion DoS Vulnerability

CVE-2026-59942 Overview

CVE-2026-59942 is a Denial of Service (DoS) vulnerability in Dompdf, an HTML to PDF converter for PHP. Versions 3.1.5 and prior allow unauthenticated remote attackers to exhaust server resources by submitting a crafted HTML document. The attack uses a single image with massive dimensions (for example, 30,000x30,000 pixels) encoded in Base64 and wrapped in specific CSS containers. Internal image dimension checks can be bypassed with high-entropy content such as random noise, causing the PHP process to crash during the rendering phase. The issue is tracked under [CWE-400: Uncontrolled Resource Consumption] and has been patched in Dompdf version 3.1.6.

Critical Impact
An unauthenticated remote attacker can crash the PHP process and take down the web server by submitting a single crafted HTML document to any endpoint that converts user-supplied HTML to PDF using Dompdf.

Affected Products

Dompdf versions 3.1.5 and prior
PHP applications that convert user-supplied HTML content to PDF via Dompdf
Web applications exposing URL-to-PDF or HTML-to-PDF endpoints backed by Dompdf

Discovery Timeline

2026-07-28 - CVE-2026-59942 published to NVD
2026-07-30 - Last updated in NVD database

Technical Details for CVE-2026-59942

Vulnerability Analysis

The vulnerability resides in how Dompdf processes embedded images during PDF rendering. Dompdf performs early validation of image dimensions to prevent obviously oversized images from being processed. However, this validation can be bypassed by encoding a high-entropy image (such as random noise) in Base64 and wrapping it in specific CSS containers. Once the image passes the initial check, the renderer proceeds to allocate memory for the bounding box calculation and internal buffers. No cumulative limit is enforced on CPU time or memory usage per object during this phase. A single 30,000x30,000 pixel image is sufficient to exhaust the PHP process memory limit and terminate the worker.

Root Cause

The root cause is missing enforcement of resource limits after the initial dimension check. Dompdf validated width and height as integers but did not evaluate the estimated in-memory byte size of the decoded image. The Helpers::dompdf_getimagesize() helper returned only width, height, and type, providing the caller with insufficient data to reject images that would exceed memory budgets. The rendering path in src/Image/Cache.php therefore accepted images that later consumed all available process memory.

Attack Vector

An unauthenticated remote attacker submits a crafted HTML string containing a Base64-encoded image with extreme pixel dimensions and random-noise content. The request is delivered to any HTTP endpoint that forwards user-controlled HTML or URLs to Dompdf. When Dompdf renders the document, the PHP worker exhausts its memory allocation and crashes. Repeated requests degrade or fully deny service to the underlying web server.

php

// Security patch in src/Image/Cache.php - enforces image byte size limit
                 throw new ImageException("Image not readable or empty", E_WARNING);
             }
 
-            list($width, $height, $type) = Helpers::dompdf_getimagesize($resolved_url, $options->getHttpContext());
+            list($width, $height, $type, , , , , $imageBytes) = Helpers::dompdf_getimagesize($resolved_url, $options->getHttpContext());
 
             if (($width && $height && in_array($type, ["gif", "png", "jpeg", "bmp", "svg","webp"], true)) === false) {
                 throw new ImageException("Image type unknown", E_WARNING);
             }
 
+            $maxImageBytes = $options->getImageByteSizeLimit();
+            if ($width <= 0 || $height <= 0 || ($maxImageBytes > 0 && ($imageBytes === null || $imageBytes > $maxImageBytes))) {
+                throw new ImageException("Image dimensions or size exceed the configured limit", E_WARNING);
+            }
+
             if ($type === "svg") {
                 $parser = xml_parser_create("utf-8");
                 xml_parser_set_option($parser, XML_OPTION_CASE_FOLDING, false);

Source: GitHub Commit 7c65e7b

Detection Methods for CVE-2026-59942

Indicators of Compromise

HTTP POST requests to PDF generation endpoints containing large Base64 data:image/* payloads or <img> tags with abnormally large width and height attributes.
PHP worker processes terminated by Allowed memory size ... exhausted fatal errors in web server or PHP-FPM logs.
Sudden spikes in CPU or memory usage on web servers correlated with a single PDF generation request.
Repeated 500-class responses or connection resets from endpoints known to invoke Dompdf.

Detection Strategies

Inspect access logs for large request bodies to PDF conversion routes and correlate with PHP fatal error entries.
Monitor PHP-FPM child process restart rates and out-of-memory kills at the operating system level.
Add application-layer logging around Dompdf invocations to capture input size, image count, and rendering duration per request.

Monitoring Recommendations

Track PHP memory exhaustion errors and process crashes as high-priority events in centralized log analytics.
Alert on sustained elevated CPU or memory consumption on web workers serving PDF generation endpoints.
Rate-limit and log the identity or source IP of clients invoking HTML-to-PDF functionality to detect abuse patterns.

How to Mitigate CVE-2026-59942

Immediate Actions Required

Upgrade Dompdf to version 3.1.6 or later on all affected PHP applications.
Configure the new imageByteSizeLimit option to reject oversized images before rendering.
Restrict PDF generation endpoints to authenticated users where feasible and apply request rate limits.
Set conservative PHP memory_limit and max_execution_time values for workers that invoke Dompdf.

Patch Information

The fix is available in Dompdf v3.1.6. See GitHub Release v3.1.6 and the GHSA-f5gf-2cj8-52g2 advisory. The patch adds an imageByteSizeLimit option in src/Options.php, extends Helpers::dompdf_getimagesize() to return the estimated in-memory byte size, and enforces the byte-size check in src/Image/Cache.php. Review commits 7c65e7b and 89164ea for the full change set.

Workarounds

Sanitize or strip <img> tags and inline data: URIs from user-supplied HTML before passing it to Dompdf.
Enforce a maximum request body size at the reverse proxy or web server layer to block oversized payloads.
Run PDF conversion in a sandboxed worker with strict memory and CPU cgroup limits to contain crashes.
Disable remote image loading in Dompdf options where not required by the application.

bash

# Update Dompdf via Composer to the patched release
composer require dompdf/dompdf:^3.1.6

# Enforce the new image byte size limit (example: 5 MB)
# In PHP application code:
# $options = new Dompdf\Options();
# $options->set('imageByteSizeLimit', 5 * 1024 * 1024);
# $dompdf = new Dompdf\Dompdf($options);