Pillow: bundled libopenjp2 heap-buffer-overflow write reachable from Image.open().load() (OSV-2025-219 / GHSA-78g4-xqwv-q3g8)
Severity: high · Patch status: partial · Since 2026-10-17
Pillow wheels from 11.1.0 through 12.3.0 bundle a libopenjp2 (2.5.3/2.5.4) containing a heap-buffer-overflow write in opjj2kreadsod (OSV-2025-219), introduced in OpenJPEG in June 2024 — notably, older OpenJPEG 2.5.2 is safe. The flaw is reachable from Image.open(fp); im.load() with default settings, and because the wheel bundles its own copy, patched host OS libraries do not help. A public ASan PoC demonstrates the overflow through Pillow's own decoder. Attackers can craft a JPEG 2000 codestream that triggers memory corruption even when uploaded as avatar.png with image/png Content-Type, since Image.open() sniffs magic bytes. Fixed in Pillow 13.0.0; the upstream OpenJPEG fix (91d08b11, Feb 2026) remains unreleased. No in-the-wild exploitation reported.
What to do
- Upgrade Pillow to 13.0.0 (or pin to <=11.0.0 if downgrade is feasible)
- Until upgraded, pass an explicit formats= list excluding JPEG2000 to Image.open() and validate on the detected format, not client Content-Type or filename
- Reject or sandbox untrusted image uploads; consider blocking JPEG 2000 magic bytes (JP2/j2k codestreams) at the application layer
- Audit image-processing services for reliance on filename/Content-Type allowlists that Image.open() bypasses
- Monitor for an OpenJPEG release carrying 91d08b11 and rebuild any vendored/bundled OpenJPEG accordingly
Fixed versions
Sources
All live incidents on Threat Watch