CVE-2026-59205: Heap-Based Buffer Overflow in Pillow ImageCms Module

Pillow incorporates the LittleCMS (lcms2) library via its ImageCms module to perform high-fidelity color profile conversions. The ImageCmsTransform class handles these transformations by establishing custom input and output pixel modes, which correspond to specific internal memory layouts.

The vulnerability, designated as CVE-2026-59205, manifests when an application processes transformations via apply() or apply_in_place(). These APIs fail to validate that the pixel modes of user-supplied images correspond to the formats expected by the compiled transformation object.

Because the native C extension _imagingcms only performs coordinate-based boundary checks, it readily processes images with mismatched formats. This discrepancy allows multi-byte pixel structures to be written into buffers allocated for single-byte pixel layouts.

The root cause of this vulnerability lies in the lack of type and mode validation within the src/PIL/ImageCms.py Python layer and the corresponding _imagingcms.c native component. During transformation compilation, a handle is initialized with predefined source and destination formats, which dictate how many bytes are read and written per pixel.

When cmsDoTransform() is executed, the destination image's row buffer pointers are supplied directly to the LittleCMS engine. If the compiled transformation outputs 4-byte pixels (such as RGBA) but the target image is allocated with a 1-byte pixel mode (such as L), LittleCMS continues to write 4 bytes per pixel into the destination buffer.

This behavior causes a controlled out-of-bounds write of 3 bytes per pixel into adjacent heap chunks. Conversely, if the input image mode contains fewer bytes than expected by the transformation engine, an out-of-bounds heap read occurs, exposing adjacent memory contents.

The vulnerability was mitigated in Pillow version 12.3.0 by incorporating check assertions directly into the high-level Python wrappers inside src/PIL/ImageCms.py.

Prior to the patch, the apply method did not perform any validation of input or output modes:

def apply(self, im, imOut=None):
    if imOut is None:
        imOut = Image.new(self.output_mode, im.size, None)
    self.transform.apply(im.getim(), imOut.getim())
    imOut.info["icc_profile"] = self.output_profile.tobytes()
    return imOut

The corrected implementation establishes strict equality validations prior to invoking the C extension:

def apply(self, im: Image.Image, imOut: Image.Image | None = None) -> Image.Image:
    if im.mode != self.input_mode:
        msg = "mode mismatch"
        raise ValueError(msg)
    if imOut is not None:
        if imOut.mode != self.output_mode:
            msg = "mode mismatch"
            raise ValueError(msg)
    else:
        imOut = Image.new(self.output_mode, im.size, None)
    self.transform.apply(im.getim(), imOut.getim())
    imOut.info["icc_profile"] = self.output_profile.tobytes()
    return imOut

These checks ensure that the physical structures allocated for the images match the spatial logic expected by the native code.

Although the current validation checks successfully address the public API vector, implementing defenses purely at the Python layer introduces a potential gap in defensive controls. If an attacker is capable of executing limited python code, they can directly import and call the binary extension module _imagingcms.

Because the underlying C-code wrappers do not check the mode attribute of the ImagingCore structures, direct calls to the underlying transform engine still result in a heap out-of-bounds write. Furthermore, if custom image classes can spoof the .mode property while returning an under-allocated buffer on .getim(), the Python-level checks can be circumvented.

To ensure complete isolation, future iterations of Pillow should incorporate these size-assertion validations inside the native C extension _imagingcms.c before passing pointers to the lcms2 library.

To exploit this vulnerability, an attacker must submit an image that forces the application to perform a color space transformation where the source or target image buffers are mismatched. An application that automatically converts user uploads to a standardized color profile is highly vulnerable to this scenario.

Because the bytes written to the adjacent heap space represent the translated pixels of the source image, an attacker can construct custom pixel matrices to control the corrupted data. By crafting the input pixel coordinates and color values, the attacker can precisely overwrite adjacent metadata blocks, targeting function pointers or control structures on the heap to execute arbitrary code.

The vulnerability is assigned CVSSv3.1 score 7.5 (High) due to the potential for total loss of process availability. In environments where Pillow processes image uploads, exploitation immediately leads to process termination or denial of service.

In scenarios where memory protections such as ASLR are bypassed or where control over heap layouts is mature, heap corruption can be weaponized to compromise system integrity. This vulnerability is of critical concern for multi-tenant image hosting services and document processing pipelines.