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.
// 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
# 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
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.


