CVE-2026-59187: OpenEXR Buffer Overflow Vulnerability

CVE-2026-59187 Overview

CVE-2026-59187 is a heap out-of-bounds write vulnerability in OpenEXR, the reference implementation of the EXR image format used extensively in the motion picture industry. The flaw resides in the exrmetrics utility and triggers when it processes a crafted deep scanline EXR file with pixel conversion options such as --pixelmode float or --bench. The DeepSlice structure requests FLOAT output while the backing sample buffers are allocated based on the input HALF element size, producing a size mismatch that corrupts the heap. The issue affects OpenEXR versions 3.3.0 through 3.3.12 and 3.4.0 through 3.4.13, and is fixed in versions 3.3.13 and 3.4.14.

Critical Impact
A crafted EXR file processed by exrmetrics can trigger heap corruption, leading to process crash or possible integrity impact on the host system.

Affected Products

OpenEXR 3.3.0 through 3.3.12
OpenEXR 3.4.0 through 3.4.13
Downstream tools and pipelines bundling the vulnerable exrmetrics binary

Discovery Timeline

2026-08-25 - CVE-2026-59187 published to NVD
2026-08-25 - Last updated in NVD database

Technical Details for CVE-2026-59187

Vulnerability Analysis

The vulnerability is a classic heap buffer overflow classified under [CWE-122]. exrmetrics iterates channels from the input header when sizing the per-sample buffers, but later requests FLOAT output from DeepSlice. A HALF channel uses 2 bytes per sample, while FLOAT uses 4 bytes. When the writer stores FLOAT samples into buffers sized for HALF, it writes past the allocation boundary and corrupts adjacent heap memory.

The overflow occurs during read and conversion of deep scanline images, a data-dense format that stores multiple samples per pixel. Because the buffer under-allocation is deterministic for HALF inputs, an attacker with control over the input file can produce reliable heap corruption. Exploitation requires the user to invoke exrmetrics on the malicious file with a pixel conversion flag.

Root Cause

The root cause is a mismatch between the channel type used to size sample buffers and the channel type declared to the DeepSlice output. The pre-patch code sized buffers using in.header().channels() (the input header, containing HALF) while output was configured for FLOAT. The patch corrects this by iterating outHeader.channels(), ensuring buffer sizing matches the output element width.

Attack Vector

Exploitation requires a victim to run exrmetrics against an attacker-supplied EXR file with pixel conversion options such as --pixelmode float or --bench. User interaction is required, and the attack surface includes automated media pipelines, batch conversion jobs, and CI systems that process untrusted EXR content.

cpp

// Security patch in src/bin/exrmetrics/exrmetrics.cpp
// Fix deep pixelmode heap buffer overflow in exrmetrics (#2487)

    sampleData.resize (numChans);
    channelNumber = 0;
-    for (ChannelList::ConstIterator i = in.header ().channels ().begin ();
-         i != in.header ().channels ().end ();
+    for (ChannelList::ConstIterator i = outHeader.channels ().begin ();
+         i != outHeader.channels ().end ();
         ++i)
    {
        int samplesize = pixelTypeSize (i.channel ().type);

Source: OpenEXR commit 46e7022

Detection Methods for CVE-2026-59187

Indicators of Compromise

Unexpected crashes or abort signals from exrmetrics processes handling third-party EXR content
Heap corruption diagnostics from AddressSanitizer or glibc malloc checks when parsing deep scanline EXR files
EXR files containing deep scanline data with HALF channels processed under --pixelmode float or --bench

Detection Strategies

Inventory build systems, render farms, and media pipelines for the exrmetrics binary version and flag versions in the 3.3.0–3.3.12 and 3.4.0–3.4.13 ranges
Monitor for exrmetrics invocations against files originating outside trusted repositories or from external submissions
Enable ASan or fuzzing in CI environments that process EXR inputs to surface heap violations early

Monitoring Recommendations

Log command-line arguments for exrmetrics executions, focusing on --pixelmode and --bench flags
Alert on child-process termination via SIGABRT or SIGSEGV for media conversion utilities
Track file provenance for EXR assets ingested by automated pipelines

How to Mitigate CVE-2026-59187

Immediate Actions Required

Upgrade OpenEXR to version 3.3.13 or 3.4.14, which contain the fix
Audit media processing pipelines for calls to exrmetrics and restrict use to trusted input files until patching completes
Remove or disable the exrmetrics binary on systems that do not require it

Patch Information

The upstream fix is available in the Academy Software Foundation OpenEXR repository. See the GitHub Security Advisory GHSA-6jj8-cxcr-j8hm and the patch commits 46e7022 and 7e772dd. Both patches change the channel iteration to use outHeader.channels() so buffer sizing matches the output pixel type.

Workarounds

Avoid invoking exrmetrics with --pixelmode float or --bench on untrusted EXR files
Run exrmetrics inside a sandbox or container with least-privilege file system access to contain heap corruption effects
Validate EXR inputs and reject deep scanline files from untrusted sources until upgrades are applied

bash

# Verify installed OpenEXR version and upgrade
exrmetrics --version

# Debian/Ubuntu example
sudo apt update && sudo apt install --only-upgrade openexr

# Build from source: check out fixed tag
git clone https://github.com/AcademySoftwareFoundation/openexr.git
cd openexr
git checkout v3.4.14   # or v3.3.13
cmake -B build -S . && cmake --build build --target install