PyOpenEXR CVE-2026-68513

Exploitation requires that the target application invoke OpenEXR.File() using PyOpenEXR with separate_channels=False, which is the default and requires no special configuration to trigger. The crafted EXR file must contain both a literal channel whose name matches the group key produced by coalescing a set of dot-prefixed RGB channels - for example, a channel named 'left' alongside channels 'left.R', 'left.G', and 'left.B'. The CVSS vector specifies AV:L (the file must be accessible on the local system or within a process's file-open path) and UI:R (a user or automated job must invoke the open call). Applications that explicitly pass separate_channels=True are fully protected as the coalescing path is not entered. No authentication or elevated privileges are required (PR:N). Exploitation is further limited to integrity and availability impact only - no confidentiality data exposure results from the heap overflow. In unattended pipeline deployments that ingest untrusted EXR submissions automatically, the UI:R barrier is effectively absent, making those environments the highest-risk targets.

The CVSS 3.1 score of 7.1 (AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:H) places this vulnerability in the file-borne exploitation class: an attacker cannot exploit it over the network without first convincing a user or automated system to process a malicious EXR file, which limits opportunistic mass-scale attacks compared to network-reachable vulnerabilities. No EPSS score was provided in the input; with AV:L and UI:R, exploitation probability in a general enterprise context is low. The vulnerability is not listed in the CISA KEV catalog and no public proof-of-concept exploit has been identified, further reducing urgency for most organizations. However, PyOpenEXR is commonly embedded in automated rendering pipelines and asset-ingest systems that process untrusted artist-submitted files without human review - in these pipeline contexts the UI:R barrier is effectively removed because file processing is programmatic, which meaningfully raises practical exploitability above what the raw CVSS vector implies. SSVC assessment: exploitation status is none confirmed, automatable is conditionally yes in unattended ingest pipelines, technical impact is partial (integrity and availability, no confidentiality). Studios and organizations running automated EXR ingestion should treat this with higher urgency than a simple 7.1 local score would suggest.

An attacker crafts a flat scanline EXR file containing channels named 'left', 'left.R', 'left.G', and 'left.B', then delivers it to a VFX studio's automated asset-ingest pipeline or persuades a user to open it in a Python-based compositing tool. When the application calls OpenEXR.File(path) with the default separate_channels=False, the coalescing logic collides the literal 'left' key with the synthesized RGB group key 'left', allocates a NumPy array sized for only one channel's data, and then writes three additional RGB pixel planes into it during decode, causing an out-of-bounds heap write that crashes the process or corrupts adjacent heap metadata. No public proof-of-concept exploit code has been identified at time of analysis.