Pillow CVE-2026-96637

Exploitation requires an application to open an attacker-supplied multi-frame SPIDER-format stack image and then advance past the first frame (SpiderImageFile.seek() to a later frame) and load it. The malicious file deliberately uses a small, safe first frame to pass Image._decompression_bomb_check() at Image.open() time, then declares very large dimensions in a later mode-F frame; prior to 13.0.0, seek() replaced self._size and reloaded without re-running the bomb check. Limiting factors: the application must specifically process SPIDER stack files (a niche electron-microscopy format rarely fed untrusted input), must iterate/seek beyond the first frame rather than only reading frame 0, and the impact is confined to memory-exhaustion DoS (UI:P / passive application interaction, no authentication, no code execution).

This is a CWE-400 uncontrolled resource consumption (memory exhaustion / decompression bomb) issue in Pillow's SPIDER image handling, scored CVSS 4.0 7.1 (High). The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:H) is internally consistent with the description: network-deliverable malicious file, no privileges, passive user/application interaction, and an availability-only impact - there is NO confidentiality or integrity impact and NO code execution, so this is strictly a denial-of-service bug. No EPSS score was provided, the CVE is NOT in CISA KEV, and no standalone weaponized exploit is flagged in the input (the fix commit does include a test that crafts a triggering file, but that is a regression test, not an in-the-wild exploit). Taken together the signals point to a genuine-but-moderate DoS: the severity is real for services that ingest untrusted SPIDER stacks, but exploitation is bounded by the fact that the SPIDER format is a niche scientific-imaging format rarely exposed to untrusted input, and the worst realistic outcome is memory exhaustion rather than compromise. Treat as a patch-in-normal-cycle availability hardening item, not an emergency - prioritize only where applications accept attacker-controlled multi-frame SPIDER files.

An attacker submits a tiny multi-frame SPIDER image whose first frame declares safe dimensions so Image.open() passes the decompression-bomb check, while a later mode-F frame declares enormous dimensions (e.g., 65535x65535). When the application advances to that frame via seek() and loads it, Pillow allocates roughly four bytes per attacker-declared pixel - multiple gigabytes - exhausting memory and crashing the process. No public in-the-wild exploit is identified, though the fixing commit includes a proof-of-concept test demonstrating the crafting technique.