Pillow CVE-2026-96638

Requires the target application to decode an attacker-supplied, RLE-compressed BMP image (BI_RLE4/BI_RLE8) using Pillow prior to 13.0.0 - this is the exact precondition: the image-processing pipeline must accept untrusted BMP input and invoke the BMP decoder. Limiting factors that reduce real-world risk: impact is confined to availability (no code execution, no information disclosure); the attacker must have a path to deliver the image into the decode routine (e.g., an upload endpoint, avatar/thumbnail service, or document-processing job); and applications that restrict accepted formats, cap decode memory/image dimensions (e.g., via MAX_IMAGE_PIXELS or external resource limits), or run decoding in sandboxed/resource-capped workers blunt or contain the DoS.

No CVSS score or vector was provided by any source (NVD, vendor, or oss-security all list CVSS as N/A), so severity signals rest solely on the Pillow project's own qualitative bucket, which rates CVE-2026-96638 as Medium. There is no EPSS score, no CISA KEV listing, and no public proof-of-concept referenced - exploitation status is therefore 'no public exploit identified at time of analysis'. The vulnerability is a BMP RLE decoder memory-amplification denial of service: a tiny crafted file expands into unbounded memory during decode, which is an availability-only issue with no confidentiality or integrity impact. My independent assessment (AV:N/AC:L/PR:N/UI:N/A:H = 7.5) scores higher than the vendor's Medium bucket because any service that decodes untrusted BMPs can be crashed by a small input; the gap likely reflects that vendor triage weighs the bounded, recoverable nature of a single OOM event rather than raw network reachability. This is a real but second-tier priority: trivially triggerable where untrusted image decoding is exposed, yet it yields only resource exhaustion, not code execution or data theft. Note the conflict to resolve with the vendor: whether a single crafted file fully exhausts host memory (A:H) or merely degrades a worker (A:L) is not quantified in the sources.

An attacker submits a small, specially crafted RLE-compressed BMP to any service that uses Pillow (<13.0.0) to decode, thumbnail, or transcode user-supplied images. During RLE decoding the run-length data amplifies into a far larger pixel buffer, exhausting available memory and crashing or hanging the worker process. No public proof-of-concept is referenced in the provided sources.