OpenEXR EUVD-2026-37944

Exploitation requires the target to decode an attacker-supplied EXR file that uses HTJ2K compression and declares an oversized channel width (for FLOAT data, width >= 536870912) sufficient to overflow the 32-bit width*bytes_per_element multiplication in ht_undo_impl(). The victim application must use OpenEXR 3.4.0-3.4.11 and must actually process the malicious file (CVSS UI:R); there is no remote network-triggered path. Limiting factors: the attack is local/file-based (AV:L), needs no privileges (PR:N) but does need the file to be opened or auto-ingested, only affects pipelines that accept the HTJ2K codec, and is fixed in 3.4.12. The specific width threshold means only crafted inputs trigger the overflow, not arbitrary malformed files.

Signals are largely consistent and point to a real but not urgent issue. The CVSS 3.1 vector (AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:H, base 7.1) reflects a file-parsing bug: exploitation is local and requires the victim to process a malicious EXR file (UI:R), with no confidentiality impact but high integrity and availability impact. EPSS is low (0.17%, 7th percentile) and CISA SSVC marks Exploitation: none, Automatable: no, Technical Impact: partial - all reinforcing that this is not under active or automated exploitation. There is no KEV listing and no public exploit identified. Realistic risk is highest for software that automatically ingests untrusted EXR files (render farms, asset pipelines, image-processing services, thumbnailers), where the UI:R barrier is effectively met by automated processing. One nuance: while CVSS scores integrity and availability as High, whether the heap out-of-bounds write is reliably weaponizable into code execution versus a crash is not established in the available data - treat code execution as plausible but unconfirmed.

An attacker crafts a malicious EXR file with an HTJ2K-compressed channel declaring a very large width (e.g., >= 536870912 for FLOAT data) and submits it to a target that decodes EXR images - for example uploading it to a VFX asset pipeline, render service, or image converter using OpenEXR. When the victim application decodes the file, the 32-bit multiplication overflows and the corrupted offset drives a heap out-of-bounds write. No public exploit is identified at this time, and the local vector plus required processing of the file (UI:R, AC:L) means a crash is the most certain outcome, with memory corruption potentially escalatable.