CVE-2026-68513: OpenEXR PyOpenEXR Buffer Overflow Vulnerability

CVE-2026-68513 Overview

OpenEXR is the reference implementation and specification for the EXR image format, widely used across the motion picture industry. CVE-2026-68513 is a heap buffer overflow [CWE-122] in the PyOpenEXR Python wrapper triggered by a channel-name key collision between literal and prefixed RGB channels. The flaw affects OpenEXR versions 3.3.0 through 3.3.12 and 3.4.0 through 3.4.13. A crafted flat scanline EXR file causes the wrapper to reuse an undersized NumPy array during RGB coalescing, writing out of bounds when OpenEXR.File(path) decodes pixels. Fixed builds are available in 3.3.13 and 3.4.14.

Critical Impact
Processing a malicious EXR file through PyOpenEXR with separate_channels=false triggers an out-of-bounds heap write, enabling integrity and availability compromise on the local host.

Affected Products

OpenEXR PyOpenEXR wrapper versions 3.3.0 through 3.3.12
OpenEXR PyOpenEXR wrapper versions 3.4.0 through 3.4.13
Python applications and pipelines that call OpenEXR.File(path) with separate_channels=false

Discovery Timeline

2026-08-25 - CVE-2026-68513 published to the National Vulnerability Database
2026-08-25 - Last updated in NVD database

Technical Details for CVE-2026-68513

Vulnerability Analysis

The vulnerability lives in the PyOpenEXR C++ wrapper, specifically the code path that coalesces separate physical channels into a shared RGB NumPy array. When separate_channels=false, PyOpenEXR maps each physical channel through channelNameToRGBA() and writes the resulting slices into a two-dimensional NumPy array sized for the expected RGB set. An attacker-supplied EXR containing both a literal channel such as left and prefixed channels such as left.R, left.G, and left.B causes channelNameToRGBA() to produce colliding keys. The wrapper then reuses the same undersized backing array for multiple distinct channel slices. When OpenEXR.File(path) decodes pixel data, the writes exceed the allocated buffer on the heap. The result is heap corruption during a routine file load, without any authentication or network access.

Root Cause

The root cause is missing validation in validateCoalescedChannelTypes(). The function checked channel type compatibility but did not detect key collisions produced by literal-and-prefixed channel name pairs. The upstream fix renames the function to validateCoalescedChannels() and refuses to coalesce when a conflict is present.

Attack Vector

Exploitation requires an operator or automated pipeline to open a crafted EXR file locally. The attack vector is local with user interaction, and no privileges are required on the target process. Rendering farms, DCC applications, and content ingestion pipelines that automatically process untrusted EXR uploads are the primary exposure surface.

cpp

// Source: https://github.com/AcademySoftwareFoundation/openexr/commit/c1f3ec0d91cfa5a8035ecd00920835ac76e01640
// Patch in src/wrappers/python/PyOpenEXR.cpp
            std::vector<size_t> shape ({height, width});

            if (!separate_channels)
-                P.validateCoalescedChannelTypes (header.channels (), rgbaChannels);
+                P.validateCoalescedChannels (header.channels (), rgbaChannels);

            //
            // Read the channel data, different for image vs. deep

The corresponding header change in src/wrappers/python/PyOpenEXR.h renames the declaration so the wrapper now validates both channel types and colliding coalesced channel names before allocating the shared RGB array. See the GitHub Security Advisory GHSA-rw5h-3q4v-c3vc for the full technical write-up.

Detection Methods for CVE-2026-68513

Indicators of Compromise

EXR files whose channel list contains both a literal name (for example left) and prefixed RGB siblings (left.R, left.G, left.B) in the same part.
Python processes importing OpenEXR at versions 3.3.0–3.3.12 or 3.4.0–3.4.13.
Unexpected crashes, SIGSEGV, or heap corruption diagnostics from processes invoking OpenEXR.File().

Detection Strategies

Inventory installed OpenEXR Python bindings across build servers, render nodes, and analyst workstations using pip show openexr or SBOM tooling.
Parse incoming EXR assets with a pre-flight script that enumerates channel names and flags literal-plus-prefixed collisions before handing files to production pipelines.
Enable AddressSanitizer or heap protections in test builds of tools that link PyOpenEXR to surface out-of-bounds writes during QA.

Monitoring Recommendations

Alert on unexpected termination or memory-corruption signals from Python interpreters loading EXR content.
Monitor asset ingestion services for EXR uploads from untrusted sources and quarantine files that fail channel-name validation.
Track OpenEXR package versions in CI/CD and endpoint inventories to identify unpatched hosts.

How to Mitigate CVE-2026-68513

Immediate Actions Required

Upgrade PyOpenEXR to 3.3.13 or 3.4.14 on every workstation, render node, and container image that processes EXR files.
Audit pipelines that call OpenEXR.File(path) with separate_channels=false and restrict them to trusted asset sources until patched.
Rebuild and redeploy internal tools and DCC plugins that statically link the vulnerable OpenEXR versions.

Patch Information

The Academy Software Foundation released fixes in OpenEXR 3.3.13 and 3.4.14. The patch renames validateCoalescedChannelTypes() to validateCoalescedChannels() and refuses to coalesce RGB channels when a conflicting channel name is present. Review the GitHub commit c1f3ec0d and the follow-up commit d134e3cd for the complete change set.

Workarounds

Call OpenEXR.File() with separate_channels=true to bypass the vulnerable coalescing path.
Reject EXR inputs whose channel lists contain both a literal name and matching prefixed RGB siblings.
Run EXR decoding in a sandboxed, non-privileged process to contain heap corruption impact.

bash

# Upgrade the vulnerable Python bindings
pip install --upgrade "openexr>=3.4.14"

# Or, for the 3.3.x branch
pip install --upgrade "openexr>=3.3.13,<3.4"

# Verify the installed version
python -c "import OpenEXR; print(OpenEXR.__version__)"