Live › vulnerability › CVE-2026-96637
Go to dashboardPillow's SPIDER image plugin skips the decompression bomb size check when seeking to later frames, so a tiny crafted SPIDER stack file can make im.load() allocate multiple gigabytes. An attacker who gets a malicious image processed by an app using Pillow can exhaust memory and cause denial of service.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 19:11 UTC, 3h before NVD. All times on this page are UTC.
| Product | Ecosystem | Affected | Fixed in |
|---|---|---|---|
| pillow | pypi | < 13.0.0 | 13.0.0 |
pip show pillow and check whether the version is below 13.0.013.0.0 or later (pip install -U )pillow>=13.0.0Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
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().
All versions up to and including current HEAD (v13.0.0.dev0, commit e7a7ea84)
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.
Sibling multi-frame plugins DO re-check on their alternate paths:
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.
Python 3.13, Pillow HEAD e7a7ea84
Attached: pillow_poc_spider_bomb.py
Sets Image.MAX_IMAGE_PIXELS=5000, then:
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.
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
This page as .md · .json · in your agent: get_signal("CVE-2026-96637")
GitHub Advisory Database, CC-BY 4.0 · NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.