CVE-2026-28231: Integer Overflow in pillow-heif Encode Path

CVE-2026-28231 is an integer overflow in the encode path of pillow-heif, a Python library for HEIF images. Large image dimensions bypass a bounds check and cause a heap out-of-bounds read, which can leak memory or crash the process. NVD scores it 9.1. Upgrade pillow-heif to 1.3.0 or later.

What's affected

The package is pillow-heif (also written pillow_heif) on PyPI. NVD says versions prior to 1.3.0 are affected and that 1.3.0 fixes the issue. The GitHub advisory GHSA-5gjj-6r7v-ph3x is worded slightly differently: it lists affected versions as below 1.2.1 and patched versions as 1.3.0 and later. The practical answer is the same, which is to move to 1.3.0 or later.

The advisory notes that no special configuration is needed, and that the bug sits in the encode path. That path is reached whenever an application calls the library's encode function, or saves an image through Pillow with the format set to HEIF or AVIF. The decode path is a separate code path that libheif's built-in limits partly guard.

That distinction matters for triage. A service that only reads HEIF images and never writes them is in a different position from one that converts uploads to HEIF or AVIF.

How to check if you're exposed

Find the installed version in each environment.

pip show pillow-heif
pip list | grep -i heif

For a project with a lockfile, search it for pillow-heif or pillow_heif and read the pinned version. Do the same for container images, because the library is often installed in an image layer that nobody has looked at in months.

Then check whether your code writes HEIF or AVIF. Search for pillow_heif.encode, for saves with format HEIF or AVIF, and for any thumbnail or conversion step that outputs those formats.

Paste your package manifest or lockfile into the free in-browser dependency scan at gold.safeguard.sh/scan to see which of your projects pull in the affected package, including indirect dependencies.

What to do now

1. Upgrade pillow-heif to 1.3.0 or later in every project, lockfile and image that uses it.
2. Rebuild and redeploy images so the new wheel actually ships.
3. If you accept user supplied images that the application later re-encodes to HEIF or AVIF, validate dimensions and file size before the encode step as a defence in depth measure.
4. Add a memory or process level limit to image processing workers, so a crash affects one worker and not the whole service.
5. Re-run a dependency scan after upgrading to confirm no transitive copy of an older version remains.

Why it matters

The advisory traces the bug to a size check. The code multiplies a row length by a height using 32 bit signed integers, and compares the result with the buffer length. If the product is larger than a 32 bit integer can hold, it wraps around to a small number, and the check passes when it should fail. The loop that follows then reads past the end of the buffer.

That is a chain of two weaknesses: CWE-190 (Integer Overflow or Wraparound) leading to CWE-125 (Out-of-bounds Read). The advisory says the impact is information disclosure, where server heap memory can leak into encoded images, or a denial of service from a process crash.

The pattern is common in native extensions. Python code is memory safe, but a library that wraps C code inherits C's rules, and one arithmetic mistake in a size check can undo the safety of everything above it.

The record does not flag exploitation in the wild, and the CVE is not in CISA's Known Exploited Vulnerabilities catalog. Whether you are exposed depends on a specific code path, which is exactly the question reachability analysis answers: does your application actually call the vulnerable function?

Try it yourself

Click through it at your own pace, or open it full screen.

Quick check

Sources

• GitHub Security Advisory GHSA-5gjj-6r7v-ph3x
• pillow_heif v1.3.0 release

Last reviewed: 19 October 2026.