CVE-2026-112899

============================================================================
EPS load(scale) lets Ghostscript render past the decompression bomb limit
Location: src/PIL/EpsImagePlugin.py:92  in Ghostscript()
Commit:   a707c6b21c313880d0771e54965d142dd42358b6
============================================================================

When an application opens an untrusted Encapsulated PostScript file and asks Pillow to render it at a larger scale, Pillow has Ghostscript produce an image several times bigger than Pillow's configured size limit allows. The size check runs only after Ghostscript has finished rendering and written the full raw image to a temporary file. An attacker who can upload a file of about 100 bytes makes each such request spend scale² times the Ghostscript rendering work and temporary disk space that the limit is meant to permit. For example, at scale 2 that is a 972 MB temporary file.

The cause is in Ghostscript() in src/PIL/EpsImagePlugin.py. It multiplies the file-declared size by the caller's scale (lines 93-94) and passes the product to gs as the -g output geometry. It never calls Image._decompression_bomb_check() on the scaled size. The only check is the one Image.open() ran on the unscaled size, so a file declaring 9000×9000 passes, and load(scale=2) then asks Ghostscript for 18000×18000 (3.6× MAX_IMAGE_PIXELS). A file declaring 18000×18000 directly would be refused before Ghostscript ever ran. DecompressionBombError fires only when Pillow reopens the output file, so Pillow's own in-process allocation stays bounded and there is no memory corruption.

The effect is a constant-factor overshoot rather than an unbounded one, for three reasons:

• The multiplier is an integer chosen by the application, not by the file.
• With the default warning filter, Image.open() already lets files up to 2× the limit reach Ghostscript at scale=1.
• Any application feeding untrusted files to Ghostscript is already exposed to a tiny file that keeps Ghostscript busy indefinitely, since gs runs with no timeout.

This is the EPS counterpart of the WMF load(dpi) gap closed in af70b075a. It has been present since the decompression-bomb limit was introduced in ce2955ec7 (2.5.0). The attached reproducer stubs out Ghostscript and shows a 76-byte file passing Image.open() and reaching gs with -g18000x18000. A one-line patch mirroring the WMF check is included.

Details

EpsImageFile.load(scale=N) (the documented way to rasterise an EPS at higher resolution) renders width*N × height*N pixels through Ghostscript, but the only decompression-bomb check on the way is the one Image.open() ran on the unscaled, file-declared width × height. The scaled product is never passed to Image._decompression_bomb_check() before gs is started.

This 111-byte EPS declares 9000×9000 = 81,000,000 pixels, below the default MAX_IMAGE_PIXELS (89,478,485), so Image.open() accepts it without even a warning:

%!PS-Adobe-3.0 EPSF-3.0
%%BoundingBox: 0 0 9000 9000
%%EndComments
0 0 moveto 9000 9000 lineto stroke
showpage

im.load(scale=2) on it then executes

gs -q -g18000x18000 -r144.000000x144.000000 -dBATCH -dNOPAUSE -dSAFER -sDEVICE=pnmraw -sOutputFile=/tmp/tmpXXXX -c 0 0 translate -f attack.eps -c showpage

