Description

OpenEXR is the reference implementation and specification for the EXR image format, widely used in the motion picture industry. In versions before 3.2.11, 3.3.0 through 3.3.12, and 3.4.0 through 3.4.13, exrmultiview can write past a heap allocation when it combines two attacker-supplied, individually valid scanline EXR files whose union dataWindow is not aligned to one view's channel subsampling. The utility allocates sampled channel storage using a truncated union_width / xSampling, then reads the sampled input through a Slice based on the misaligned union window, producing a heap out-of-bounds write. The trigger is normal public-tool processing, such as exrmultiview left A.exr right B.exr out.exr with crafted but valid inputs, so this is not solely an API or caller-precondition issue. 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": "7.1",
  "pubDate": "2026-08-25T20:17:02.780Z",
  "pubdate": "2026-08-25T20:17:02.780Z",
  "executiveSummary": "This vulnerability involves a heap-based out-of-bounds write in the exrmultiview utility within the OpenEXR library.\nThe flaw occurs during the process of combining two valid scanline EXR files when the union dataWindow is not properly aligned with the channel subsampling of the views.\nThe vulnerability affects OpenEXR versions prior to 3.2.11, 3.3.0 through 3.3.12, and 3.4.0 through 3.4.13.\nAn attacker can leverage this flaw by providing specifically crafted EXR files to the exrmultiview command-line utility, leading to memory corruption.\nThe impact includes potential arbitrary code execution or application crashes, posing significant security risks to systems processing untrusted image data in the motion picture industry pipeline.\nNo authentication or elevated privileges are required for exploitation as the vulnerability is triggered by standard tool usage with malicious input files.\nThe risk is high due to the widespread integration of OpenEXR in media production environments.",
  "technicalDetails": "The root cause of the vulnerability is an integer arithmetic error and improper buffer sizing within the exrmultiview utility when calculating heap allocation sizes for sampled channel storage.\nSpecifically, the utility calculates the required storage by performing a truncated division: (union_width / xSampling). This calculation fails to account for cases where the union of the dataWindow is not perfectly aligned with the channel subsampling requirements of the individual views being combined.\nWhen a user executes exrmultiview with two crafted EXR files, the application logic assumes the calculated buffer size is sufficient for the subsequent data copy operation. However, due to the misalignment, the actual data read from the input Slice is larger than the truncated allocation size.\nThe exploitation flow proceeds as follows: First, an attacker generates two valid but malicious scanline EXR files where the union of their respective dataWindows results in a dimension that triggers the rounding/truncation error in the allocation function. Second, the user processes these files via the vulnerable exrmultiview command-line interface. Third, the utility allocates a heap buffer based on the incorrect, smaller size. Finally, the internal read routine copies the image data into this undersized buffer, resulting in an out-of-bounds heap write.\nThis operation results in memory corruption adjacent to the heap allocation, which an attacker can potentially control to overwrite function pointers, object metadata, or other critical structures in the heap. This can lead to hijacking the control flow of the application if an attacker achieves a successful primitive for arbitrary code execution.\nThe issue is not limited to API-level usage; it is directly exploitable through public-tool processing, making it a critical risk for any automated media pipeline using these versions of OpenEXR.\nAffected versions include OpenEXR before 3.2.11, the 3.3.0-3.3.12 range, and the 3.4.0-3.4.13 range."
}