CVE-2026-61555: OpenEXR DOS Vulnerability in EXR Processing

CVE-2026-61555 Overview

OpenEXR is the reference implementation and specification for the EXR image format used across the motion picture industry. CVE-2026-61555 is an out-of-bounds read vulnerability [CWE-125] in Imf::viewFromChannelName() triggered when Imf::GetChannelsInMultiPartFile() processes a crafted EXR file. A malicious file containing an empty multiView header attribute and a dotless channel name causes the function to index an empty vector, resulting in a crash. The flaw affects OpenEXR versions before 3.2.11, 3.3.0 through 3.3.12, and 3.4.0 through 3.4.13. The issue is fixed in versions 3.2.11, 3.3.13, and 3.4.14.

Critical Impact
A crafted EXR file can crash any local application or pipeline component that parses multi-part EXR images using vulnerable OpenEXR versions.

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

Technical Details for CVE-2026-61555

Vulnerability Analysis

The vulnerability resides in Imf::viewFromChannelName() within src/lib/OpenEXR/ImfMultiView.cpp. When the function processes a channel name lacking a dot separator, it assumes the associated multiView header attribute vector contains at least one entry representing the default view. The code performs multiView[0] without validating that the vector is non-empty. An attacker who supplies an EXR file containing an empty multiView attribute and any dotless channel name forces an out-of-bounds read on the empty vector, terminating the parsing process.

Exploitation requires local file processing with user interaction, meaning a victim must open or process the crafted EXR file. Impact is limited to availability: the parser aborts, disrupting rendering pipelines, image viewers, and batch conversion workflows that depend on OpenEXR.

Root Cause

The root cause is missing input validation on the multiView header attribute. The viewFromChannelName() routine trusted that a well-formed EXR file always provides a non-empty view list, but the specification did not enforce this invariant at parse time. The fix replaces the direct index access with a call to defaultViewName(multiView), which safely handles the empty case.

Attack Vector

An attacker crafts an EXR file with a zero-length multiView attribute in the header and at least one channel with a name that contains no . separator. When a target application invokes GetChannelsInMultiPartFile() on this file, viewFromChannelName() is called and reads past the bounds of the empty vector, crashing the host process.

cpp

// Patch in src/lib/OpenEXR/ImfMultiView.cpp
         // in the name belong to the default view.
         //
 
-        return multiView[0];
+        return defaultViewName (multiView);
     }
     else
     {
// Source: https://github.com/AcademySoftwareFoundation/openexr/commit/6c6bc2d485f1435d3776b3b4a36f1617cf87070b

Detection Methods for CVE-2026-61555

Indicators of Compromise

Unexpected termination of image processing tools, DCC applications, or render nodes when opening EXR assets from untrusted sources.
Crash dumps or core files referencing Imf::viewFromChannelName or Imf::GetChannelsInMultiPartFile in the stack trace.
EXR files whose header contains a multiView attribute of type stringvector with zero entries alongside channels lacking a . separator.

Detection Strategies

Inventory installed OpenEXR libraries and application-bundled copies across workstations and render farms, flagging versions below 3.2.11, 3.3.13, or 3.4.14.
Parse EXR headers at ingest boundaries to reject files where multiView is present but empty.
Monitor process telemetry for repeated abnormal exits of image pipeline binaries such as oiiotool, DCC applications, and custom renderers.

Monitoring Recommendations

Forward crash reports and application exit codes from media production hosts to a centralized log platform for correlation.
Alert on ingestion of EXR files from external submitters that trigger parser faults during automated preview or thumbnail generation.
Track OpenEXR library versions in software bills of materials (SBOMs) to identify vulnerable downstream products.

How to Mitigate CVE-2026-61555

Immediate Actions Required

Upgrade OpenEXR to version 3.2.11, 3.3.13, or 3.4.14 depending on your deployed release branch.
Rebuild and redistribute any first-party applications that statically link OpenEXR against the patched version.
Restrict processing of EXR files originating from untrusted or external sources until patches are deployed.

Patch Information

The fix replaces the unchecked multiView[0] access with defaultViewName(multiView), which safely returns the default view when the vector is empty. See the GitHub Security Advisory GHSA-g8f2-r72m-48vx and the corresponding fix commits: commit 6c6bc2d, commit b4257c7, and commit c6d3796.

Workarounds

Pre-validate EXR files with a lightweight header parser and quarantine any file containing an empty multiView attribute.
Sandbox image processing workers so a parser crash does not disrupt broader rendering or ingest pipelines.
Disable automatic preview or thumbnail generation for EXR uploads from untrusted users until patching is complete.

bash

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

# Debian/Ubuntu upgrade example
sudo apt-get update && sudo apt-get install --only-upgrade libopenexr-3-1-30

# Build from patched source
git clone --branch v3.4.14 https://github.com/AcademySoftwareFoundation/openexr.git
cd openexr && cmake -B build && cmake --build build --target install