Pillow 11.1.0 to 12.3.0 patched to fix bundled OpenJPEG heap overflow

Pillow version 13.0.0 addresses a high-severity heap-buffer-overflow vulnerability found in bundled OpenJPEG libraries. Affected releases include versions 11.1.0 through 12.3.0, which ship with vulnerable libopenjp2 binaries that ignore host operating system patches.

What happened

GitHub advisory GHSA-78g4-xqwv-q3g8 identifies a heap-buffer-overflow write in the libopenjp2 library bundled with Pillow wheels starting from version 11.1.0. The flaw was introduced in an OpenJPEG commit from June 2024 and persists in versions 2.5.3 and 2.5.4, which are included in Pillow 11.1.0, 11.2.1, 11.3.0, and the 12.0.0 through 12.3.0 series. Earlier Pillow releases such as 10.4.0 and 11.0.0 remain safe because they bundle OpenJPEG 2.5.2.

The vulnerability exists in the `opj_j2k_read_sod` function within `j2k.c`, where the `tp_index` array lacks null and bounds checks. An attacker can trigger this by providing a crafted image file with a specific `TPsot` field in the SOT marker. The flaw is reachable using standard `Image.open` and `im.load` calls with default settings, meaning no special configuration is required to expose the application to risk.

Why it matters

This defect is particularly dangerous because Pillow wheels bundle their own copy of the vulnerable library, rendering host-level OpenJPEG patches ineffective. Security teams cannot rely on operating system updates to mitigate this risk, as the Python package carries its own binary dependencies. The inversion of typical patching logic means that keeping the dependency current in earlier versions actually created the exposure, complicating legacy system assessments.

The correct guard already exists a few lines later in `opj_j2k_add_tlmarker`, which writes to the same array at the same index behind a check. One writer checked its sibling not, leading to the inconsistency. The vulnerability has been assigned no CVE identifier in the provided material, relying instead on the GitHub advisory for tracking and remediation guidance.

What to watch

• Monitor for new Pillow releases beyond version 13.0.0 for continued stability
• Check internal repositories for cached or pinned versions of Pillow 11.1.0 to 12.3.0
• Verify that deployment pipelines are not blocking the upgrade to patched versions
• Review logs for unusual memory access patterns in image processing services

Who needs to act first

Teams should prioritize updating systems that process untrusted or user-uploaded image files, as these face the highest exposure risk. Begin by identifying all environments running affected Pillow versions through dependency scanning tools. Test the upgrade to version 13.0.0 in isolated staging environments to ensure compatibility with existing applications. Roll out the update to production systems in phases, monitoring for any regressions in image handling workflows. Ensure backup procedures are in place before applying changes to critical infrastructure.

What to do and how to stay safe: Pillow

• Scan all Python environments for Pillow versions 11.1.0 through 12.3.0 using package managers
• Upgrade affected systems to Pillow version 13.0.0 or later to obtain the fixed libopenjp2 library
• Verify that the upgrade successfully replaced the bundled binary by checking version outputs
• Implement strict input validation for image files to reduce the attack surface further

Step-by-step guide: Virtual Patching Myths: What It Actually Fixes and Breaks

General security guidance from the Patch Gazette newsroom. It is not confirmed advice from the organisations named in this story.

Frequently asked questions

Which Pillow versions are affected by this vulnerability?

Versions 11.1.0, 11.2.1, 11.3.0, and all 12.x versions up to 12.3.0 are affected.

Is there a CVE identifier for this flaw?

No CVE identifier is listed in the GitHub advisory GHSA-78g4-xqwv-q3g8.

Can operating system updates fix this vulnerability?

No, because Pillow wheels bundle their own copy of the vulnerable library.