CVE-2026-68514: OpenEXR: Heap buffer overflow in PyOpenEXR from literal/prefixed RGB channel name collision in deep images
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
PyOpenEXR / OpenEXR Python bindingsto a version that resolves this vulnerability.Fixed in 3.3.13 - Upgrade
Upgrade
PyOpenEXR / OpenEXR Python bindingsto a version that resolves this vulnerability.Fixed in 3.4.14
Event History
Frequently Asked Questions
Which deployments are affected?
Deployments using the PyOpenEXR Python bindings in OpenEXR versions 3.3.0 through 3.3.12 or 3.4.0 through 3.4.13 are affected when they read deep scanline EXR files. The issue is in the OpenEXR.File Python API path.
What does an attacker need to exploit this issue?
An attacker needs to cause the application to open a crafted deep scanline EXR file. The file must include a literal channel named left and layer-prefixed channels named left.R, left.G, and left.B; user interaction is required to open the file.
Is the default Python API affected?
Yes. Opening the crafted file with the default public Python API, OpenEXR.File(path), triggers the overflow during normal deep-sample decoding.
What should be done to remediate the issue?
Upgrade to OpenEXR 3.3.13 or later on the 3.3 branch, or 3.4.14 or later on the 3.4 branch. If an upgrade is not immediately possible, avoid opening untrusted deep scanline EXR files through PyOpenEXR.