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 return stale heap data when reading a crafted deep scanline EXR that uses layer-prefixed RGB channels. With the default channel coalescing (separate_channels=False), the wrapper groups channels such as left.R, left.G, and left.B into a single RGB sample array, but the lane-offset calculation in PyPart::setDeepSliceData() only recognizes the exact unprefixed names G, B, and A. As a result, prefixed channels like left.G and left.B are decoded into lane 0 while lanes 1 and 2 are left uninitialized and returned to Python. A Python application that reads untrusted deep EXR files through the default OpenEXR.File API and then logs, serializes, previews, or otherwise processes the resulting NumPy sample arrays may expose uninitialized same-process heap contents, in addition to receiving incorrect green and blue channel data. This issue is fixed in versions 3.3.13 and 3.4.14.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.3",
  "pubDate": "2026-08-25T19:16:52.120Z",
  "pubdate": "2026-08-25T19:16:52.120Z",
  "executiveSummary": "PyOpenEXR is susceptible to an information disclosure vulnerability resulting from uninitialized heap memory access.\nThe vulnerability originates in the PyPart::setDeepSliceData() function, which fails to correctly calculate lane offsets for layer-prefixed RGB channels when using default channel coalescing.\nThis flaw allows a crafted deep scanline EXR file to cause the library to return stale heap memory instead of the expected pixel data for the green and blue channels.\nSuccessful exploitation results in the exposure of sensitive process heap contents to the Python environment.\nThe vulnerability affects PyOpenEXR versions 3.3.0 through 3.3.12 and 3.4.0 through 3.4.13.\nAttackers can leverage this by supplying malicious EXR files to applications utilizing the vulnerable library, potentially exfiltrating sensitive data residing in the application's memory space.\nThe risk is particularly high in services that process untrusted user-uploaded imagery for previewing, serialization, or logging.",
  "technicalDetails": "The root cause of this vulnerability is an incorrect implementation of channel name parsing within the PyPart::setDeepSliceData() function in the PyOpenEXR Python bindings. The function is designed to map specific image channels to appropriate memory lanes when performing channel coalescing (separate_channels=False).\nUnder default settings, PyOpenEXR attempts to group channels named 'R', 'G', 'B', and 'A' into a unified NumPy sample array. However, the logic within setDeepSliceData() relies on hardcoded string matches for these channel identifiers. When a deep scanline EXR employs layer-prefixed channels (e.g., 'left.R', 'left.G', 'left.B'), the logic fails to identify the prefixed 'G' and 'B' components.\nBecause the system only recognizes the unprefixed labels 'G', 'B', and 'A', the lane-offset calculation fails to correctly route the prefixed channel data into the corresponding memory structure. Consequently, the green and blue components are decoded into lane 0, while lanes 1 and 2 remain uninitialized. The resulting NumPy array returned to the Python interpreter contains valid data in the first lane, but contains stale heap memory in the subsequent lanes.\nThe attack flow requires an attacker to construct a specially crafted deep scanline EXR file containing prefixed channels. Once a victim application processes this file via the OpenEXR.File API, the library populates the output arrays with raw heap data captured from the process memory. If the application subsequently serializes these arrays to a file, logs them, or displays them in a user interface, the stale heap content is exposed.\nThe impact is significant, as heap memory may contain sensitive information such as cryptographic keys, session tokens, or other user data processed by the same execution context. There is no requirement for authentication or specific privileges beyond the ability to provide an input file to the target application. Because this occurs at the heap level, the vulnerability is highly reliable and does not require complex heap spraying techniques to influence the content of the exposed memory.\nAffected versions include 3.3.0-3.3.12 and 3.4.0-3.4.13. The vulnerability is explicitly linked to how the C++ wrapper interfaces with the underlying memory buffers of the OpenEXR implementation, leading to an out-of-bounds read of initialized memory during the construction of the Python-accessible sample buffers."
}