Description

OpenEXR is the reference implementation and specification for the EXR image file format, widely used in the motion picture industry. In versions 3.3.0 through 3.3.12 and 3.4.0 through 3.4.13, the PyOpenEXR Python bindings contain a heap out-of-bounds write triggered when reading a crafted deep scanline EXR file. When a deep file declares a literal channel named left alongside layer-prefixed RGB channels left.R, left.G, and left.B, the wrapper processes the literal left channel first and allocates a scalar deep sample array for it, then reuses that same array as the coalesced destination for the prefixed RGB group. The deep reader registers sample slices with an RGB stride (three lanes) into storage that was allocated with scalar shape, so decoding the deep samples writes past the allocation. Opening such a file through the default public Python API, OpenEXR.File(path), causes a heap buffer overflow during normal deep sample decode, leading to memory corruption and a crash. This issue is fixed in versions 3.3.13 and 3.4.14.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.5",
  "pubDate": "2026-08-25T20:17:02.613Z",
  "pubdate": "2026-08-25T20:17:02.613Z",
  "executiveSummary": "The PyOpenEXR Python bindings for OpenEXR are susceptible to a heap out-of-bounds write vulnerability occurring during the decoding of maliciously crafted deep scanline EXR files.\nThe vulnerability arises from a logic error in memory allocation when handling deep files that mix literal and layer-prefixed channels, specifically when a literal channel named 'left' coexists with prefixed 'left.R', 'left.G', and 'left.B' channels.\nAn attacker can exploit this flaw by providing a specially crafted EXR file to a target application using the affected OpenEXR.File(path) API.\nSuccessful exploitation results in heap memory corruption, which typically leads to an application crash or potentially arbitrary code execution depending on the attacker's ability to control the heap state.\nAffected products include PyOpenEXR versions 3.3.0 through 3.3.12 and 3.4.0 through 3.4.13.\nThe issue is classified as a critical memory safety vulnerability due to the ease of triggering via standard file processing APIs, requiring no specific authentication or elevated privileges beyond the ability to provide input to an application that processes EXR images.",
  "technicalDetails": "The vulnerability exists within the PyOpenEXR wrapper logic responsible for mapping and decoding deep scanline EXR data. The root cause is a race condition or mismatch in the initialization and subsequent reuse of buffers when processing complex channel groupings.\nWhen the reader encounters a deep file containing both a literal channel named 'left' and prefixed channels (e.g., 'left.R', 'left.G', 'left.B'), the internal logic incorrectly identifies the 'left' channel and performs an initial allocation for a scalar deep sample array based on this single-channel width.\nSubsequently, the decoder attempts to coalesce the prefixed RGB group ('left.R', 'left.G', 'left.B') into the previously allocated buffer. Because the RGB channels require a stride of three lanes, the memory requirements for the destination buffer are significantly larger than the initial scalar allocation.\nThe deep reader registers the RGB sample slices using the higher-stride configuration while still targeting the original, smaller memory block. As the decoder proceeds, it performs write operations across the three lanes into an area allocated only for a single scalar value. This results in an out-of-bounds heap write.\nThe attack flow begins when an application invokes OpenEXR.File(path) on an attacker-supplied EXR file. The parsing logic reads the image header and channel definitions, triggering the flawed memory registration process. As the decoder iterates through the deep samples and writes image data to the heap, the out-of-bounds access corrupts adjacent memory objects in the heap segment.\nThis corruption can lead to the overwrite of critical heap metadata or application-specific pointers, facilitating a denial-of-service condition via application crash or potentially allowing a sophisticated adversary to redirect execution flow. The exploit does not require authentication or specific privileges, as it is triggered during the standard parsing of an untrusted file format, making it dangerous for any media processing pipeline, thumbnail generation service, or image conversion utility that utilizes the vulnerable PyOpenEXR versions."
}