CVE-2026-59984 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. OpenEXR versions 3.1.0 through 3.2.10, 3.3.0 through 3.3.12, and 3.4.0 through 3.4.13 are vulnerable on ILP32 builds to an out-of-bounds write. When a crafted B44-compressed scanline EXR causes the logical scratch size to truncate before allocation and uncompress_b44_impl() writes using the attacker-controlled channel width, allowing denial of service and memory corruption. This issue is fixed in versions 3.2.11, 3.3.13, and 3.4.14.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/25/2026
OpenEXR serves as the reference implementation for the EXR image format, a standard extensively utilized within the motion picture industry for high-dynamic-range imaging and visual effects workflows. The vulnerability identified in this library affects specific version ranges including 3.1.0 through 3.2.10, 3.3.0 through 3.3.12, and 3.4.0 through 3.4.13 when compiled for ILP32 architectures. This architecture typically refers to systems where integers, longs, and pointers are all thirty-two bits wide, such as many modern Linux distributions running on x86-64 processors in compatibility mode or certain embedded environments. The core of the issue lies within the B44 compression algorithm implementation, which is designed for efficient storage of high-resolution images by compressing data blocks using a floating-point DCT-based method common in film production pipelines.
The technical flaw manifests as an out-of-bounds write resulting from integer truncation during memory allocation calculations. Specifically, when processing a crafted EXR file containing B44-compressed scanlines, the function responsible for determining the logical scratch size fails to account for potential overflow or truncation errors inherent in ILP32 builds. This miscalculation leads to an insufficient buffer being allocated on the heap. Subsequently, the uncompress_b44_impl() routine proceeds to write data into this undersized buffer using a channel width value controlled by the attacker via the malformed input file. Because the allocation size does not match the actual amount of data written due to the truncation error, memory beyond the bounds of the allocated block is overwritten. This constitutes a classic heap-based out-of-bounds write vulnerability that compromises memory safety guarantees provided by modern compilers and operating systems.
The operational impact of this vulnerability is severe, primarily enabling denial of service through application crashes caused by segmentation faults or access violations when corrupted memory regions are accessed later in execution. More critically, the ability to perform an arbitrary out-of-bounds write opens pathways for remote code execution if an attacker can carefully craft the payload to overwrite adjacent heap metadata or function pointers. This aligns with CWE-787 Out-of-Bounds Write and CWE-190 Integer Overflow or Wraparound in its root cause classification. In the context of attack frameworks, this vulnerability facilitates exploitation techniques categorized under ATT&CK Tactic TA0004 Privilege Escalation and TA0005 Defense Evasion by allowing attackers to manipulate process memory state for malicious purposes. Given that OpenEXR is often used as a backend library in larger applications such as image viewers, compositing software like Nuke or After Effects, and rendering pipelines, the attack surface extends beyond just the library itself to any application linking against it without proper input validation at higher levels.
Mitigation strategies focus primarily on upgrading to patched versions of OpenEXR which address these integer handling issues in the B44 decompression logic. Users should update to version 3.2.11, 3.3.13, or 3.4.14 and later releases where the scratch size calculation has been corrected to prevent truncation on ILP32 builds. For organizations unable to immediately patch their dependencies, implementing strict input validation at the application layer is recommended. This includes verifying file headers and metadata before passing data to the OpenEXR library for decompression. Additionally, deploying runtime memory protection mechanisms such as Address Sanitizer during development or using heap hardening techniques in production environments can help detect or mitigate exploitation attempts of this class of vulnerability until a full patch deployment is achieved across all affected systems.