CVE-2026-55373 in OpenEXR
Summary
by MITRE • 08/25/2026
OpenEXR is the reference implementation and specification for the EXR image format, widely used in the motion picture industry. Versions prior to 3.2.10, 3.3.12, and 3.4.13 contain an infinite-loop vulnerability in SampleCountChannel. The helper roundListSizeUp() rounds a sample-list size up to the next power of two using repeated unsigned left shifts, which terminates for normal values but fails for UINT_MAX: the sequence reaches 0x80000000, and the next left shift wraps the 32-bit value to 0. Because 0 remains less than UINT_MAX, the loop never progresses and never exits. The bug is reachable through public OpenEXRUtil APIs, either by editing the sample-count buffer through SampleCountChannel::Edit (whose destructor calls endEdit()) or by calling SampleCountChannel::set(x, y, UINT_MAX) on a valid pixel. This issue has been fixed in versions 3.2.10, 3.3.12, and 3.4.13.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/25/2026
OpenEXR serves as the reference implementation for the EXR image format, which is extensively utilized within the motion picture industry for high-dynamic-range imaging workflows. A critical flaw exists in versions prior to 3.2.10, 3.3.12, and 3.4.13 involving an infinite loop vulnerability located within the SampleCountChannel component. This defect arises from a logical error in the helper function roundListSizeUp(), which is designed to round a sample-list size up to the next power of two using repeated unsigned left shifts. While this algorithm functions correctly for standard input values, it fails catastrophically when processing the maximum possible value for an unsigned 32-bit integer, UINT_MAX.
The technical root cause lies in how signed and unsigned arithmetic interactions are handled during bit manipulation operations. When the function processes UINT_MAX, represented as all bits set to one, repeated left shifting eventually results in a value of 0x80000000. In many implementations or subsequent logical checks involving this specific boundary condition, further shifting causes the value to wrap around to zero due to overflow behavior inherent in fixed-width integer arithmetic. Since the loop termination condition relies on comparing the current shifted value against UINT_MAX, and because zero is strictly less than UINT_MAX, the conditional check remains perpetually true. Consequently, the loop enters an infinite state from which it cannot escape without external intervention or process termination.
This vulnerability is reachable through public OpenEXRUtil APIs, making it exploitable by applications that integrate these libraries for image processing tasks. Attackers can trigger this condition either by editing the sample-count buffer via SampleCountChannel::Edit, where the destructor invokes endEdit() and subsequently calls the flawed rounding logic, or directly by invoking SampleCountChannel::set with a coordinate pair and setting one of the dimensions to UINT_MAX on a valid pixel. The presence of such an infinite loop in image parsing libraries poses significant operational risks, primarily manifesting as denial-of-service conditions where application threads hang indefinitely consuming CPU resources without progressing further execution.
From a security classification perspective, this issue aligns with CWE-835, which describes loops that never terminate due to logic errors involving integer overflow or boundary condition failures. It also relates to CWE-400 regarding uncontrolled resource consumption resulting from the infinite loop behavior. In terms of adversary tactics, this vulnerability could be leveraged within ATT&CK technique T1496, Resource Hijacking, specifically for denial-of-service scenarios where an attacker exhausts system resources by causing a thread to hang in an endless computation cycle.
The severity of this flaw is compounded by its accessibility through public APIs and the commonality of processing untrusted or malformed image files in professional workflows. Mitigation strategies must prioritize immediate upgrading to patched versions, specifically 3.2.10, 3.3.12, or 3.4.13, which contain corrections for this arithmetic boundary condition. For environments where updating is not immediately feasible, input validation mechanisms should be implemented at the application layer to reject sample counts that approach integer limits before they are passed to OpenEXR utility functions. Additionally, implementing timeout guards on image processing threads can provide a secondary defense-in-depth measure against potential denial-of-service attacks exploiting this logic error.