Openexr CVE-2026-34379

Victim must open a crafted EXR file with DWA or DWAB compression containing FLOAT-type channels in an application using vulnerable OpenEXR versions 3.2.0-3.2.6, 3.3.0-3.3.8, or 3.4.0-3.4.8. Remote unauthenticated attacker sends malicious file; victim interaction required.

The CVSS base score of 7.1 reflects high availability impact with low integrity impact, requiring user interaction (opening a crafted file). The attack vector is network-based with low complexity and no authentication requirements (AV:N/AC:L/PR:N/UI:R), making weaponization straightforward via email attachments, web downloads, or supply chain insertion into media production pipelines. Real-world risk is elevated for organizations processing untrusted EXR files from external sources, particularly those running ARM-based rendering farms or Apple Silicon workstations where the crash is deterministic. On x86 systems, exploitation difficulty increases but compiler-dependent memory corruption remains theoretically possible. No EPSS score, KEV listing, or public exploit code is present in available data, suggesting exploitation has not been observed in the wild. However, the detailed technical disclosure in the GitHub advisory (GHSA-w88v-vqhq-5p24) provides sufficient information for exploit development. The vendor has released patches across all affected branches (3.2.7, 3.3.9, 3.4.9), significantly reducing remediation friction. Priority should be elevated for organizations using ARM/RISC-V architectures or processing media files from untrusted sources, while x86 environments face primarily denial-of-service risk.

An attacker crafts a malicious EXR file with DWA compression and FLOAT-type channels, embedding it in a visual effects asset package or distributing it via a stock media library. When a visual effects artist or automated rendering pipeline opens the file using vulnerable OpenEXR versions on an ARM-based render farm, the unaligned memory write triggers an immediate crash, disrupting production workflows. On x86 systems with aggressive compiler optimizations, repeated processing of the malicious file could potentially corrupt adjacent memory structures, though achieving reliable code execution would require significant reverse engineering of the specific compiler output and runtime memory layout.