CVE-2026-112902

============================================================================
Memory disclosure and segfault in libtiff encoder via crafted TIFF tags
Location: src/encode.c:1014  in PyImaging_LibTiffEncoderNew()
Commit:   a707c6b21c313880d0771e54965d142dd42358b6
============================================================================

A crafted TIFF file of a few hundred bytes makes Pillow copy an attacker-chosen amount of its own process memory into the TIFF it writes back out, or crash the process outright. The trigger is an ordinary Image.open() followed by a bare im.save(fp, "TIFF"). The only precondition is that the application re-saves images as TIFF. When the uploaded file is compressed, Pillow routes that save through libtiff automatically, with no options from the application. The attached reproducer does this with a 356-byte LZW TIFF: one crafted tag comes back holding 65536 bytes taken from _imaging.so's read-only data, and a second crafted tag makes the worker die with SIGSEGV on every run.

The bug is in PyImaging_LibTiffEncoderNew (src/encode.c). It decides what arguments to pass to the variadic TIFFSetField() from the shape of the Python value (scalar, tuple or bytes). It assumes its ImagingLibTiffMergeFieldInfo() call defined how libtiff will read them. But TIFFMergeFieldInfo() never overrides libtiff's built-in field table, so libtiff reads the arguments according to its own definition of the tag:

• For a counted array tag such as DNGPrivateData (50740), a count-1 integer in the source file is taken as the byte count. The data pointer is then read from an argument slot Pillow never wrote, and that many bytes are copied into the output.
• For a fixed-size array tag such as ActiveArea (50829), the integer itself is used as the source address.

Where that unwritten slot points depends on the compiler. In the tested clang build it points into _imaging.so, and a larger count returned thousands of pointers into libpython, libc and libtiff, which defeats address-space randomisation for anyone chaining another bug. When the application preserves metadata with tiffinfo=im.tag_v2, a 64-bit entry turns ActiveArea into a 16-byte read from an address the attacker chooses. All observed memory errors are reads; no out-of-bounds write was found.

Other branches of the same loop share the defect and are reachable from crafted TIFFs or from EXIF in JPEG/PNG/WebP re-saved as compressed TIFF. These are the bytes, RATIONAL-tuple and typed-tuple branches, and a BYTE-typed ColorMap. The file-reachable forwarding was introduced in a3d45e9cefd0 ("Added custom int and float TIFF tags") and first released in 5.4.0.

Details

PyImaging_LibTiffEncoderNew (src/encode.c:777-1060) chooses the argument list it hands to the variadic TIFFSetField() from the Python value of each tag — scalar vs. tuple vs. bytes, and a type that is either autodetected or copied from the source file's IFD — and assumes that its own ImagingLibTiffMergeFieldInfo() registration defines how libtiff will read the va_list. It does not: libtiff keeps its built-in definition for every tag it already knows, and core tags are never registered at all. libtiff therefore consumes the varargs as (count, pointer), (pointer) or three pointers according to its field table, whatever Pillow actually pushed. The encoder never consults that table (TIFFFindField / TIFFFieldPassCount / TIFFFieldWriteCount / TIFFFieldDataType) before the call.

The most severe instance, and the one the attached reproducer exercises: when a TIFF is re-saved through the libtiff writer, every tag of the source IFD that Pillow does not recognise is forwarded to libtiff with TIFFSetField(). A count-1 integer entry is passed as a single scalar vararg. If libtiff's own field table defines that tag number as an array field, libtiff consumes the varargs as (count, pointer) or (pointer) instead, so the attacker's integer becomes either…

Pillow is a Python imaging library. In versions through 12.3.0, the libtiff TIFF encoder can pass arguments to  TIFFSetField()  that do not match libtiff’s definition of the corresponding tag. When an application saves attacker-controlled image metadata through this encoder, crafted tag values can cause invalid memory reads, copying process memory into the encoded output or crashing the process. Applications that return the encoded output to an attacker can disclose that memory. The issue is reachable when re-saving compressed TIFF images and through certain conversions that preserve EXIF metadata into compressed TIFF output. This vulnerability is fixed in version 13.0.0.

