CVE-2026-62986 in OpenEXR
Summary
by MITRE • 08/25/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/25/2026
OpenEXR serves as the reference implementation for the EXR image file format, a standard extensively utilized within the motion picture industry for high-dynamic-range imaging and complex visual effects workflows. The vulnerability identified in PyOpenEXR Python bindings affects versions 3.3.0 through 3.3.12 and 3.4.0 through 3.4.13. This specific flaw arises during the processing of crafted deep scanline EXR files that employ layer-prefixed RGB channels, such as left.R, left.G, and left.B. The core technical deficiency lies within the PyPart::setDeepSliceData() function, which is responsible for mapping channel data into lane offsets when handling deep images. Under default configuration settings where separate_channels is set to False, the wrapper attempts to coalesce distinct channels like red, green, blue, and alpha into a single RGB sample array for efficient processing. However, the logic governing lane-offset calculation fails to recognize layer-prefixed channel names, only acknowledging exact unprefixed identifiers such as G, B, and A.
Consequently, when parsing these prefixed channels, the decoder incorrectly maps all relevant data into lane zero while leaving lanes one and two uninitialized in memory. This misalignment results in a heap-based information disclosure vulnerability where stale or uninitialized heap data is returned to the Python environment alongside corrupted color channel values. The operational impact is significant for applications that ingest untrusted deep EXR files using the default OpenEXR.File API. If such an application subsequently logs, serializes, previews, or processes the resulting NumPy sample arrays without proper sanitization, it may inadvertently expose sensitive memory contents from the same process to external observers or storage systems. This constitutes a classic out-of-bounds read scenario where uninitialized memory is exposed due to incorrect array indexing and buffer management logic within the binding layer.
From a security taxonomy perspective, this vulnerability aligns with CWE-120 Buffer Copy without Checking Size of Input in C/C++, specifically manifesting as an improper initialization or use of uninitialized variables leading to information leakage. It also relates closely to CWE-94 Improper Control of Generation of Code Command Injection if the exposed data is interpreted by downstream systems, though primarily it represents a memory safety issue categorized under CWE-200 Exposure of Sensitive Information to an Unauthorized Actor. In terms of adversarial tactics, this flaw could be leveraged in reconnaissance phases where attackers seek to gather sensitive information from application memory states, mapping to ATT&CK technique T1537 Transfer Data to Cloud Account if the leaked data is exfiltrated via network services following extraction.
The resolution for this issue was implemented in versions 3.3.13 and 3.4.14 of OpenEXR. Developers utilizing PyOpenEXR must upgrade to these patched versions immediately to mitigate the risk of heap information disclosure. Mitigation strategies also include implementing strict input validation on all EXR files before processing, ensuring that only trusted sources are ingested by applications handling deep image data. Additionally, application-level safeguards such as memory sanitizers like AddressSanitizer can help detect similar issues during development and testing phases. Organizations should audit their dependency trees to ensure no legacy versions of OpenEXR remain in production environments where untrusted media files might be processed through Python-based pipelines involving NumPy array operations or serialization mechanisms that could propagate uninitialized data.