CVE-2026-55373: OpenEXR SampleCountChannel DOS Vulnerability

CVE-2026-55373 Overview

CVE-2026-55373 is an infinite-loop vulnerability in OpenEXR, the reference implementation for the EXR image format used across the motion picture industry. The flaw resides in the roundListSizeUp() helper within SampleCountChannel. When processing a sample-list size equal to UINT_MAX, repeated unsigned left shifts wrap the 32-bit value to zero, and the loop never terminates. The bug is reachable through public OpenEXRUtil APIs, either through SampleCountChannel::Edit or by calling SampleCountChannel::set(x, y, UINT_MAX) on a valid pixel. Affected versions have been patched in 3.2.10, 3.3.12, and 3.4.13.

Critical Impact
A local attacker can trigger an unrecoverable infinite loop in applications linking OpenEXR, exhausting CPU resources and causing a denial-of-service condition against image processing pipelines.

Affected Products

OpenEXR versions prior to 3.2.10 (3.2.x branch)
OpenEXR versions prior to 3.3.12 (3.3.x branch)
OpenEXR versions prior to 3.4.13 (3.4.x branch)

Discovery Timeline

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

Technical Details for CVE-2026-55373

Vulnerability Analysis

The vulnerability is classified as [CWE-190] Integer Overflow or Wraparound, manifesting as an infinite loop denial-of-service. OpenEXR's SampleCountChannel uses a helper called roundListSizeUp() to round a sample-list size up to the next power of two. The routine performs this rounding through repeated unsigned left shifts of a 32-bit value.

For normal inputs, the shift sequence terminates once the value exceeds or equals the target size. However, when the input equals UINT_MAX (0xFFFFFFFF), the sequence reaches 0x80000000, and the next left shift wraps the 32-bit value to zero. Since zero remains less than UINT_MAX, the loop condition never becomes false. The thread executing the routine spins indefinitely, consuming a full CPU core.

Root Cause

The root cause is missing boundary validation on the sample-count input combined with reliance on unsigned shift arithmetic that silently truncates. The roundListSizeUp() helper does not check for the pathological UINT_MAX value or detect the wraparound to zero, so the exit condition is unreachable for that specific input.

Attack Vector

Exploitation requires local access to an application that consumes attacker-influenced OpenEXR content or exposes the affected OpenEXRUtil APIs. Two reachable paths exist: editing the sample-count buffer through SampleCountChannel::Edit, whose destructor invokes endEdit(), or calling SampleCountChannel::set(x, y, UINT_MAX) on a valid pixel. Both paths funnel into roundListSizeUp() and trigger the infinite loop.

The vulnerability manifests during in-process image handling. See the GitHub Security Advisory for technical details on the affected code paths.

Detection Methods for CVE-2026-55373

Indicators of Compromise

Processes linking libOpenEXR or libOpenEXRUtil consuming 100% of a CPU core with no forward progress in stack samples
Repeated stack frames referencing SampleCountChannel::endEdit or roundListSizeUp in thread dumps
Rendering, compositing, or thumbnail worker processes hanging when handling untrusted EXR files

Detection Strategies

Inspect OpenEXR library versions across build systems, render farms, and media asset pipelines to identify installations below 3.2.10, 3.3.12, or 3.4.13
Sample long-running image processing threads with perf, py-spy, or platform equivalents to identify hot loops inside SampleCountChannel
Correlate EXR file ingestion events with sudden CPU saturation on the same host to identify triggering inputs

Monitoring Recommendations

Alert on image-processing workers exceeding runtime and CPU thresholds when handling a single input file
Track version inventory of OpenEXR across container images and workstation deployments using software composition analysis
Log and retain samples of EXR files that caused worker terminations for offline analysis

How to Mitigate CVE-2026-55373

Immediate Actions Required

Upgrade OpenEXR to version 3.2.10, 3.3.12, or 3.4.13 depending on the branch in use
Rebuild and redeploy any downstream applications that statically link OpenEXR against a fixed release
Restrict processing of untrusted EXR files to sandboxed workers with enforced CPU and wall-clock limits

Patch Information

The OpenEXR maintainers fixed the issue in versions 3.2.10, 3.3.12, and 3.4.13. The patch adds proper handling of the UINT_MAX boundary in roundListSizeUp() so that the shift loop terminates for all valid unsigned 32-bit inputs. Refer to the OpenEXR GitHub Security Advisory GHSA-mff9-68x3-h8rh for the authoritative fix commit and release notes.

Workarounds

Enforce per-process CPU time limits on OpenEXR consumers using ulimit -t, setrlimit(RLIMIT_CPU), or container CPU quotas
Validate sample-count values before invoking SampleCountChannel::set in application code and reject inputs equal to UINT_MAX
Isolate EXR parsing in short-lived worker processes that can be terminated by a supervisor when they exceed expected runtimes

bash

# Configuration example: enforce CPU time limit on EXR processing workers
ulimit -t 30
systemd-run --scope -p CPUQuota=100% -p RuntimeMaxSec=30 \
  /usr/local/bin/exr-worker --input /path/to/untrusted.exr