OpenEXR CVE-2026-59981

Exploitation requires three concrete conditions to be simultaneously true. First, the target application must use the OpenEXRUtil library (not just core OpenEXR) and specifically call the row() accessor on a SampleCountChannel or the equivalent row() on a TypedDeepImageChannel or flat image channel. Second, the opened EXR file must be a deep image (not a flat image) with a non-zero dataWindow origin - the severity of the out-of-bounds displacement scales directly with the magnitude of dataWindow.min.y; a large negative vertical origin produces the worst-case pointer displacement. Third, user interaction (UI:R per CVSS) is required: a human or automated job must open or process the attacker-controlled file. Exploitation is limited by the requirement for UI:R (no direct network-triggerable path without a victim action), by the fact that only applications using the OpenEXRUtil abstraction layer are affected (applications using only the lower-level Imf:: reading APIs are not), and by the need for heap layout control to advance beyond a crash to meaningful information disclosure.

The CVSS 7.1 score appropriately reflects a denial-of-service-primary, confidentiality-secondary vulnerability. The High availability impact (A:H) is realistic - a crafted file triggers an out-of-bounds read that will crash most applications. The Low confidentiality impact (C:L) reflects the described scenario where adjacent heap memory may be returned as sample-count values, which could expose in-process data; however, this requires a controlled heap layout and is therefore difficult to reliably exploit for information disclosure. AC:L is plausible because the trigger condition (non-zero dataWindow origin) is a standard, easily crafted EXR attribute. No EPSS data was supplied, limiting quantitative exploitation-probability comparison. Neither a public exploit nor a CISA KEV entry exists, so real-world exploitation risk is currently theoretical. The primary realistic threat is pipeline crashes in automated VFX render farms or batch-processing workflows that ingest untrusted EXR assets without sandboxing. High-privilege RCE is not ruled out under adversarial heap shaping but is not demonstrated; treating this as a crasher with limited information-disclosure potential is the defensible posture until more evidence emerges.

An attacker uploads a crafted deep EXR file to a media asset management system or shares it via collaboration tooling targeting a VFX studio's compositing pipeline. An artist or automated render worker opens the file in an application using the OpenEXRUtil layer (such as a compositor or batch transcoder); the application calls SampleCountChannel::row() to iterate sample counts, which resolves to a pointer far before the allocated buffer due to the large negative vertical dataWindow origin embedded in the file. The process crashes, and under a controlled heap layout the misaligned reads may surface adjacent heap contents as sample-count data returned to the caller.