Summary
Pillow: Decompression bomb check bypass in SpiderImagePlugin.seek() leads to unbounded allocation DoS
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.
Impact
Crafted input forces the application to consume excessive CPU, memory, or other resources, degrading or denying service. Typical impact: denial of service.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
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
Frequently Asked Questions
- What is CVE-2026-96637? CVE-2026-96637 is a high-severity uncontrolled resource consumption vulnerability in pillow (pip), affecting versions < 13.0.0. It is fixed in 13.0.0. Crafted input forces the application to consume excessive CPU, memory, or other resources, degrading or denying service.
- Which versions of pillow are affected by CVE-2026-96637? pillow (pip) versions < 13.0.0 is affected.
- Is there a fix for CVE-2026-96637? Yes. CVE-2026-96637 is fixed in 13.0.0. Upgrade to this version or later.
- Is CVE-2026-96637 exploitable, and should I be worried? Whether CVE-2026-96637 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-96637 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-96637? Upgrade
pillowto 13.0.0 or later.