CVE-2026-59205

What it actually does

Pillow versions prior to 12.3.0 contain a native heap corruption flaw in the ImageCms.ImageCmsTransform.apply(im, imOut) API. When an application passes an output image object whose mode does not match the transform’s declared output mode, Pillow can write image data into memory using incorrect assumptions about the destination buffer. This can corrupt the Python process heap and typically results in interpreter crashes or worker-process termination. The assigned impact is availability-focused: no direct confidentiality or integrity impact is indicated by the CVSS vector, but the flaw occurs in native image-processing code and can be triggered without authentication if exposed through an application image-processing workflow.

Why it matters to the business

Applications that process user-supplied images with affected Pillow versions may be vulnerable to denial of service. An attacker could repeatedly trigger crashes in web workers, background processors, thumbnailing services, document pipelines, or media ingestion jobs, causing service disruption, failed uploads, queue backlogs, and degraded customer-facing functionality. Although this issue is not currently listed in CISA KEV and EPSS is low, public exploit availability increases urgency for internet-facing or high-volume image-processing services.

How an attack unfolds

An attacker first identifies an application path that processes images using Python Pillow and performs ICC/color-management transformations with ImageCms. The vulnerable condition depends on application code invoking ImageCms.ImageCmsTransform.apply(im, imOut) while providing an output image whose mode differs from the transform’s expected output mode. If the application allows the attacker to influence the input image, color profile, requested output mode, or transformation parameters, the attacker can craft requests that drive execution into the mismatched-output path. Once Pillow performs the transform, native code writes using incompatible buffer assumptions, corrupting heap memory inside the Python process. The immediate practical outcome is usually a segmentation fault, abort, worker crash, or container restart. Repeated requests can keep application workers unstable and produce sustained denial of service. Remote code execution should not be assumed from the available scoring, but memory corruption in native libraries should still be treated as high priority where untrusted image processing is exposed.

How to fix it

Upgrade Pillow to version 12.3.0 or later everywhere it is used. Rebuild and redeploy application containers, virtual environments, serverless packages, and background worker images that vendor or pin Pillow. If immediate upgrade is not possible, mitigate by avoiding direct use of ImageCms.ImageCmsTransform.apply(im, imOut) with caller-provided output images, validating that imOut.mode exactly matches the transform output mode before calling apply, removing attacker control over output modes and ICC transform parameters, and isolating image processing in constrained worker processes with restart limits, memory limits, and queue rate controls. Pin dependency versions explicitly and ensure transitive dependency lockfiles resolve to Pillow 12.3.0 or newer.

How to confirm the fix worked

Confirm runtime versions with package inventory commands such as `python -m pip show Pillow`, `python -m pip freeze`, `pipdeptree`, Poetry/Pipenv lockfile inspection, container SBOMs, and deployed artifact manifests. At runtime, verify `PIL.__version__` reports 12.3.0 or later. Search application code for `ImageCmsTransform.apply`, `ImageCms.ImageCmsTransform.apply`, and uses of `imOut` in Pillow color-management paths, then confirm output image modes are validated or the vulnerable call pattern has been removed. After upgrading, rebuild images from clean dependency caches, redeploy all workers and services, and verify no running process or container still imports an older Pillow package. Operationally, monitor that previously crashing image-processing paths no longer produce segmentation faults, aborts, or worker restarts under normal regression tests.

Typical attack path

1. Find a web endpoint, API, queue consumer, or file-processing workflow that accepts attacker-controlled images or image metadata.
2. Determine that the backend uses Python Pillow with ImageCms color transformation functionality.
3. Submit crafted image-processing requests that influence the source image, ICC profile, transform, destination image mode, or output parameters.
4. Trigger code that calls ImageCms.ImageCmsTransform.apply(im, imOut) with an imOut mode that does not match the transform’s declared output mode.
5. Cause native heap corruption in the Python process during the color-management transform.
6. Crash the worker, job processor, or service instance and repeat the request to sustain denial of service.

How to detect it

Detection should focus on evidence of exploitation attempts causing instability in Python image-processing services. Review application logs, worker logs, container runtime events, process supervisor logs, crash dumps, and operating system logs for Python crashes, segmentation faults, allocator corruption messages, repeated worker exits, or restarts correlated with image upload, thumbnail generation, document conversion, or color-profile processing requests. In web and API logs, look for bursts of image-processing requests from the same source followed by HTTP 500/502/503 responses, upstream connection resets, queue job failures, or pod/container restarts. In application code and telemetry, pay special attention to paths using `PIL.ImageCms`, `ImageCmsTransform.apply`, ICC profile conversion, or explicit `imOut` handling. If core dumps are available, inspect stack traces for Pillow, PIL.ImageCms, LittleCMS/lcms, or Python native extension frames around the crash. Absence of a unique malicious file signature means detection is primarily behavioral: crash/restart patterns, failed image transforms, and request correlation are more reliable than static network indicators.

• ImageCms.ImageCmsTransform.apply
• ImageCmsTransform.apply(
• PIL.ImageCms
• malloc(): corrupted top size
• malloc(): invalid size
• free(): invalid next size
• free(): invalid pointer
• double free or corruption
• corrupted double-linked list
• Fatal Python error: Segmentation fault
• Segmentation fault (core dumped)
• Fatal Python error: Aborted
• core dumped
• worker exited unexpectedly
• container restarted
• CrashLoopBackOff

What your security team should do

• Prioritize upgrade to Pillow 12.3.0 or later for internet-facing services and asynchronous workers that process untrusted images.
• Perform a dependency inventory across application repositories, containers, CI artifacts, and serverless packages to locate all Pillow versions prior to 12.3.0.
• Search code for ImageCms color transformation usage, especially `ImageCmsTransform.apply(im, imOut)`, and require mode validation before any explicit output image is passed.
• Add compensating controls while patching: image upload rate limits, maximum file size limits, worker memory limits, job retry caps, and isolation of image conversion workers from critical application processes.
• Review application and infrastructure logs for unexplained Python segmentation faults, native aborts, container restarts, or spikes in failed image-processing jobs since the vulnerability became public.
• Add dependency scanning rules or software composition analysis policies that fail builds using Pillow versions earlier than 12.3.0.
• Because exploit code is available, treat repeated crashes in image-processing components as potentially malicious even though the issue is not currently in CISA KEV and EPSS remains low.