i.e. asks Ghostscript for an 18000×18000 = 324,000,000-pixel raster (3.6× MAX_IMAGE_PIXELS), whose pnmraw output is a 972,000,019-byte file in the temp directory. An EPS that declares 18000×18000 directly is rejected by Image.open() with DecompressionBombError before Ghostscript is ever run; via scale=2 the same raster is rendered first and the DecompressionBombError only appears afterwards, when Pillow opens the file Ghostscript produced. (Between 1× and 2× MAX_IMAGE_PIXELS, Image.open() only emits DecompressionBombWarning, so with the default warning filter an EPS declaring e.g. 13377×13377 is already rendered at scale=1 — a 537 MB…

Pillow is a Python imaging library. In versions 2.3.0 through 12.3.0, EPS rendering does not validate the scaled image dimensions before invoking Ghostscript. Applications that process untrusted EPS or PostScript files using an application-selected scale greater than one can incur excessive Ghostscript CPU and temporary disk consumption. In versions with decompression-bomb protection, the scaled output is checked only after Ghostscript has completed rendering, allowing resource consumption beyond the configured pixel limit. The amplification depends on the scale selected by the application, not an attacker-controlled scale value. This issue is fixed in version 13.0.0.

TuxCare rebuilt pillow to address 11 CVEs. Fixed in 11.3.0.post7+tuxcare.

TuxCare rebuilt pillow to address 11 CVEs. Fixed in 11.2.1.post9+tuxcare.

TuxCare rebuilt pillow to address 11 CVEs. Fixed in 10.4.0.post11+tuxcare.

TuxCare rebuilt pillow to address 11 CVEs. Fixed in 9.5.0.post9+tuxcare.

TuxCare rebuilt pillow to address 10 CVEs. Fixed in 9.4.0.post10+tuxcare.

TuxCare rebuilt pillow to address 9 CVEs. Fixed in 8.4.0.post9+tuxcare.

This update for python-Pillow fixes the following issues:

• CVE-2026-96636: decompression-bomb protection bypass via multi-frame seek() in MPO and DCX (bsc#1286802).
• CVE-2026-96637: decompression bomb check bypass in SpiderImagePlugin.seek() leads to unbounded allocation DoS (bsc#1286801).
• CVE-2026-96640: PDF append accepts malformed shared page-tree DAG, which can cause resource exhaustion (bsc#1286798).
• CVE-2026-96641: reachable undefined behavior in native integer operations can lead to denial of service or logic integrity compromise (bsc#1286797).
• CVE-2026-96642: TarIO negative size field causes infinite CPU-spin loop (bsc#1286796).
• CVE-2026-112390: Denial of Service via infinite loop during crafted MIC image parsing (bsc#1286256).
• CVE-2026-112391: Denial of Service via unbounded recursion in PDF parser (bsc#1286273).
• CVE-2026-112392: Denial of Service via zero-size images in rank filters (bsc#1286287).
• CVE-2026-112393: heap buffer overflow and stale-heap disclosure in _tiffWriteProc when saving compressed TIFF data (bsc#1286325).
• CVE-2026-112394: P;2L and P;4L decoders may read 1 to 3 bytes past the passed buffer size (bsc#1286311).
• CVE-2026-112397: out-of-bounds access in _imagingmorph on a zero-width image (bsc#1286314).
• CVE-2026-112398: heap buffer overflow in FPX JPEG decoding can lead to code execution (bsc#1286406).
• CVE-2026-112399: Denial of service via crafted APNG image (bsc#1286368).
• CVE-2026-112400: Denial of Service via memory exhaustion from crafted GIF image (bsc#1286370).
• CVE-2026-112401: Denial of Service via crafted GIF comments (bsc#1286372).
• CVE-2026-112402: Denial of service via double free during image transformation (bsc#1286381).
• CVE-2026-112403: heap buffer overflow in ImagingJpegDecode allows for code execution (bsc#1286405).
• CVE-2026-112405: NULL pointer dereference in Image.merge via an unvalidated band 0 (bsc#1286404).
• CVE-2026-112406: infinite loop in PdfParser.rewrite_pages on page tree Parent cycle (bsc#1286403).
• CVE-2026-112891: quadratic GIF comment copying during save (bsc#1286402).
• CVE-2026-112892: MSP RLE decoder expands a tiny file into unbounded memory (bsc#1286401).
• CVE-2026-112894: Denial of Service via crafted multi-frame image conversion (bsc#1286408).
• CVE-2026-112895: Denial of service via crafted PDF during append operations (bsc#1286411).
• CVE-2026-112896: TIFF encoder ColorMap plane-size mismatch causes a heap out-of-bounds read (bsc#1286400).
• CVE-2026-112897: TiffDecode returns uninitialized memory as pixels for short JPEG strips (bsc#1286398).
• CVE-2026-112899: EPS load(scale) lets Ghostscript render past the decompression bomb limit (bsc#1286489).
• CVE-2026-112900: argument Injection in Ghostscript call can lead to remote code execution (bsc#1286397).
• CVE-2026-112901: ReDoS in XbmImagePlugin can be triggered by 512-byte file (bsc#1286396).
• CVE-2026-112902: memory disclosure and segfault in libtiff encoder via crafted TIFF tags (bsc#1286804).