Pillow FPX Decoder Heap Overflow (GHSA-5x8w-8jj5-q52h): Code Execution via Image.open() on Untrusted Files

What happened

A security advisory (GHSA-5x8w-8jj5-q52h) reports a heap buffer overflow in Pillow's FlashPix (FPX) JPEG-tile decoder, affecting Pillow 12.2.0. According to the researcher-published writeup, the FpxImagePlugin maps attacker-controlled FPX color IDs to a rawmode/output-buffer size, but the embedded JPEG's own component count (set via its SOF marker) determines how many bytes libjpeg actually writes per pixel when Pillow falls back to JCS_UNKNOWN colorspace handling. A crafted file can declare 4 components against a buffer sized for 2 bytes/pixel, producing a heap out-of-bounds write with attacker-controlled length and content.

Critically, FPX files are OLE2/CFBF compound documents detected by Pillow via the OLE2 magic bytes, not file extension — so any code path that calls Image.open() on a file will attempt FPX decoding if the optional olefile package is installed, regardless of the uploaded filename or expected format. A public proof-of-concept demonstrates turning this into arbitrary command execution by using the overflow to overwrite a Python object's type pointer and hijack a vtable call during buffer release. A CVE (CVE-2026-112398) has been associated with this advisory; CVSS has not yet been published, and exploitation in the wild has not been reported — this is a proof-of-concept disclosure, not a confirmed active-exploitation event.

Why it matters for defenders

This affects any application that processes user-supplied images with Pillow and has olefile installed as a dependency: upload handlers, avatar/thumbnail generation, document-conversion pipelines, and similar media-processing services. Because detection is content-based (OLE2 magic) rather than extension-based, an attacker does not need to name the file .fpx or trick a user into any interaction — a server that automatically thumbnails or ingests uploads is reachable. The reported impact is code execution in the context of the process performing the image decode, which for many services (upload workers, background job processors) could mean broad compromise of that process's privileges and data access.

What defenders should watch for or do now

• Inventory services using Pillow and check whether the optional olefile package is installed — if FPX support isn't needed, removing olefile removes this attack surface.
• Track upstream Pillow for a patched release addressing this advisory and prioritize upgrading image-processing/upload-handling services once available.
• Where feasible, run untrusted image decoding in an isolated/sandboxed worker (restricted container, seccomp profile, no outbound exec capability) so a decoder compromise doesn't translate directly to host or service compromise.
• Hunting angle: look for unexpected child-process spawns (e.g., system()/shell execs) from image-processing or thumbnailing worker processes, and for crash/abort signatures (e.g., glibc heap-corruption aborts) correlated with image upload or conversion activity.
• Consider input validation/allowlisting of accepted image formats at the application layer in addition to relying on library-level content sniffing, since the latter is exactly what's being abused here.

Developing intel

This item is based on a freshly published GitHub Security Advisory with an accompanying public PoC; details may evolve as Pillow maintainers respond and as the associated CVE record is enriched (CVSS scoring is not yet available). For the full technical writeup, PoC code, and credits, see the original advisory: GHSA-5x8w-8jj5-q52h.