CVE-2026-41142: OpenEXR Buffer Overflow Vulnerability

CVE-2026-41142 Overview

CVE-2026-41142 is an integer overflow vulnerability [CWE-190] in OpenEXR, the reference implementation of the EXR image file format used widely in the motion picture industry. The flaw resides in ImageChannel::resize within the OpenEXRUtil public API. An overflow in pixel count calculations leads to a heap out-of-bounds write when a victim processes a crafted EXR file. Affected versions include 3.0.0 through 3.2.8, 3.3.0 through 3.3.10, and 3.4.0 through 3.4.10. Patches are available in 3.2.9, 3.3.11, and 3.4.11.

Critical Impact
Attackers can trigger heap memory corruption through a malicious EXR file, potentially leading to arbitrary code execution in applications and pipelines that consume untrusted image input.

Affected Products

OpenEXR versions 3.0.0 to before 3.2.9
OpenEXR versions 3.3.0 to before 3.3.11
OpenEXR versions 3.4.0 to before 3.4.11

Discovery Timeline

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

Technical Details for CVE-2026-41142

Vulnerability Analysis

The vulnerability stems from unchecked arithmetic when computing the pixel buffer size inside ImageChannel::resize. OpenEXR multiplies width and height values supplied by image metadata to determine allocation size. When the product exceeds the maximum value of the integer type, the result wraps around to a smaller value. The library then allocates an undersized heap buffer based on the truncated count.

Subsequent write operations iterate using the original (unwrapped) dimensions, writing past the end of the allocation. This produces a heap out-of-bounds write reachable through the OpenEXRUtil public API. Any application using OpenEXRUtil to load or process EXR files inherits the flaw.

Root Cause

The root cause is a missing overflow check in pixel count arithmetic. The fix in commit 0592ee5 introduces <cstdint> and <limits> headers in src/lib/OpenEXRUtil/ImfImageChannel.cpp to enable validated 64-bit math and std::numeric_limits bounds checks before allocation occurs.

Attack Vector

Exploitation requires a victim to open or process a malicious EXR file using a tool or pipeline built on OpenEXRUtil. The attack vector is network-reachable when files arrive through email, web uploads, asset pipelines, or rendering farms. User interaction is required to trigger processing of the crafted file.

cpp

// Patch excerpt: src/lib/OpenEXRUtil/ImfImageChannel.cpp
#include "ImfImageLevel.h"
#include <Iex.h>

+#include <cstdint>
+#include <limits>
+
using namespace IMATH_NAMESPACE;
using namespace IEX_NAMESPACE;
using namespace std;

Source: GitHub Commit 0592ee5

Detection Methods for CVE-2026-41142

Indicators of Compromise

Crashes or aborts in processes linked against libOpenEXRUtil when handling EXR inputs
EXR files with abnormally large declared dataWindow or channel dimensions that overflow 32-bit pixel counts
Heap corruption signatures (e.g., glibc malloc() aborts, ASan heap-buffer-overflow reports) in image processing services

Detection Strategies

Inventory build dependencies and identify binaries linking OpenEXR versions earlier than 3.2.9, 3.3.11, or 3.4.11
Run fuzzing or AddressSanitizer-instrumented builds against EXR ingestion paths to surface heap OOB writes
Apply YARA or content rules that flag EXR files with channel dimensions exceeding rational pipeline limits

Monitoring Recommendations

Log unexpected terminations of rendering, compositing, and asset ingestion services that parse EXR content
Alert on EDR detection of child process spawning or shellcode execution from image processing applications
Monitor file upload gateways and shared storage for inbound EXR files originating from untrusted sources

How to Mitigate CVE-2026-41142

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 internal tools, plugins, or services that statically link OpenEXR
Restrict EXR ingestion to trusted sources until patching completes across the pipeline

Patch Information

The upstream fix is delivered in commit 0592ee539f33c122c90f09238579b902d838afb4 and tracked under GitHub Pull Request #2367 and GHSA-m25w-72cj-q6mg. Operators should pull the patched releases directly from the Academy Software Foundation OpenEXR repository or distribution package mirrors.

Workarounds

Sandbox EXR processing in isolated containers or seccomp-filtered processes to limit blast radius
Pre-validate EXR header dataWindow dimensions and reject files exceeding sane width/height bounds before invoking OpenEXRUtil
Disable automatic EXR thumbnailing or preview generation in shared file servers until patches are applied

bash

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

# Example: pin patched version in a Debian/Ubuntu build environment
apt-get install --only-upgrade libopenexr-3-1=3.4.11-*

# Rebuild downstream consumers against the patched headers
cmake -DCMAKE_PREFIX_PATH=/opt/openexr-3.4.11 .. && make -j