CVE-2026-96637 in Pillow
Summary
by MITRE • 10/21/2026
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._decompression_bomb_check(). 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.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/22/2026
The vulnerability identified in the Pillow imaging library, specifically within versions prior to 13.0.0, represents a critical resource exhaustion flaw rooted in improper validation logic during image processing. The core technical defect resides in the SpiderImageFile.seek() method located in src/PIL/SpiderImagePlugin.py. This function is responsible for navigating through different frames or modes within SPIDER format files, which are commonly used in scientific imaging applications such as electron microscopy and cryo-electron tomography. When the library processes a multi-frame SPIDER file, it initially validates the first frame to ensure it does not exceed predefined memory limits designed to prevent denial of service attacks. However, when subsequent frames are accessed via the seek operation, the code reparses later stack frames and updates internal state variables such as self._size with new dimensions declared in those frames. Crucially, this update occurs without re-invoking the Image._decompression_bomb_check() function, which is the primary safeguard against loading excessively large images that could consume excessive system resources.
This architectural oversight allows an attacker to craft a malicious SPIDER file containing two distinct sections: a small initial frame with safe dimensions and low pixel count, followed by a later mode F frame declaring extremely large width and height values. Upon opening the image, the library performs its standard decompression bomb check on the first frame, which passes successfully due to its modest size requirements. Subsequently, when an application attempts to access or render the second frame using seek(), the internal dimensions are updated to reflect the massive pixel count declared in that later section. The loading of this specific mode F frame triggers memory allocation based on these inflated dimensions, calculating approximately four bytes per pixel for floating-point data types. Consequently, a file with minimal disk size can force the application to allocate multiple gigabytes of RAM, leading to severe performance degradation or complete system crash due to out-of-memory conditions.
The operational impact of this vulnerability is significant, particularly in environments where Pillow processes untrusted image inputs from external sources. Attackers can exploit this flaw to execute a denial of service attack with minimal bandwidth requirements, as the malicious payload remains small on disk while exerting maximum pressure on system memory resources. This type of resource exhaustion aligns closely with CWE-400, which covers unconstrained resource consumption vulnerabilities where an entity does not properly control the allocation and maintenance of limited resources. Furthermore, this exploitation technique is consistent with ATT&CK tactic T1499, specifically Endpoint Denial of Service via application layer exploits that target software logic flaws rather than network bandwidth or protocol parsing errors directly. The ability to bypass initial security checks by leveraging multi-frame structures highlights a gap in the library's state management and validation consistency across different access patterns within the same file object.
To mitigate this risk, organizations relying on Pillow must immediately upgrade to version 13.0.0 or later, where the developers have addressed this logic error by ensuring that dimension changes trigger appropriate memory safety checks regardless of which frame is being accessed. In scenarios where upgrading is not immediately feasible, defensive coding practices should be implemented within application layers consuming these images. This includes implementing custom size validation before calling seek() on image objects, setting strict limits on maximum allowable pixel dimensions at the application level rather than relying solely on library defaults, and monitoring memory usage during image processing operations to detect anomalous spikes indicative of such attacks. Additionally, input sanitization strategies should be employed to validate file structures against expected SPIDER specifications, rejecting files that exhibit inconsistent frame metadata or unexpected mode transitions before they are fully processed by the imaging engine.