CVE-2026-68515: OpenEXR Buffer Overflow Vulnerability

CVE-2026-68515 Overview

CVE-2026-68515 is a heap-based buffer overflow [CWE-122] in OpenEXR, the reference implementation for the EXR image format used across the motion picture industry. The flaw resides in the exrmultiview utility, which combines multiple scanline EXR files into a single multi-view output. When two attacker-supplied files present a union dataWindow that is not aligned to a view's channel subsampling, the tool writes past a heap allocation. Processing occurs through normal command-line usage, so the issue is not limited to API misuse. Affected versions include OpenEXR releases prior to 3.2.11, 3.3.0 through 3.3.12, and 3.4.0 through 3.4.13.

Critical Impact
A crafted pair of individually valid EXR files can trigger a heap out-of-bounds write in exrmultiview, enabling integrity and availability compromise on the processing host.

Affected Products

OpenEXR versions before 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-68515 published to NVD
2026-08-26 - Last updated in NVD database

Technical Details for CVE-2026-68515

Vulnerability Analysis

The defect lives in src/bin/exrmultiview/makeMultiView.cpp. exrmultiview computes a union dataWindow from two input files and allocates sampled channel storage using a truncated union_width / xSampling. It then reads sampled input through an Imf::Slice based on the misaligned union window. When the union width is not a multiple of the channel's xSampling, the truncation shrinks the allocation while the slice iteration still walks the full window, producing a heap out-of-bounds write.

An attacker only needs to supply two individually valid scanline EXR files. The trigger is standard tool invocation such as exrmultiview left A.exr right B.exr out.exr, which shifts the risk boundary from library callers to any workflow that runs the shipped binary on untrusted media.

Root Cause

The root cause is missing validation of channel subsampling relative to the union dataWindow. The allocation math applied integer truncation without ensuring alignment, allowing the slice engine to reference bytes outside the allocated heap region.

Attack Vector

Exploitation requires local access and user interaction: a user or automated pipeline must run exrmultiview against crafted inputs. Successful exploitation corrupts heap memory, yielding process crashes and potential integrity loss in the produced assets or the process address space.

cpp

// Patch: src/bin/exrmultiview/makeMultiView.cpp
            string         inChanName = j.name ();
            string outChanName = insertViewName (inChanName, viewNames, i);

+           if (inChannel.xSampling != 1 || inChannel.ySampling != 1)
+               THROW (IEX_NAMESPACE::ArgExc,
+                      "no support for subsampling:"
+                      << " channel " << inChanName
+                      << " of " << inFileNames[i]
+                      << " has subsampling " << inChannel.xSampling
+                      << ", " << inChannel.ySampling);
+
            image.addChannel (outChanName, inChannel);
            image.channel (outChanName).black ();
// Source: https://github.com/AcademySoftwareFoundation/openexr/commit/77ee19c021398b1c56f32c3af8347e365dbd4f33

The patch rejects any input channel whose xSampling or ySampling is not 1, eliminating the misalignment path before allocation occurs.

Detection Methods for CVE-2026-68515

Indicators of Compromise

Unexpected crashes or aborts of the exrmultiview process during batch rendering or ingest workflows.
Presence of EXR files with non-default channel xSampling or ySampling values processed by multi-view tooling.
Heap corruption signatures reported by AddressSanitizer or the OS crash reporter for exrmultiview.

Detection Strategies

Inventory hosts and pipelines that invoke exrmultiview and correlate execution telemetry with source file provenance.
Scan build artifacts and container images for vulnerable OpenEXR versions prior to 3.2.11, 3.3.13, or 3.4.14.
Enable memory-safety instrumentation (ASan, hardened allocators) in staging environments that process untrusted EXR inputs.

Monitoring Recommendations

Alert on process termination signals (SIGABRT, SIGSEGV) originating from exrmultiview or wrapping media pipelines.
Log command-line arguments passed to OpenEXR utilities to identify processing of externally sourced files.
Monitor for anomalous child processes spawned from render farm or CI workers running EXR tooling.

How to Mitigate CVE-2026-68515

Immediate Actions Required

Upgrade OpenEXR to 3.2.11, 3.3.13, or 3.4.14 on all systems that ship or invoke exrmultiview.
Rebuild and redistribute container images, render farm agents, and DCC plugin bundles that vendor OpenEXR.
Restrict exrmultiview execution to trusted content until patches are deployed.

Patch Information

The issue is fixed in OpenEXR 3.2.11, 3.3.13, and 3.4.14. Reference commits 77ee19c0, c644ac2d, and e2300a3d on the Academy Software Foundation repository, published alongside GitHub Security Advisory GHSA-gjf7-wjjw-xq56. The fix rejects channels with non-unit xSampling or ySampling in makeMultiView.cpp.

Workarounds

Pre-validate incoming EXR files and reject any channel with xSampling != 1 or ySampling != 1 before invoking exrmultiview.
Sandbox the exrmultiview binary with seccomp, AppArmor, or container isolation to contain heap corruption impact.
Route untrusted EXR content through a quarantined pre-processing stage that normalizes subsampling before multi-view assembly.

bash

# Reject EXR inputs with non-unit channel subsampling before processing
exrheader input.exr | awk '/xSampling|ySampling/ {if ($3 != 1) exit 1}' \
  && exrmultiview left A.exr right B.exr out.exr \
  || echo "Rejected: unsupported channel subsampling in input"