CVE-2026-59186: OpenEXR Buffer Overflow Vulnerability

CVE-2026-59186 Overview

CVE-2026-59186 is a heap out-of-bounds write in OpenEXR, the reference implementation of the EXR image format used widely in motion picture production. The flaw affects 32-bit and ILP32 builds when a crafted tiled EXR file is read through the public TiledRgbaInputFile RGBA API. A file declaring a small 40x40 data window combined with a 65537x65537 tile size causes the Array2D<Rgba> tile-conversion buffer size calculation to overflow. The library then allocates a much smaller heap buffer than required, and tile decode writes past that allocation [CWE-122].

Critical Impact
Attackers can trigger a heap out-of-bounds write on 32-bit OpenEXR consumers by delivering a malicious tiled EXR file, resulting in memory corruption and application crashes.

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-59186 published to NVD
2026-08-25 - Last updated in NVD database

Technical Details for CVE-2026-59186

Vulnerability Analysis

The vulnerability lives in OpenEXR's Array2D<Rgba> template, which allocates a two-dimensional buffer used during tile decoding by TiledRgbaInputFile. On ILP32 platforms, size_t is 32 bits, so the product of tile width and tile height (65537 * 65537 * sizeof(Rgba)) wraps around during size computation. The resulting truncated value produces a small heap allocation. When the decoder later writes the full tile contents, it walks past the allocated bounds and corrupts adjacent heap metadata and objects.

Exploitation requires the victim to open an attacker-supplied EXR file. Because OpenEXR is embedded in image viewers, compositing suites, VFX pipelines, and web-based media services, a crafted file distributed over the network can reach vulnerable parsers with user interaction.

Root Cause

The root cause is an integer overflow in Array2D::resizeErase() when computing the total byte count for the pixel buffer on ILP32/LLP64 builds. The header does not include <cstddef> or use overflow-safe arithmetic before invoking operator new[], so the truncated size silently succeeds. The fix hardens the size calculation and raises an Iex exception on overflow instead of allocating an undersized region.

Attack Vector

The attack vector is a malicious tiled EXR file. The file declares mismatched geometry, using a compact data window with an oversized tile size, so header validation accepts it while later allocation math overflows. Delivery paths include email attachments, web downloads, media processing pipelines, and shared asset repositories consumed by 32-bit build targets.

// Patch excerpt: src/lib/OpenEXR/ImfArray.h
// Fix integer overflow in Array2D::resizeErase() on ILP32/LLP64 builds (#2486)
 #define INCLUDED_IMF_ARRAY_H

 #include "ImfForward.h"
+#include "IexBaseExc.h"
+
+#include <cstddef>

 //-------------------------------------------------------------------------
 //
// Source: https://github.com/AcademySoftwareFoundation/openexr/commit/71907b44ce9a1b05bf3934b8a7821752750731ab

Detection Methods for CVE-2026-59186

Indicators of Compromise

EXR files whose header declares a tileXSize or tileYSize far larger than the dataWindow dimensions, such as a 40x40 window paired with 65537x65537 tiles.
Crashes or SIGSEGV in processes linked against OpenEXR shared libraries (libIlmImf, libOpenEXR) on 32-bit hosts.
Heap corruption traces referencing Imf::Array2D<Rgba>::resizeErase or TiledRgbaInputFile::readTile in core dumps.

Detection Strategies

Statically inspect EXR file headers before ingestion and reject files where tile_size * sizeof(pixel) exceeds a sane upper bound.
Instrument media processing services with AddressSanitizer or heap canaries during CI to catch out-of-bounds writes triggered by fuzzed EXR corpora.
Correlate abnormal termination of image processing workers with recent EXR file arrivals in shared storage or upload buckets.

Monitoring Recommendations

Monitor endpoint telemetry for crash events in image viewers, DCC tools, and web media services that link OpenEXR.
Log the version of OpenEXR loaded by production pipelines and alert when a 32-bit binary loads a vulnerable version.
Track inbound EXR uploads with anomalous header-to-tile ratios in content ingestion gateways.

How to Mitigate CVE-2026-59186

Immediate Actions Required

Upgrade OpenEXR to 3.2.11, 3.3.13, or 3.4.14 across all build targets, prioritizing 32-bit and ILP32 systems.
Rebuild and redistribute any first-party applications that statically link OpenEXR after upgrading the dependency.
Restrict acceptance of EXR files from untrusted sources until patched builds are deployed.

Patch Information

The issue is fixed in OpenEXR 3.2.11, 3.3.13, and 3.4.14. The upstream fixes are tracked in commits 71907b44, 904141d3, and b1a58873. See the GitHub Security Advisory GHSA-f667-c4wm-c8gq for full details.

Workarounds

Build and run OpenEXR consumers on 64-bit (LP64) platforms, where the size calculation does not truncate.
Pre-validate EXR headers in a wrapper that rejects tile dimensions greater than the data window size.
Sandbox EXR decoding in an isolated process with strict resource limits so heap corruption cannot pivot into the host application.

bash

# Validate installed OpenEXR version and confirm patch level
pkg-config --modversion OpenEXR
# Expected output: 3.2.11, 3.3.13, or 3.4.14 (or later)

# On Debian/Ubuntu, upgrade the distribution package
sudo apt-get update && sudo apt-get install --only-upgrade libopenexr-3-1-30