CVE-2026-68514: OpenEXR Buffer Overflow Vulnerability

CVE-2026-68514 Overview

CVE-2026-68514 is a heap out-of-bounds write [CWE-122] in the PyOpenEXR Python bindings shipped with OpenEXR, the reference implementation of the EXR image file format used across visual effects and animation pipelines. The flaw affects versions 3.3.0 through 3.3.12 and 3.4.0 through 3.4.13. A crafted deep scanline EXR file that mixes a literal channel named left with layer-prefixed channels left.R, left.G, and left.B triggers heap memory corruption during normal decoding through the default OpenEXR.File(path) API. Maintainers fixed the issue in versions 3.3.13 and 3.4.14.

Critical Impact

Opening a malicious EXR file through the PyOpenEXR wrapper causes heap buffer overflow, memory corruption, and process crash, disrupting any local workflow that ingests untrusted image assets.

Affected Products

• OpenEXR PyOpenEXR bindings versions 3.3.0 through 3.3.12
• OpenEXR PyOpenEXR bindings versions 3.4.0 through 3.4.13
• Python applications and pipeline tooling that call OpenEXR.File(path) on untrusted EXR inputs

Discovery Timeline

• 2026-08-25 - CVE-2026-68514 published to NVD
• 2026-08-26 - Last updated in NVD database

Technical Details for CVE-2026-68514

Vulnerability Analysis

The PyOpenEXR wrapper coalesces layer-prefixed RGB channels into a single contiguous buffer for efficient decoding. When a deep scanline file declares both a scalar literal channel named left and a set of layer-prefixed channels left.R, left.G, and left.B, the wrapper processes the literal left channel first. It allocates a scalar-shaped deep sample array sized for a single lane. The coalescing logic then reuses this same array as the destination for the three-lane RGB group without reallocating storage.

The deep reader subsequently registers sample slices with an RGB stride of three lanes into memory that was allocated with scalar shape. When the deep sample decoder writes decoded pixel data, it walks past the end of the allocation and corrupts adjacent heap memory. The result is a crash during routine file parsing and potential exploitation of the underlying heap corruption primitive.

Root Cause

The root cause is missing conflict validation in the RGB channel coalescing path within PyOpenEXR.cpp. The prior validateCoalescedChannelTypes helper checked type compatibility but did not detect the collision between a bare channel name and identically prefixed layer channels. The buffer allocated for the scalar channel was reused with an incompatible stride, producing an out-of-bounds write during deep sample decode.

Attack Vector

Exploitation requires user interaction: a victim must open a crafted deep scanline EXR file through the default OpenEXR.File(path) Python API. The attack vector is local, so the malicious file must reach the target through a delivery channel such as asset ingestion, shared storage, or a pipeline job that fetches remote content. There is no confidentiality or integrity impact reported, but availability is high due to guaranteed memory corruption and process termination.

// Upstream patch replaces the type-only validator with a conflict-aware check
// Source: https://github.com/AcademySoftwareFoundation/openexr/commit/c1f3ec0d91cfa5a8035ecd00920835ac76e01640
            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 renames the helper and expands its responsibilities to reject coalescing when a conflicting channel name is present. See the GitHub Security Advisory GHSA-mw28-66qc-c883 for the complete disclosure.

Detection Methods for CVE-2026-68514

Indicators of Compromise

• Unexpected termination of Python processes that call OpenEXR.File() shortly after loading an EXR asset
• EXR files whose channel list contains both a bare channel name (for example left) and layer-prefixed channels sharing that prefix (left.R, left.G, left.B)
• Crash dumps or Address Sanitizer reports indicating heap-buffer-overflow inside PyOpenEXR deep sample decoding

Detection Strategies

• Inventory Python environments and render nodes for installed openexr package versions and flag any release in the 3.3.0–3.3.12 or 3.4.0–3.4.13 ranges
• Parse EXR headers at ingestion time and reject files whose channel lists contain conflicting bare and prefixed channel names
• Enable heap hardening or Address Sanitizer in test pipelines to surface out-of-bounds writes during automated asset validation

Monitoring Recommendations

• Alert on repeated crashes of asset-processing services, render workers, or DCC plugins that link against PyOpenEXR
• Log the origin of EXR assets entering the pipeline and correlate crashes with newly ingested files from external contributors
• Track package updates on build servers to confirm remediated OpenEXR versions are deployed across all workstations

How to Mitigate CVE-2026-68514

Immediate Actions Required

• Upgrade the OpenEXR Python bindings to version 3.3.13 or 3.4.14, which contain the coalescing validation fix
• Restrict OpenEXR.File() usage to trusted asset sources until all endpoints are patched
• Isolate EXR ingestion in sandboxed processes so a crash cannot destabilize larger pipeline services

Patch Information

The fix is delivered through two upstream commits in the AcademySoftwareFoundation OpenEXR repository. The primary change is the PyOpenEXR coalescing patch, with the corresponding follow-up commit applied on the release branches. Both patches rename validateCoalescedChannelTypes to validateCoalescedChannels and add logic that refuses to coalesce RGB channels when a conflicting bare channel name is present.

Workarounds

• Pass separate_channels=True when opening EXR files so the wrapper skips the vulnerable coalescing path
• Pre-scan EXR files with a lightweight parser and drop any that declare both bare and layer-prefixed variants of the same channel name
• Route untrusted EXR content through a sacrificial worker or container with strict resource limits

# Upgrade PyOpenEXR to a fixed release
pip install --upgrade "openexr>=3.4.14"

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