CVE-2026-68513: OpenEXR: Heap buffer overflow in PyOpenEXR from literal/prefixed RGB channel name collision
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 separatechannels=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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 3.3.13 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 3.4.14
Event History
Frequently Asked Questions
Who is exposed to this issue?
Users of PyOpenEXR in OpenEXR 3.3.0 through 3.3.12 or 3.4.0 through 3.4.13 are exposed when their workflow decodes attacker-controlled EXR files. The vulnerable path is reached through OpenEXR.File(path).
What does an attacker need to provide to trigger the overflow?
An attacker needs to convince a user or application to decode a crafted flat scanline EXR containing both a literal channel name, such as left, and prefixed RGB channels such as left.R, left.G, and left.B. Exploitation also requires the PyOpenEXR decoding path to use separate_channels=false.
How can this be remediated?
Upgrade to OpenEXR 3.3.13 or later in the 3.3 series, or 3.4.14 or later in the 3.4 series. These versions contain the fix.
What can be done if upgrading is not immediately possible?
Avoid decoding untrusted EXR files with the affected PyOpenEXR path, particularly flat scanline images that may contain colliding literal and prefixed RGB channel names. Restrict processing to trusted EXR inputs until a fixed version can be deployed.