Pillow Heap Buffer Overflow When Saving TIFF to In-Memory Buffers (GHSA-332p-7hrc-92wf)

What happened

A security advisory published for Pillow (the Python Imaging Library, distributed via PyPI) describes a heap buffer overflow in _tiffWriteProc, the write callback Pillow uses in src/libImaging/TiffDecode.c when saving a TIFF image to an in-memory target such as io.BytesIO() instead of a real file. According to the report, the function sizes its realloc() from the buffer's current size rather than the current write position, so a seek-ahead write performed by libtiff while writing the TIFF directory can land past the end of the allocated block. The same code path also fails to zero out memory it skips over, which the report says leaks stale heap bytes — data from unrelated prior allocations — into the saved file. The advisory states this is reachable with default settings via the common pattern Image.open(upload).save(io.BytesIO(), "TIFF"), and that a reproducer reliably crashes the process. A tracked CVE (CVE-2026-112393) is associated with this advisory, and a public proof-of-concept is noted as available; no CVSS score was provided in the source material.

Why it matters for defenders

Pillow is one of the most widely used imaging libraries in the Python ecosystem, and the vulnerable pattern — accepting an uploaded image and re-encoding it to TIFF in memory for further processing or storage — is a common service-side workflow (thumbnailing, format normalization, document pipelines). Per the advisory, exploitation requires no non-default Pillow options, only that the application saves to a non-file-backed target and that attacker-controlled data (such as image tags or an embedded ICC profile) reaches the TIFF writer. The practical impact described ranges from process crashes (denial of service for a worker/request) to disclosure of unrelated heap memory in the output file; the advisory additionally reports a researcher-built, more involved proof-of-concept combining this bug with a separate information leak to achieve code execution under specific, non-default conditions — this should be treated as a demonstration of theoretical severity rather than a turnkey exploit.

What defenders should watch for or do now

• Inventory services and pipelines that call Pillow's Image.save() with TIFF output to in-memory objects (BytesIO, HTTP response streams, object-storage upload streams) rather than to a file path.
• Prioritize review of any code that opens untrusted/user-supplied images and re-saves them as TIFF, especially where tag metadata (ImageDescription, DocumentName, XMP) or ICC profiles from the source image are preserved through copy(), resize(), thumbnail(), or direct re-save.
• Watch for unexpected worker crashes or SIGABRT/heap-corruption errors in processes that perform TIFF conversions, which may indicate exploitation attempts or accidental triggering.
• As a short-term mitigation, consider routing TIFF saves through real file paths (temp files) instead of in-memory buffers where feasible, pending a patched Pillow release, and track the vendor's fix status closely given the public PoC.
• Flag outbound TIFF files produced by affected services for review if there is any concern about inadvertent disclosure of heap memory contents.

Developing situation

This is a same-day advisory and the underlying facts — patch availability, affected version ranges, and real-world exploitation — are still developing. Defenders should monitor Pillow's official release channels for a fixed version and treat details here as preliminary. Full technical details are available in the original advisory: GHSA-332p-7hrc-92wf.