TuxCare rebuilt pillow to address 9 CVEs. Fixed in 11.3.0.post11+tuxcare.

TuxCare rebuilt pillow to address 9 CVEs. Fixed in 11.2.1.post13+tuxcare.

TuxCare rebuilt pillow to address 1 CVE. Fixed in 10.4.0.post16+tuxcare.

TuxCare rebuilt pillow to address 7 CVEs. Fixed in 9.5.0.post13+tuxcare.

These are all security issues fixed in the python313-Pillow-13.0.0-2.1 package on the GA media of openSUSE Tumbleweed.

Root has patched CVE-2026-112902 in the pillow package for Root:PyPI. Multiple fixed versions available.

This update for python-Pillow fixes the following issues:

• CVE-2026-96636: decompression-bomb protection bypass via multi-frame seek() in MPO and DCX (bsc#1286802).
• CVE-2026-96637: decompression bomb check bypass in SpiderImagePlugin.seek() leads to unbounded allocation DoS (bsc#1286801).
• CVE-2026-96640: PDF append accepts malformed shared page-tree DAG, which can cause resource exhaustion (bsc#1286798).
• CVE-2026-96641: reachable undefined behavior in native integer operations can lead to denial of service or logic integrity compromise (bsc#1286797).
• CVE-2026-96642: TarIO negative size field causes infinite CPU-spin loop (bsc#1286796).
• CVE-2026-112390: Denial of Service via infinite loop during crafted MIC image parsing (bsc#1286256).
• CVE-2026-112391: Denial of Service via unbounded recursion in PDF parser (bsc#1286273).
• CVE-2026-112392: Denial of Service via zero-size images in rank filters (bsc#1286287).
• CVE-2026-112393: heap buffer overflow and stale-heap disclosure in _tiffWriteProc when saving compressed TIFF data (bsc#1286325).
• CVE-2026-112394: P;2L and P;4L decoders may read 1 to 3 bytes past the passed buffer size (bsc#1286311).
• CVE-2026-112397: out-of-bounds access in _imagingmorph on a zero-width image (bsc#1286314).
• CVE-2026-112398: heap buffer overflow in FPX JPEG decoding can lead to code execution (bsc#1286406).
• CVE-2026-112399: Denial of service via crafted APNG image (bsc#1286368).
• CVE-2026-112400: Denial of Service via memory exhaustion from crafted GIF image (bsc#1286370).
• CVE-2026-112401: Denial of Service via crafted GIF comments (bsc#1286372).
• CVE-2026-112402: Denial of service via double free during image transformation (bsc#1286381).
• CVE-2026-112403: heap buffer overflow in ImagingJpegDecode allows for code execution (bsc#1286405).
• CVE-2026-112405: NULL pointer dereference in Image.merge via an unvalidated band 0 (bsc#1286404).
• CVE-2026-112406: infinite loop in PdfParser.rewrite_pages on page tree Parent cycle (bsc#1286403).
• CVE-2026-112891: quadratic GIF comment copying during save (bsc#1286402).
• CVE-2026-112892: MSP RLE decoder expands a tiny file into unbounded memory (bsc#1286401).
• CVE-2026-112894: Denial of Service via crafted multi-frame image conversion (bsc#1286408).
• CVE-2026-112895: Denial of service via crafted PDF during append operations (bsc#1286411).
• CVE-2026-112896: TIFF encoder ColorMap plane-size mismatch causes a heap out-of-bounds read (bsc#1286400).
• CVE-2026-112897: TiffDecode returns uninitialized memory as pixels for short JPEG strips (bsc#1286398).
• CVE-2026-112899: EPS load(scale) lets Ghostscript render past the decompression bomb limit (bsc#1286489).
• CVE-2026-112900: argument Injection in Ghostscript call can lead to remote code execution (bsc#1286397).
• CVE-2026-112901: ReDoS in XbmImagePlugin can be triggered by 512-byte file (bsc#1286396).
• CVE-2026-112902: memory disclosure and segfault in libtiff encoder via crafted TIFF tags (bsc#1286804).