OpenEXR CVE-2026-59985

Two conditions must hold simultaneously: the target must be running an ILP32 build of OpenEXR (where size_t and int are 32 bits - typical of 32-bit ARM, x86, or MIPS embedded/cross-compiled targets, not standard x86-64 or arm64 builds), AND a user or automated process must open a specially crafted RLE-compressed .exr file supplied by the attacker. Standard 64-bit LP64 builds are unaffected because the 64-bit size value is not truncated. The UI:R CVSS metric confirms that some form of file-open action is required; purely passive network exposure without file processing does not trigger the flaw. Exploitation is limited to denial of service (process crash); no code execution or confidentiality impact is confirmed from available data.

The CVSS 5.5 score reflects a local attack vector (AV:L), low complexity (AC:L), no privileges required (PR:N), mandatory user interaction (UI:R), no scope change, and availability-only impact (A:H). The local vector is consistent with file-based exploitation - the attacker delivers a malicious .exr file that a local user or process opens, rather than attacking over a network. The critical constraining factor is the ILP32 build requirement: modern x86-64 Linux, macOS, and Windows deployments use LP64 where size_t is 64 bits, making this path unreachable on the majority of production systems. This meaningfully narrows the real-world exposure beyond what the CVSS score alone implies. No CISA KEV listing and no public POC exist, indicating no confirmed active exploitation. Input tags include 'Information Disclosure' but the CVSS vector scores C:N - this discrepancy suggests the out-of-bounds read has theoretical information-disclosure potential but only denial of service is confirmed from available data. Real-world risk is low-to-moderate overall but elevated for any 32-bit build pipeline or embedded media-processing system that ingests untrusted EXR files.

An attacker crafts an .exr file containing an RLE-compressed block whose declared 64-bit unpacked size, when truncated on an ILP32 system, causes the allocator to provision a buffer smaller than the actual decompressed payload. When a victim user opens the file - or an automated render farm ingest script processes it via exrmetrics or the OpenEXRCore library - unpack_32bit() reads past the buffer boundary and crashes the decoding process. No public exploit code exists, but the trigger primitive is straightforward given that parsing begins immediately on file open.