CVE-2026-62986: OpenEXR: PyOpenEXR deep prefixed RGB stale lane disclosure
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 (separatechannels=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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
PyOpenEXRto a version that resolves this vulnerability.Fixed in 3.3.13 - Upgrade
Upgrade
PyOpenEXRto a version that resolves this vulnerability.Fixed in 3.4.14
Event History
Frequently Asked Questions
Which deployments are affected?
PyOpenEXR bindings in OpenEXR versions 3.3.0 through 3.3.12 and 3.4.0 through 3.4.13 are affected. The issue applies when reading deep scanline EXR files with layer-prefixed RGB channels through the Python bindings.
What must an attacker provide to trigger the disclosure?
An attacker needs to cause a Python application to read a crafted deep scanline EXR containing prefixed channels such as left.R, left.G, and left.B. No authentication or special privileges are required, but user interaction is required to have the application process the file.
Are applications using the default Python file-reading behavior exposed?
Yes. The affected behavior occurs with the default channel coalescing setting, separate_channels=False, used by the OpenEXR.File API. Applications that log, serialize, preview, or otherwise expose the returned NumPy sample arrays may disclose uninitialized heap contents.
What version should be used to remediate the issue?
Upgrade to OpenEXR 3.3.13 or later in the 3.3 series, or 3.4.14 or later in the 3.4 series.