CVE-2026-42217: OpenEXR Buffer Overflow Vulnerability

CVE-2026-42217 Overview

CVE-2026-42217 affects OpenEXR, the reference implementation of the EXR image storage format used in motion picture and visual effects pipelines. The flaw resides in readVariableLengthInteger(), which decodes variable-length integers from untrusted EXR input without bounding the shift count. After enough continuation bytes, the decoder performs a left shift by 70 on a 64-bit value, triggering undefined behavior under C++ semantics. The issue maps to [CWE-190] (Integer Overflow or Wraparound) and was patched in versions 3.2.9, 3.3.11, and 3.4.11.

Critical Impact

A remote attacker can supply a crafted EXR file that causes undefined behavior during IDManifest parsing, leading to unpredictable program state in any application that processes untrusted OpenEXR data.

Affected Products

• OpenEXR versions 3.0.0 through 3.2.8
• OpenEXR versions 3.3.0 through 3.3.10
• OpenEXR versions 3.4.0 through 3.4.10

Discovery Timeline

• 2026-05-07 - CVE-2026-42217 published to NVD
• 2026-05-07 - Last updated in NVD database

Technical Details for CVE-2026-42217

Vulnerability Analysis

The vulnerability lives in readVariableLengthInteger() inside src/lib/OpenEXR/ImfIDManifest.cpp. The function decodes a variable-length integer by reading continuation bytes from EXR input and shifting each 7-bit chunk into a 64-bit accumulator. The decoder fails to bound the shift count against the width of the destination type. After ten or more continuation bytes, the shift count reaches 70, exceeding the 64-bit limit defined by the C++ standard for shift operations.

Applications that consume untrusted EXR files inherit this exposure. This includes rendering pipelines, content review tools, and asset ingestion services that rely on OpenEXR for decoding.

Root Cause

The root cause is missing input validation on the shift counter inside the variable-length integer decoder. Each continuation byte contributes 7 bits, so a valid encoding for a 64-bit integer requires at most 10 bytes. The code accepted arbitrary continuation byte sequences from attacker-controlled input. Once shift reached or exceeded 64, the expression (byte & 127) << shift produced undefined behavior per the C++ specification.

Attack Vector

An attacker delivers a malformed EXR file containing an IDManifest section with an over-long variable-length integer. The victim application parses the file using a vulnerable OpenEXR build. Delivery vectors include uploads to media processing services, shared asset repositories, and email attachments processed by automated thumbnail or preview generators. No authentication is required and no user interaction is needed beyond opening or processing the file.

            throw IEX_NAMESPACE::InputExc (
                "IDManifest too small for variable length integer");
        }
+        // Each chunk contributes at most 7 bits; shifts must stay < 64 or
+        // (byte & 127) << shift has undefined behavior (C++).
+        if (shift >= 64)
+        {
+            throw IEX_NAMESPACE::InputExc (
+                "Invalid variable-length integer in IDManifest");
+        }
        byte = *(unsigned char*) readPtr++;
        // top bit of byte isn't part of actual number, it just indicates there's more info to come
        // so take bottom 7 bits, shift them to the right place, and insert them

Source: OpenEXR Patch Commit 21eaa33. The patch adds an explicit shift >= 64 guard that throws an InputExc before the illegal shift can execute.

Detection Methods for CVE-2026-42217

Indicators of Compromise

• EXR files containing an IDManifest section with more than 10 consecutive bytes that have the high bit set in the variable-length integer encoding.
• Crashes, aborts, or sanitizer reports from processes linking against libOpenEXR versions earlier than 3.2.9, 3.3.11, or 3.4.11.
• Unexpected termination of media ingestion workers shortly after receiving a new EXR upload.

Detection Strategies

• Inventory all binaries and containers that link against libOpenEXR and identify versions below the patched releases.
• Run UndefinedBehaviorSanitizer (UBSan) builds of EXR-consuming services in pre-production to surface illegal shift operations.
• Inspect EXR samples at the gateway and reject files where IDManifest variable-length integer encodings exceed 10 bytes.

Monitoring Recommendations

• Alert on repeated crashes or restarts of image processing services that handle user-supplied content.
• Log SHA-256 hashes of EXR uploads and correlate against worker crash events to identify weaponized samples.
• Track outbound dependency advisories from the Academy Software Foundation for OpenEXR security updates.

How to Mitigate CVE-2026-42217

Immediate Actions Required

• Upgrade OpenEXR to 3.2.9, 3.3.11, or 3.4.11 depending on the deployed branch.
• Rebuild and redeploy any first-party software that statically links OpenEXR or bundles vulnerable shared libraries.
• Audit container images and third-party tools in the media pipeline for embedded copies of vulnerable OpenEXR releases.

Patch Information

The Academy Software Foundation released fixes in OpenEXR 3.2.9, 3.3.11, and 3.4.11. The fix is tracked in OpenEXR Pull Request #2378 and committed in 21eaa33bcbbb0c83a5fc42f6b6d65b70a996e63c. The complete advisory is published as GHSA-3c67-4wwp-w52m.

Workarounds

• Restrict EXR processing to trusted sources until the patched library is deployed across all consumers.
• Sandbox EXR decoding workers using seccomp, AppArmor, or container-level resource limits to contain undefined behavior outcomes.
• Pre-validate uploaded EXR files with a strict parser that rejects oversized variable-length integer encodings.

# Verify installed OpenEXR version on Linux hosts
pkg-config --modversion OpenEXR

# Example vcpkg upgrade
vcpkg upgrade openexr --no-dry-run

# Example Debian/Ubuntu package check
dpkg -l | grep -i openexr