Description

OpenEXR is the reference implementation and specification for the EXR image format, widely used in the motion picture industry. Versions 3.3.0 through 3.3.12 and 3.4.0 through 3.4.13 contain a heap buffer overflow in PyOpenEXR triggered by a channel-name key collision between literal and prefixed RGB channels. When separate_channels=false, PyOpenEXR maps each physical channel name through channelNameToRGBA() and coalesces the results into a shared RGB array. A crafted flat scanline EXR that contains both a literal channel such as left and prefixed channels such as left.R, left.G, and left.B causes these names to collide, so the wrapper reuses an undersized two-dimensional NumPy array for the coalesced RGB slices and writes out of bounds when OpenEXR.File(path) decodes the pixels. This issue is fixed in versions 3.3.13 and 3.4.14.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.1",
  "pubDate": "2026-08-25T20:17:02.463Z",
  "pubdate": "2026-08-25T20:17:02.463Z",
  "executiveSummary": "A critical heap buffer overflow vulnerability exists within the PyOpenEXR wrapper for OpenEXR versions 3.3.0-3.3.12 and 3.4.0-3.4.13. The vulnerability is triggered by a channel-name collision during the coalescing process of image data, specifically when the separate_channels flag is set to false.\nThis memory corruption flaw allows a malicious actor to craft a specially formatted EXR file that forces the application to write data outside the boundaries of an allocated NumPy array. Successful exploitation may lead to arbitrary code execution, application crashes, or memory disclosure, depending on the memory layout and the surrounding runtime environment.\nThe vulnerability affects systems relying on PyOpenEXR for processing EXR imagery, commonly utilized in VFX pipelines. Exploitation is contingent upon the processing of a maliciously crafted input file. There are no authentication or specific privilege requirements beyond the capability to provide the malicious file to the target application.\nGiven the ubiquitous use of EXR files in professional imaging, this vulnerability represents a significant risk to workstations and automated rendering servers that may handle untrusted assets. Remediation requires updating to the patched versions to eliminate the underlying logic flaw.",
  "technicalDetails": "The root cause of the vulnerability resides in the channel mapping logic of the PyOpenEXR wrapper, specifically within how it handles channel naming collisions during pixel coalescing. When the separate_channels parameter is false, PyOpenEXR invokes channelNameToRGBA() to map physical channel identifiers to a shared RGB array structure.\nA heap buffer overflow is triggered when a crafted EXR file contains both literal channel names (e.g., 'left') and prefixed channel names (e.g., 'left.R', 'left.G', 'left.B'). The logic fails to differentiate between these conflicting naming schemes, causing the wrapper to reuse an undersized two-dimensional NumPy array that was allocated for fewer channels than are actually present in the file.\nThe attack flow proceeds as follows: 1) An attacker provides a maliciously crafted flat scanline EXR file containing overlapping or colliding channel names. 2) The PyOpenEXR wrapper parses the image header and initiates the pixel decoding process via OpenEXR.File(path). 3) During the mapping of channels to the NumPy array, the collision causes the pointer arithmetic and indexing logic to target a destination buffer that has not been sized to accommodate the additional pixel data resulting from the prefix-based channels. 4) As OpenEXR.File(path) performs the pixel decoding, it writes data into the shared RGB array structure, exceeding the allocated heap bounds of the NumPy array.\nBecause NumPy arrays operate as contiguous memory segments in the heap, the out-of-bounds write corrupts adjacent memory blocks. Depending on the memory layout of the host process, this can overwrite heap metadata, function pointers, or sensitive objects stored in adjacent memory regions. This memory corruption can facilitate arbitrary code execution by redirecting control flow, or result in a Denial of Service (DoS) due to segmentation faults during the write operation.\nAffected versions are limited to PyOpenEXR components within OpenEXR 3.3.0 through 3.3.12 and 3.4.0 through 3.4.13. The vulnerability does not require authentication, as it is a client-side parsing issue, nor does it require escalated privileges; the code executes with the permissions of the user initiating the image processing task. The attack is entirely file-driven, making it highly effective against any system that parses EXR files from unknown or untrusted sources."
}