OpenEXR EUVD-2026-65696

Exploitation requires that (1) the target application links against a vulnerable version of the OpenEXR library (before 3.2.11, 3.3.0-3.3.12, or 3.4.0-3.4.13), (2) the application calls Imf::GetChannelsInMultiPartFile() on an EXR file - meaning multipart EXR processing must be exercised, not just single-part reads, and (3) a user or automated process opens or processes the crafted EXR file (UI:R per CVSS). What limits exploitation: the attack vector is local file-open rather than network-reachable, no authentication bypass or privilege escalation is involved, and the sole impact is a process crash. Applications that validate EXR files against trusted sources or that sandbox file parsing would substantially reduce exposure.

The NVD CVSS 3.1 score of 5.5 (AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H) accurately characterises the real-world risk: impact is limited to a process crash with no confidentiality or integrity consequence, and the attack vector is local file-open, requiring user interaction. No KEV listing and no public POC code have been identified, placing this at low operational urgency for most organizations. The 'Information Disclosure' tag supplied with the CVE is inconsistent with both the description and the CVSS C:N metric - no confidentiality impact is described; this tag likely reflects a tagging artifact and should not be treated as confirmed. EPSS data was not provided; given the niche file-format vector and absence of POC, exploitation probability is expected to be low. The primary risk population is render-farm operators, VFX studios, and applications that auto-ingest untrusted EXR files (e.g., asset review tools), where a crafted file could crash a pipeline worker process.

An attacker crafts an EXR image file containing a multiView header attribute set to an empty list, then delivers it to a target via email, shared asset storage, or a malicious download. When a VFX artist or automated render-pipeline process opens or ingests the file using a vulnerable OpenEXR build, Imf::GetChannelsInMultiPartFile() triggers the out-of-bounds read in viewFromChannelName(), crashing the application or worker process. No public proof-of-concept code is known at time of analysis, but constructing such a file requires only basic EXR format knowledge.