OpenEXR CVE-2026-59982

Exploitation requires three concurrent conditions: the target application must use the OpenEXRUtil API's row() method on a deep or flat image channel (not merely the core OpenEXR I/O layer); the processed EXR file must specify a nonzero dataWindow origin, which is a valid EXR format configuration but not the most common default; and a user or automated process must open or ingest the crafted file (confirmed by UI:R in the CVSS vector). The defect does not affect applications that use the core EXR reading API without the TypedDeepImageChannel, TypedFlatImageChannel, or SampleCountChannel row() methods from OpenEXRUtil. Information disclosure is further bounded by heap memory layout in the affected process - an attacker cannot arbitrarily choose what memory is read. Authentication is not required per CVSS PR:N, but the UI:R constraint means fully passive, zero-click exploitation is not possible.

The CVSS 7.1 rating accurately reflects the primary risk profile: no authentication is required, attack complexity is low, but user interaction - opening a crafted EXR file - is a hard prerequisite per UI:R, ruling out fully automated exploitation without social engineering or pipeline infiltration. The high availability impact (A:H) reflects a deterministic crash path, while the limited confidentiality impact (C:L) acknowledges that the out-of-bounds read can expose adjacent heap memory but is bounded by the process address space and heap layout. No EPSS score was supplied in the source data, so exploitation probability cannot be numerically quantified; however, the absence from CISA KEV and the lack of any reported public exploit code at time of analysis both suggest this has not been actively weaponized. The CWE-190 integer overflow tag may cause confusion in automated scanner triage, since the root cause is a pointer arithmetic origin mismatch rather than a classic arithmetic overflow - security teams should verify their scanner correctly identifies the affected component (OpenEXRUtil, not just the core OpenEXR library). The real-world priority is highest for organizations that ingest EXR content from untrusted external sources, such as studios receiving third-party assets or render farms processing externally submitted jobs; environments where EXR files originate only from internal, trusted tools face meaningfully lower realistic risk despite the network-vector CVSS rating.

An attacker crafts a deep EXR image with a nonzero dataWindow origin (e.g., origin at coordinates 1024, -1024 as demonstrated by the added regression test) and delivers it to a target via email attachment, a shared asset repository, or a malicious render farm submission. When a VFX artist or automated pipeline processes the file using a vulnerable OpenEXR-linked application, TypedDeepImageChannel::row(0) returns a pointer before the allocated buffer, triggering either a process crash or exposure of adjacent heap memory contents. No public proof-of-concept has been identified at time of analysis, though the regression test added in the patch provides a clear reproduction blueprint for researchers.