Pillow: EPS load(scale) lets Ghostscript render past the decompression bomb limit (CVE-2026-112899)

The vulnerability in Pillow's EpsImagePlugin arises from the load(scale) method, which requests Ghostscript to render an EPS image at a resolution scaled by the caller's scale parameter. Pillow only performs the decompression bomb size check on the unscaled image dimensions declared in the EPS file, allowing Ghostscript to produce an image several times larger than the configured limit. For example, an EPS declaring 9000×9000 pixels passes the initial check, but loading it with scale=2 causes Ghostscript to render an 18000×18000 pixel image, exceeding the decompression bomb threshold by 3.6 times. The oversized image results in large temporary files (e.g., 972 MB) and increased processing time. The decompression bomb error is only raised after Ghostscript finishes rendering, so the resource exhaustion occurs before Pillow intervenes. This issue has existed since Pillow 2.5.0 and is similar to a previously fixed WMF load(dpi) vulnerability. A patch is available that applies the decompression bomb check to the scaled size before invoking Ghostscript.

An attacker who can supply a crafted EPS file and control the scale parameter can cause Ghostscript to render images significantly larger than Pillow's decompression bomb limit. This leads to excessive CPU usage and large temporary disk space consumption, potentially causing denial of service conditions on systems processing untrusted EPS files. However, Pillow's internal memory allocation remains bounded, and no memory corruption occurs. The vulnerability does not allow arbitrary code execution or privilege escalation but can degrade service availability.

A patch is available for Pillow that applies the decompression bomb check to the scaled image size before invoking Ghostscript, preventing oversized renders. Users should upgrade to a fixed version of Pillow (13.0.0 or later). Until patched, avoid processing untrusted EPS files with scaling or implement external controls to limit resource usage by Ghostscript. Since this is a local library vulnerability, sandboxing or limiting Ghostscript execution time may also help mitigate impact.