Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.5",
  "pubDate": "2026-08-25T18:17:57.060Z",
  "pubdate": "2026-08-25T18:17:57.060Z",
  "executiveSummary": "This vulnerability is an out-of-bounds write flaw affecting OpenEXR versions 3.1.0 through 3.2.10, 3.3.0 through 3.3.12, and 3.4.0 through 3.4.13. The issue specifically impacts ILP32 builds, where 32-bit pointer and long data models are utilized.\nThe vulnerability arises from an integer truncation during the calculation of the scratch buffer size when processing B44-compressed scanline EXR files. This truncation leads to an undersized memory allocation.\nBy providing a crafted EXR file, an attacker can trigger the uncompress_b44_impl() function to perform writes that extend beyond the boundaries of the allocated buffer. The impact includes potential memory corruption and denial of service (DoS) conditions.\nThe vulnerability is addressable via vendor-provided patches. Organizations utilizing OpenEXR on ILP32 architectures should prioritize updating to versions 3.2.11, 3.3.13, or 3.4.14 to remediate this security risk.",
  "technicalDetails": "The root cause of this vulnerability lies in the memory management logic within the B44 decompression routine for EXR images. Specifically, when calculating the size requirements for the scratch buffer prior to allocation, the logic fails to account for potential integer overflows or truncations that occur within the 32-bit (ILP32) memory model. When a maliciously crafted EXR file containing B44-compressed data is processed, the logical scratch size calculation undergoes truncation, resulting in a buffer allocation that is smaller than what is required for the subsequent decompression process.\nThe exploitation occurs within the uncompress_b44_impl() function. Because the scratch buffer size is truncated, the allocated memory is insufficient to hold the decompressed output. The implementation then proceeds to write to this buffer using parameters derived from the attacker-controlled channel width metadata within the file header. Since the bounds check is bypassed due to the truncated size calculation, the write operation occurs outside the valid memory range of the heap-allocated buffer.\nThe attack flow proceeds as follows: First, the attacker creates a malformed EXR file with specific channel width parameters designed to force an integer truncation in the size allocation calculation for a B44-compressed scanline. Second, the OpenEXR library parses this header and performs a heap allocation based on the truncated result. Third, when the uncompress_b44_impl() function attempts to populate the buffer, it utilizes the unvalidated, attacker-supplied channel width, resulting in an out-of-bounds write operation. This leads to the corruption of adjacent heap memory, which may cause a crash (Denial of Service) or, depending on the memory layout and surrounding data structures, potentially lead to arbitrary code execution or unauthorized information disclosure.\nThis vulnerability is specific to ILP32 builds, where the size of pointers and the 'long' data type are 32 bits, making them more susceptible to integer truncation compared to LP64 or LLP64 architectures. The exploit does not require authentication, as the vulnerability is triggered during the standard parsing and decompression of an image file, making it accessible to any process or user capable of supplying an input file to the library."
}