Description

OpenEXR is the reference implementation and specification for the EXR image format, widely used in the motion picture industry. OpenEXR versions 3.2.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 a heap out-of-bounds read. The issue occurs when a crafted RLE-compressed EXR causes the 64-bit unpacked size to truncate before allocation in OpenEXRCore decoding.c and unpack_32bit() reads beyond the resulting buffer, allowing denial of service. This issue is fixed in versions 3.2.11, 3.3.13, and 3.4.14.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.5",
  "pubDate": "2026-08-25T19:16:51.820Z",
  "pubdate": "2026-08-25T19:16:51.820Z",
  "executiveSummary": "OpenEXR is susceptible to a heap out-of-bounds read vulnerability impacting ILP32 builds within specific version ranges (3.2.0–3.2.10, 3.3.0–3.3.12, and 3.4.0–3.4.13). The flaw arises from an integer truncation issue during the decompression of RLE-encoded EXR image data. When processing a maliciously crafted file, the application calculates an unpacked buffer size that undergoes truncation on 32-bit platforms, leading to insufficient heap allocation. Subsequently, the decoder performs out-of-bounds memory access while writing decompressed data, potentially resulting in process instability or a denial of service (DoS). The vulnerability is restricted to environments where the architecture treats integers as 32 bits, limiting the scope of exploitation to specific system configurations. Successfully triggering the vulnerability requires an attacker to provide a specially crafted EXR file that adheres to the RLE compression specification but contains metadata designed to trigger the truncation logic. No authentication or elevated privileges are required for exploitation if the target application processes untrusted EXR files. Given the nature of the crash, the primary risk implication is service interruption.",
  "technicalDetails": "The vulnerability resides in the OpenEXRCore library, specifically within the decoding logic for RLE-compressed images. The root cause is an integer truncation flaw occurring during the calculation of the expected unpacked data size for RLE blocks. In the ILP32 data model, where 'int', 'long', and 'pointer' types are all 32 bits, the 64-bit size value required to represent the unpacked image data is incorrectly handled or cast before allocation.\nDuring the execution of OpenEXRCore/decoding.c and specifically the unpack_32bit() function, the library attempts to determine the heap memory requirements for the decompressed RLE stream. A crafted EXR file can define metadata parameters that result in a 64-bit size value that, when truncated to a 32-bit representation during the allocation routine, results in a significantly smaller buffer than required. Because the memory allocator succeeds in providing this smaller buffer, the subsequent decompression loop in unpack_32bit() proceeds under the assumption that the buffer is of sufficient size.\nThe exploitation flow is as follows: 1) The attacker crafts an EXR file with an RLE-compressed data block designed to exceed the truncated allocation size. 2) The victim application parses the EXR header using OpenEXRCore. 3) The library invokes unpack_32bit() to process the payload. 4) The calculation for the destination buffer size wraps around or truncates due to the 32-bit architecture constraint. 5) A heap buffer is allocated based on the truncated value. 6) The RLE decoding process executes, writing decompressed bytes sequentially into the allocated buffer. 7) Once the write index surpasses the end of the undersized heap buffer, the process performs an out-of-bounds read/write operation. Depending on the memory layout and surrounding heap metadata, this generally leads to an immediate segmentation fault or heap corruption, resulting in a denial of service. The vulnerability is highly dependent on the architecture; therefore, non-ILP32 (64-bit) builds are generally unaffected as they do not suffer from the same integer truncation behavior during the size calculation. No authentication is required to trigger this vulnerability, as it is a client-side parsing error triggered by the ingestion of untrusted input."
}