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.
{
"cna_assigner": "GitHub_M",
"cwe_ids": [
"CWE-400"
],
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/59xxx/CVE-2026-59941.json"
}{
"extracted_events": [
{
"cpe": "cpe:2.3:a:dompdf_project:dompdf:*:*:*:*:*:*:*:*",
"range": [
{
"introduced": "0"
},
{
"fixed": "3.1.6"
}
],
"source": "CPE_RANGE"
},
{
"range": [
{
"fixed": "7c65e7bbeccf146b2409740405af73949ad129d0"
}
],
"source": "REFERENCES_COMMIT"
},
{
"original_tag": "v3.1.6",
"range": [
{
"fixed": "6d4b4eb8500f7a786da8868ba463a71b725a4005"
}
],
"source": "REFERENCES_TAG"
}
]
}