CVE-2026-59204

What it actually does

Pillow versions 8.2.0 through 12.2.0 mishandle tiled JPEG2000 decoding in src/libImaging/Jpeg2KDecode.c. During decoding, the library accumulates total_component_width across all tiles rather than recalculating it independently for each tile. A specially crafted JPEG2000 image can therefore cause excessive transient memory allocation and trigger out-of-memory conditions in the process performing image parsing. The direct impact is availability loss of the application, worker, API, batch job, or service that decodes attacker-supplied JPEG2000 content; the flaw is not described as enabling code execution, data disclosure, or data modification.

Why it matters to the business

Systems that accept, process, thumbnail, validate, convert, or inspect user-supplied images may be crashed or repeatedly destabilized by a malicious JPEG2000 file. This can interrupt uploads, media pipelines, document-processing workflows, content moderation, e-commerce image handling, messaging platforms, or automated ingestion jobs. Because the vulnerability is remotely reachable wherever untrusted image files are processed without authentication and exploit code is reported as available, organizations should treat exposed image-processing paths as higher priority even though EPSS is currently low and the issue is not listed in CISA KEV.

How an attack unfolds

An attacker identifies an application, API, queue, email/document ingestion path, or batch workflow that uses an affected Pillow release to decode JPEG2000 images. They craft a tiled JPEG2000 file whose tile layout causes Pillow’s decoder to inflate the accumulated total_component_width value during processing. When the vulnerable code attempts to decode the image, memory usage spikes substantially above what the apparent image dimensions would suggest. If memory limits are exceeded, the Python process, worker container, web request handler, or background job may be killed by the operating system or runtime, causing denial of service. Repeated submissions can keep image-processing workers unavailable, exhaust autoscaling capacity, or create a backlog in dependent processing queues.

How to fix it

Upgrade Pillow to version 12.3.0 or later wherever it is installed directly or pulled in transitively by image, document, ML, OCR, web, or media-processing components. Because no per-package fixed-version list was provided beyond the upstream fix, verify dependency lockfiles and runtime environments resolve to Pillow 12.3.0 or newer. Rebuild and redeploy containers, serverless packages, virtual environments, and application bundles that vendor or pin Pillow. If immediate upgrade is not possible, mitigate by blocking or disabling JPEG2000 decoding for untrusted inputs, rejecting JPEG2000 file types at upload boundaries, enforcing strict file size and pixel-dimension limits, applying per-request and per-worker memory limits, isolating image processing in disposable sandboxed workers, and rate-limiting unauthenticated upload or conversion endpoints.

How to confirm the fix worked

Confirm that all deployed Python environments report Pillow 12.3.0 or later, for example by checking package manifests, lockfiles, SBOMs, container images, and runtime package metadata. Validate that applications accepting untrusted images either no longer use vulnerable Pillow versions or reject JPEG2000 input before decoding. Test representative upload and processing paths with benign JPEG2000 files to ensure expected functionality remains intact after upgrade or filtering. Confirm worker memory limits, restart policies, queue back-pressure controls, and upload validation rules are active. Vulnerability scanners and dependency-audit tools should no longer report Pillow versions 8.2.0 through 12.2.0 in reachable workloads.

Typical attack path

1. Find an externally reachable feature that accepts images or documents and processes them with Pillow, such as upload, preview, thumbnailing, conversion, or metadata extraction.
2. Submit or deliver a crafted tiled JPEG2000 file using a .jp2, .j2k, .jpf, .jpx, or related JPEG2000 container/extension.
3. Trigger server-side decoding through preview generation, validation, resizing, conversion, or scanning.
4. Cause the vulnerable decoder to accumulate component width across tiles and allocate excessive transient memory.
5. Force the Python process, worker, container, or service to terminate or become unresponsive due to out-of-memory conditions.
6. Repeat submissions to sustain service disruption or overload processing queues.

How to detect it

Investigate whether JPEG2000 files were processed shortly before application crashes, worker restarts, container terminations, or operating-system out-of-memory events. Useful log sources include web access logs, upload/API gateway logs, WAF logs, application image-processing logs, background worker and queue logs, container orchestrator events, Linux kernel logs, systemd journals, Python exception logs, and endpoint/process telemetry. Look for uploads or requests involving JPEG2000 extensions or MIME types followed by high memory usage, SIGKILL events, exit code 137, Kubernetes OOMKilled status, kernel 'Out of memory' messages, or repeated restarts of Python/Pillow-based image workers. Correlate source IPs, user agents, authenticated users where applicable, object names, and timestamps across upload events and crash telemetry. Because this flaw causes denial of service rather than persistent compromise, durable artifacts may be limited to the triggering files, access records, crash/OOM logs, queue retry records, and temporary processing paths.

• .jp2
• .j2k
• .jpf
• .jpx
• image/jp2
• image/jpx
• image/jpm
• image/j2k
• PIL.Jpeg2KImagePlugin
• Jpeg2KDecode
• Out of memory: Killed process
• Killed process
• oom-killer
• OOMKilled
• exit code 137
• MemoryError
• SIGKILL
• worker lost
• worker exited unexpectedly
• cannot identify image file
• ImportError: No module named _imaging
• Pillow 8.2.0
• Pillow 12.2.0

What your security team should do

• Inventory all services, containers, serverless functions, CI jobs, and batch-processing workers that include Pillow versions 8.2.0 through 12.2.0.
• Prioritize internet-facing or unauthenticated upload, image-preview, media-conversion, OCR, document-processing, and content-ingestion paths.
• Upgrade Pillow to 12.3.0 or later and rebuild all artifacts that package Python dependencies.
• Until upgrades are complete, block JPEG2000 uploads or route them to isolated workers with strict memory, CPU, and timeout limits.
• Add monitoring for sudden worker restarts, out-of-memory kills, HTTP 5xx spikes, image-processing queue growth, and repeated JPEG2000 submissions from the same source.
• Review recent logs for suspicious JPEG2000 upload attempts and correlated process crashes or OOM events.
• Update dependency governance rules to flag vulnerable Pillow versions in source repositories, container images, and SBOMs.