CVE-2026-96637: Pillow: Decompression bomb check bypass in SpiderImagePlugin.seek() leads to unbounded allocation DoS
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.decompressionbombcheck(im.size) exactly once, in opencore (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 labreclenbyt==labbyt consistency, never bounds nsam/nrow). No bomb check runs on this new size.
On the subsequent load(), ImageFile.loadprepare() (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.decompressionbombcheck(self.size) (in seek) - TiffImagePlugin.py:1309 - Image.decompressionbombcheck(self.tilesize) - 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: pillowpocspiderbomb.py
Sets Image.MAXIMAGEPIXELS=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.decompressionbombcheck(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 pillowpocspiderbomb.py
Other sources
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.decompressionbombcheck(). 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.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pip/pillowto a version that resolves this vulnerability.Fixed in 13.0.0 - Upgrade
Upgrade
bitnami/pillowto a version that resolves this vulnerability.Fixed in 13.0.0 - Upgrade
Upgrade
Pillowto a version that resolves this vulnerability.Fixed in 13.0.0
Event History
Frequently Asked Questions
Who is exposed to this issue?
Applications using Pillow versions before 13.0.0 are exposed if they open or load attacker-controlled SPIDER stack files, particularly when processing later frames in the stack.
What does an attacker need to exploit it?
An attacker needs to provide a crafted SPIDER file with an initially safe frame that passes Image.open(), followed by a later mode F frame declaring very large dimensions. Loading that later frame can trigger multi-gigabyte memory consumption.
Is opening the file alone sufficient to trigger the allocation?
No. The crafted first frame is intended to pass Image.open(); the large allocation occurs when the later malicious frame is loaded after SpiderImageFile.seek() reparses it.
What is the remediation?
Upgrade Pillow to version 13.0.0, which fixes the missing decompression-bomb check when seeking to later SPIDER stack frames.