CVE-2026-40192

What it actually does

Pillow versions 10.3.0 through 12.1.1 fail to enforce a bounded read limit when decoding GZIP-compressed FITS image data. A small, specially crafted FITS file can expand to a very large amount of data during decompression, causing excessive memory allocation in the Python process that parses the image. The direct impact is denial of service through out-of-memory termination, process crash, container restart, worker exhaustion, or severe performance degradation. The CVSS vector indicates network-reachable, unauthenticated, low-complexity exploitation with high availability impact and no confidentiality or integrity impact.

Why it matters to the business

Applications, APIs, batch jobs, image-processing pipelines, scientific-data workflows, and file-upload services that accept or process FITS images with vulnerable Pillow versions can be made unavailable by a malicious or malformed file. This may interrupt customer-facing services, delay data-processing workloads, increase infrastructure costs through repeated crashes or autoscaling, and create operational instability. The vulnerability is not listed in CISA KEV and has low EPSS at the time of assessment, but it has been public for 116 days and is easy to trigger wherever untrusted FITS files are processed.

How an attack unfolds

An attacker identifies a service or workflow that uses Pillow to inspect, resize, validate, convert, thumbnail, or otherwise decode uploaded or remotely supplied image files. The attacker prepares a FITS image containing GZIP-compressed data that is small enough to pass normal upload or transport controls but expands dramatically when Pillow decodes it. The file is submitted through an upload endpoint, message queue, object-storage ingestion path, email attachment workflow, or any other path that causes the vulnerable Pillow FITS decoder to open it. When the Python process reads the compressed FITS data without an effective decompression limit, memory consumption grows until the process slows, crashes, is killed by the operating system or container runtime, or exhausts shared worker capacity. Repeated submissions can keep services degraded or unavailable.

How to fix it

Upgrade Pillow to a version that contains the decompression limit fix as soon as a fixed release is available from the project or package distributor. Because the provided package data does not include an exact fixed version, treat Pillow 10.3.0 through 12.1.1 as vulnerable and verify the vendor advisory, package repository, or lockfile resolution before deployment. If immediate upgrade is not possible, disable FITS image decoding for untrusted input, allow only explicitly required image formats, reject `.fits`, `.fit`, `.fts`, and compressed FITS-like uploads where not needed, and avoid invoking Pillow on arbitrary user-controlled files. Add compensating controls such as upload size limits, decompressed-size limits where available, worker memory limits, CPU and wall-clock timeouts, queue rate limits, and isolation of image-processing workers in containers or sandboxes with automatic but rate-limited restarts.

How to confirm the fix worked

Confirm exposure by inventorying Python environments, containers, virtual environments, requirements files, lockfiles, SBOMs, and deployed images for Pillow versions 10.3.0 through 12.1.1. Validate remediation by confirming that all runtime environments resolve to a non-vulnerable Pillow version once an upstream fix is available, or that FITS handling is disabled or blocked for untrusted input. Test application behavior by uploading or processing benign FITS files and verifying that unwanted FITS inputs are rejected if FITS is not required. Confirm that memory, CPU, and timeout controls are enforced for image-processing workers. In CI/CD, add dependency checks that fail builds when vulnerable Pillow versions are introduced.

Typical attack path

1. Find an application, API, worker, or pipeline that accepts image files or scientific FITS files from untrusted sources.
2. Confirm or infer that the backend uses a vulnerable Pillow version between 10.3.0 and 12.1.1.
3. Create a FITS file with GZIP-compressed content that expands to an excessive size during decoding.
4. Submit the crafted file through an upload, ingestion, email, storage, or processing workflow.
5. Trigger Pillow to decode the FITS image, causing unbounded memory consumption.
6. Cause the Python process, container, job worker, or host to crash, restart, or become severely degraded.
7. Repeat submissions to sustain denial of service or exhaust processing queues.

How to detect it

There is no reliable single network IOC for this vulnerability because exploitation is data-driven and may look like an ordinary file upload or file-ingestion event. To determine whether exploitation may already have occurred, review application logs, upload logs, object-storage access logs, message-queue histories, EDR telemetry, container events, kernel logs, and process supervisors for OOM kills, Python MemoryError events, worker crashes, or repeated restarts shortly after FITS files were uploaded or processed. Focus on timestamps where memory usage spiked, Python workers terminated unexpectedly, queues backed up, or services returned 500/503 errors. Look for filenames or content types associated with FITS files, repeated submissions from the same source, unusually small compressed files followed by very large memory allocation, and stack traces involving Pillow FITS decoding. Treat the indicators below as hunting strings and forensic pivots rather than proof of compromise; correlate them with file-ingestion activity and process/resource telemetry.

• PIL.FitsImagePlugin
• FitsImagePlugin
• MemoryError
• Out of memory
• oom-killer
• Killed process
• OOMKilled
• exit code 137
• Container killed due to memory usage
• WorkerLostError
• SIGKILL
• Cannot allocate memory
• .fits
• .fit
• .fts
• application/fits
• image/fits
• SIMPLE =
• XTENSION=

What your security team should do

• Identify all applications, services, containers, notebooks, and batch jobs that use Pillow and process user-supplied or externally sourced files.
• Prioritize remediation for internet-facing upload services, asynchronous image-processing workers, scientific-data ingestion pipelines, and systems with automatic file processing from email, object storage, or queues.
• Upgrade Pillow to a fixed version when available; until then, pin away from vulnerable releases only if the project publishes a safe replacement, or disable FITS parsing for untrusted files.
• Block or quarantine unneeded FITS extensions and MIME types at upload gateways, API validators, storage ingestion hooks, and message-processing boundaries.
• Apply strict resource controls to image-processing components, including per-worker memory limits, request timeouts, decompression limits where supported, and queue/rate limiting.
• Review recent crashes, OOM kills, container restarts, and spikes in memory usage correlated with FITS file processing or image upload activity.
• Add monitoring and alerting for repeated Pillow exceptions, Python MemoryError events, OOM killer activity, abnormal worker restarts, and unusually high memory consumption during file ingestion.
• Update secure coding guidance to require format allowlisting rather than attempting to parse every uploaded file type.