CVE-2026-59982: OpenEXR Information Disclosure Vulnerability

CVE-2026-59982 Overview

CVE-2026-59982 is an out-of-bounds read vulnerability in OpenEXR, the reference implementation for the EXR image format used throughout the motion picture industry. The flaw resides in the TypedDeepImageChannel::row() and TypedFlatImageChannel::row() APIs in the OpenEXRUtil library. When processing a crafted deep EXR file with a nonzero dataWindow origin, the API combines zero-based row access with an absolute-coordinate-adjusted base pointer. This mismatch returns an out-of-bounds pointer, resulting in a crash or limited information disclosure. Affected releases include all OpenEXR versions before 3.2.11, 3.3.0 through 3.3.12, and 3.4.0 through 3.4.13.

Critical Impact
A remote attacker can trigger a process crash or leak adjacent memory contents by supplying a malicious deep EXR file to any application linking the OpenEXRUtil library.

Affected Products

OpenEXR versions prior to 3.2.11
OpenEXR versions 3.3.0 through 3.3.12
OpenEXR versions 3.4.0 through 3.4.13

Discovery Timeline

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

Technical Details for CVE-2026-59982

Vulnerability Analysis

The defect is an out-of-bounds read classified under [CWE-190] (Integer Overflow or Wraparound), triggered when dataWindow.min is nonzero. The OpenEXRUtil image channel classes cache a _base pointer that is pre-adjusted for the absolute coordinate origin of the data window. Callers of row(int r), however, pass zero-based row indices. Multiplying the zero-based index by pixelsPerRow() and adding it to the origin-adjusted _base yields a pointer outside the allocated buffer.

Downstream code that dereferences the returned pointer reads from unrelated heap memory. Depending on the caller, this results in a segmentation fault or the disclosure of neighboring memory contents into rendered pixel data. Because deep EXR files are frequently processed by rendering pipelines, batch converters, and asset ingestion services, exploitation typically requires only that a user open or import a crafted file.

Root Cause

The root cause is a coordinate-system mismatch between the pointer stored in _base and the indices supplied to row(). _base is computed relative to the absolute dataWindow origin, while row() treats its argument as a zero-relative row index. When dataWindow.min.y is nonzero, the resulting pointer arithmetic addresses memory before or after the allocated sample buffer.

Attack Vector

Exploitation requires an attacker to deliver a crafted deep EXR file to a victim application that uses OpenEXRUtil. This includes VFX tooling, DCC applications, thumbnailers, and web services that accept EXR uploads. User interaction is required to open or process the file. The vulnerable code paths execute in-process, so successful triggering can crash the host application or leak memory contents into the rendered output.

// Source: https://github.com/AcademySoftwareFoundation/openexr/commit/37f03b6ed90f3dd9910f31de3a40f25f2bc2aca1
// Patch in src/lib/OpenEXRUtil/ImfDeepImageChannel.h
 inline T* const*
 TypedDeepImageChannel<T>::row (int r)
 {
-    return _base + r * pixelsPerRow ();
+    return _sampleListPointers + r * pixelsPerRow ();
 }

 template <class T>
 inline const T* const*
 TypedDeepImageChannel<T>::row (int r) const
 {
-    return _base + r * pixelsPerRow ();
+    return _sampleListPointers + r * pixelsPerRow ();
 }

// Patch in src/lib/OpenEXRUtil/ImfFlatImageChannel.h
 inline T*
 TypedFlatImageChannel<T>::row (int r)
 {
-    return _base + r * pixelsPerRow ();
+    return _pixels + r * pixelsPerRow ();
 }

The fix replaces the origin-adjusted _base pointer with _sampleListPointers (deep image) or _pixels (flat image), both of which use zero-based indexing that matches the caller contract.

Detection Methods for CVE-2026-59982

Indicators of Compromise

Repeated crashes or segmentation faults in processes linking libOpenEXRUtil when opening EXR files
Rendered images containing anomalous pixel patterns suggestive of leaked heap memory
Inbound EXR files whose dataWindow header specifies a nonzero min.x or min.y origin
Application logs showing exceptions originating from TypedDeepImageChannel::row or TypedFlatImageChannel::row

Detection Strategies

Inventory installed OpenEXR shared libraries and match reported versions against the vulnerable ranges (prior to 3.2.11, 3.3.0–3.3.12, and 3.4.0–3.4.13).
Use software composition analysis (SCA) tooling to identify statically linked OpenEXR in third-party rendering, VFX, and image-processing binaries.
Parse EXR file headers at the gateway and flag samples where dataWindow.min is nonzero for additional inspection before downstream processing.

Monitoring Recommendations

Monitor crash telemetry from image-processing services and DCC hosts for stack frames referencing ImfDeepImageChannel or ImfFlatImageChannel.
Alert on unusual process termination for batch renderers, thumbnailers, or upload workers that consume user-supplied EXR content.
Track deployment coverage of the patched OpenEXR versions across build environments, CI pipelines, and production render farms.

How to Mitigate CVE-2026-59982

Immediate Actions Required

Upgrade OpenEXR to version 3.2.11, 3.3.13, or 3.4.14, matching the currently deployed major/minor line.
Rebuild and redistribute internal applications and container images that statically link or vendor OpenEXR.
Restrict acceptance of untrusted EXR files at network boundaries until patched binaries are deployed.

Patch Information

The Academy Software Foundation released fixes in OpenEXR 3.2.11, 3.3.13, and 3.4.14. The corrective commits are 37f03b6, 55b7958, and aef0222. Full advisory details are available in the OpenEXR Security Advisory GHSA-6662-fq6f-93mp.

Workarounds

Reject or pre-filter EXR files whose dataWindow.min header fields are nonzero before passing them to OpenEXRUtil consumers.
Isolate EXR parsing in a sandboxed process or container so that crashes and memory disclosures do not affect the parent application.
Disable deep EXR ingestion paths in optional integrations until patched OpenEXR builds are in place.

bash

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

# Confirm no vulnerable shared libraries remain after upgrade
ldconfig -p | grep -i openexr
find / -name 'libOpenEXR*' -exec sh -c 'echo "$1"; strings "$1" | grep -m1 -E "3\.[234]\.[0-9]+"' _ {} \;