Description

OpenEXR is the reference implementation and specification for the EXR image file format, widely used in the motion picture industry. In versions through 3.2.10, 3.3.0 through 3.3.12, and 3.4.0 through 3.4.13, the OpenEXRUtil library returns an out-of-bounds pointer from the SampleCountChannel::row() API when a deep image has a non-zero dataWindow origin. The row() accessor is documented as 0-based and computes its address from an internal base that is offset for absolute pixel coordinates, so the two coordinate models conflict whenever dataWindow.min is non-zero. For a deep image whose data window has a large negative vertical origin, row(0) points far outside the allocated sample-count buffer. An application that opens an attacker-controlled deep EXR file and accesses sample counts through row() performs an out-of-bounds read, which can crash the process or, under a controlled heap layout, return adjacent heap memory as sample-count values. 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:16:58.907Z",
  "pubdate": "2026-08-25T20:16:58.907Z",
  "executiveSummary": "The OpenEXR image library contains a critical out-of-bounds pointer vulnerability within the OpenEXRUtil library, specifically affecting the SampleCountChannel::row() API. This flaw arises from a conflict between the expected 0-based indexing of the API and the internal buffer offset logic used when handling deep EXR files with non-zero dataWindow origins. The vulnerability primarily impacts applications that process untrusted deep EXR files.\nSuccessful exploitation allows an attacker to trigger an out-of-bounds memory read. Depending on the memory layout, this can result in a denial-of-service condition via process crash or the potential leakage of sensitive data residing in adjacent heap memory. The vulnerability is present in OpenEXR versions 3.2.10 and earlier, 3.3.0 through 3.3.12, and 3.4.0 through 3.4.13. Mitigation requires upgrading to fixed versions 3.2.11, 3.3.13, or 3.4.14. The flaw does not require authentication or specific privilege levels, as it is triggered locally by the parsing of a maliciously crafted image file.",
  "technicalDetails": "The vulnerability resides in the OpenEXRUtil component of the OpenEXR library. It is triggered during the invocation of the SampleCountChannel::row() accessor method, which is intended to return a pointer to the sample count data for a specific image row. The core issue is a coordinate system mismatch: the API expects 0-based indexing (row 0 to N), but the underlying implementation calculates the memory address based on an internal base offset that accounts for absolute pixel coordinates, specifically the dataWindow origin.\nWhen a deep EXR file specifies a non-zero dataWindow.min origin, the mathematical calculation of the pointer offset becomes misaligned with the actual allocated buffer boundaries. In scenarios where the deep image has a large negative vertical origin, the formula used in row() results in an address that points significantly outside the bounds of the memory allocated for the sample-count buffer. When an application attempts to access this returned pointer, it performs an out-of-bounds read operation.\nThe exploitation flow proceeds as follows: 1) An attacker provides a maliciously crafted deep EXR file containing a specifically defined, large negative vertical dataWindow origin. 2) An application utilizing an affected version of OpenEXR parses the EXR file and calls the SampleCountChannel::row(0) function. 3) The library calculates an erroneous memory address based on the malformed metadata. 4) The application accesses the calculated address. If the accessed address resides in unmapped memory, the process experiences a segmentation fault, leading to a crash (Denial of Service). If the address resides within a mapped heap region, the application reads data from that memory location as if it were valid sample-count data. This could potentially allow an attacker to influence program logic or exfiltrate adjacent heap data, depending on how the application processes the returned sample counts.\nThis vulnerability is an input-validation issue resulting in memory corruption. It is not dependent on network exposure or specific user privileges, as it is triggered solely by the processing of the malformed image data. The vulnerability is present in versions through 3.2.10, 3.3.0 through 3.3.12, and 3.4.0 through 3.4.13."
}