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(st