OpenEXR EUVD-2026-86273

Exploitation requires the victim to open or otherwise parse an attacker-supplied .exr file using OpenEXR's C++ attribute-parsing path; the file must contain an unknown-type attribute with dataSize set to zero, which drives the OpaqueAttribute constructor to memcpy from a NULL packed_data pointer. Limiting factors: the vector is local (AV:L) and requires user interaction (UI:R) - the attacker cannot trigger it remotely without the target application ingesting the crafted file - and the impact is confined to crashing the parsing process (availability only, no code execution or data disclosure). Affects OpenEXR 3.4.14 per the description; fixed by the zero-size guard in PR #2615.

This is a low-to-moderate severity, availability-only issue. The provided CVSS 3.1 vector (AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H, base 5.5) is internally consistent with the description: exploitation requires a local vector (a crafted .exr file must be parsed by the victim's application) and user interaction (opening/loading the file), and the only impact is process termination - a denial of service with no confidentiality or integrity loss. No EPSS score, CISA KEV entry, or public exploit code is present in the input, so exploitation status is 'no public exploit identified at time of analysis.' The single-null-check root cause is trivially understood from the public PR diff, which lowers the barrier to writing a crash PoC, but the practical impact is bounded: crashing an image parser is a nuisance-level DoS, not RCE. This is not a top-priority, mass-exploitation candidate; it is a routine memory-safety hardening fix best handled via normal patch cycles. Note the CPE and EUVD product/vendor fields are 'n/a', so affected-product enumeration must be derived from the description (OpenEXR) rather than structured metadata.

An attacker crafts a malicious .exr file containing an unknown-type attribute whose dataSize field is set to zero, then delivers it to a victim (e.g., as an asset in a VFX/rendering pipeline, a downloaded texture, or an email attachment). When the victim's application uses OpenEXR to parse the file, the OpaqueAttribute constructor calls memcpy() with a NULL packed_data pointer and zero size, triggering undefined behavior and process termination. No public exploit code is identified, but the fix diff publicly reveals the exact trigger condition.