CVE-2026-96637

Summary

SpiderImagePlugin's seek() bypasses the decompression bomb check, allowing a tiny (<1KB) crafted SPIDER stack file to trigger a multi-gigabyte allocation on im.load().

Affected versions

All versions up to and including current HEAD (v13.0.0.dev0, commit e7a7ea84)

Root cause

Image.open() runs Image._decompression_bomb_check(im.size) exactly once, in _open_core (src/PIL/Image.py:3668), right after the initial _open().

SPIDER stack files are multi-frame: SpiderImageFile.seek(frame) (SpiderImagePlugin.py:179-190) computes an attacker-influenced stkoffset and calls self._open() AGAIN directly (line 190) — NOT through Image.open(). _open() re-parses a fresh 27-float header at that offset and reassigns:

self._size = int(h[12]), int(h[2])      # SpiderImagePlugin.py:131

straight from unvalidated header floats (isSpiderHeader only checks internal labrec*lenbyt==labbyt consistency, never bounds nsam/nrow). No bomb check runs on this new size.

On the subsequent load(), ImageFile.load_prepare() (ImageFile.py:436-437) executes self.im = Image.core.new(self.mode, self.size) with the unchecked, attacker-chosen size. Mode is always "F" (4 bytes/pixel), so e.g. 40000x40000 = 6.4 GB.

Why this is a real bug

Sibling multi-frame plugins DO re-check on their alternate paths:

• GifImagePlugin.py:286 - Image._decompression_bomb_check(self._size) (in seek)
• TiffImagePlugin.py:1309 - Image._decompression_bomb_check(self._tile_size)
• IcnsImagePlugin.py:121/138, IcoImagePlugin.py:236/240 (sub-image selection)

SpiderImagePlugin has NO bomb check anywhere. This is the same class of bug just fixed for GdImageFile (GHSA-phj9-mv4w-65pm) and the FontFile classes (GHSA-5x94/8v84/45hq): an allocation reached on a non-Image.open() path sized by an attacker header field, independent of the one-time pixel bomb check.

Reproduction

Python 3.13, Pillow HEAD e7a7ea84

Attached: pillow_poc_spider_bomb.py

Sets Image.MAX_IMAGE_PIXELS=5000, then:

• CONTROL: Image.open(standalone 100x100 SPIDER) -> DecompressionBombWarning fires correctly.
• BYPASS: Image.open(stack, frame0=1x1) passes; im.seek(1) sets size (100,100) with NO DecompressionBombWarning/Error -> the check is bypassed.

Real-world impact: a large frame-1 nsam/nrow (e.g. 40000x40000) causes im.load() to allocate ~6.4 GB (mode F) with the bomb check fully bypassed, from a file under 1 KB.

Suggested fix

Call Image._decompression_bomb_check(self.size) at the end of SpiderImageFile._open() (or in seek() after _open()), mirroring GifImagePlugin / TiffImagePlugin. Optionally validate nsam/nrow are positive and sane in _open().

Credit: Yazan Balawneh - CyStack Security Team pillow_poc_spider_bomb.py

Pillow is a Python imaging library. Prior to 13.0.0, SpiderImageFile.seek() in src/PIL/SpiderImagePlugin.py reparses a later SPIDER stack frame and replaces self._size without rerunning Image._decompression_bomb_check(). A tiny file can use a safe first frame to pass Image.open() and then declare very large dimensions in a later mode F frame. Loading that frame allocates approximately four bytes per attacker-declared pixel and can consume multiple gigabytes of memory. This issue is fixed in version 13.0.0.

Pillow is a Python imaging library. Prior to 13.0.0, SpiderImageFile.seek() in src/PIL/SpiderImagePlugin.py reparses a later SPIDER stack frame and replaces self._size without rerunning Image._decompression_bomb_check(). A tiny file can use a safe first frame to pass Image.open() and then declare very large dimensions in a later mode F frame. Loading that frame allocates approximately four bytes per attacker-declared pixel and can consume multiple gigabytes of memory. This issue is fixed in version 13.0.0.

Pillow is a Python imaging library. Prior to 13.0.0, SpiderImageFile.seek() in src/PIL/SpiderImagePlugin.py reparses a later SPIDER stack frame and replaces self._size without rerunning Image._decompression_bomb_check(). A tiny file can use a safe first frame to pass Image.open() and then declare very large dimensions in a later mode F frame. Loading that frame allocates approximately four bytes per attacker-declared pixel and can consume multiple gigabytes of memory. This issue is fixed in version 13.0.0.

TuxCare rebuilt pillow to address 6 CVEs. Fixed in 11.3.0.post9+tuxcare.

TuxCare rebuilt pillow to address 6 CVEs. Fixed in 11.2.1.post11+tuxcare.

TuxCare rebuilt pillow to address 3 CVEs. Fixed in 10.4.0.post14+tuxcare.

TuxCare rebuilt pillow to address 3 CVEs. Fixed in 9.5.0.post12+tuxcare.

TuxCare rebuilt pillow to address 2 CVEs. Fixed in 9.4.0.post13+tuxcare.

TuxCare rebuilt pillow to address 2 CVEs. Fixed in 8.4.0.post12+tuxcare.

Root has patched CVE-2026-96637 in the pillow package for Root:PyPI. Multiple fixed versions available.

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).