Dompdf accepts BMP images based solely on declared header dimensions without bounding width × height before conversion with GD. A 58‑byte BMP with a header such as 6000×6000 triggers imagecreatetruecolor and PHP’s native BMP decoder to allocate a 6000×6000 canvas, consuming large amounts of memory and CPU. A single HTTP request containing a data:image/bmp;base64… URI can trigger this behavior, generating a 412 MB peak RSS and nearly five seconds of CPU time compared to 34 MB for a benign request— a more than twelvefold memory amplification. This flaw allows unauthenticated attackers to cause resource exhaustion and deny service.

Versions of the dompdf HTML‑to‑PDF library prior to 3.16 are affected. The vendor identified in the CNA is dompdf:dompdf, with the vulnerable releases being 3.15 and earlier. The fix is included in version 3.16 and later.

The CVSS score of 6.3 suggests a moderate severity, while the EPSS score of less than 1 % indicates a low probability of exploitation at the time of analysis. The vulnerability is not listed in the CISA KEV catalog. Attackers can exploit it via an unauthenticated HTTP request containing a data URI‑encoded BMP, requiring no authentication, uploads, or remote file fetches. The impact is a denial of service that can affect one or many users depending on the target application’s deployment scale.