Openexr EUVD-2026-24041

Exploitation requires a crafted EXR file that (1) uses the HTJ2K compression codec, (2) specifies 16,385 or more FLOAT channels, and (3) declares a width approaching the HTJ2K maximum of 32,767 pixels per scanline. The vulnerability is NOT triggered by default EXR files or standard image specifications; it demands a specific combination of channel count and width that causes bpl to exceed INT_MAX. Additionally, exploitation is contingent on the host system's memory allocator permitting the ~64 GB allocation required during decompression. Memory-constrained systems (typical servers, desktop workstations) will fail the allocation and never reach the overflow condition, resulting in benign out-of-memory handling. Only systems with aggressive memory overcommit or sufficient virtual memory can trigger the heap corruption. No special OpenEXR configuration is required beyond having HTJ2K support enabled (standard in official releases). Remote attackers can deliver a malicious EXR file without authentication.

The CVSS v3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L) indicates remote network exploitation without authentication or user interaction against default configurations, yielding a base score of 5.3 (Medium). The attack is low-complexity and requires no privileges. However, real-world risk is heavily constrained by memory availability. On memory-constrained hosts (typical servers, endpoints), the ~64 GB heap allocation required to trigger the vulnerability will fail, causing a benign out-of-memory exception before ht_undo_impl() is entered - no out-of-bounds write occurs. Only on allocator-permissive systems with adequate virtual memory (e.g., certain server configurations with overcommit enabled, or systems processing untrusted media files) does the wrapped bpl value produce heap corruption, enabling code execution or severe denial of service. The score of 5.3 reflects denial-of-service impact (Availability, not Confidentiality/Integrity) on reachable systems. Active exploitation is not confirmed (KEV status unknown from input); no public POC is referenced. The vulnerability requires a specifically crafted EXR file, not a trivial input. Remediation is straightforward: upgrade to 3.4.10. The practical risk to most deployments is low-to-moderate unless they process untrusted EXR files on systems with generous memory allocation policies.

A threat actor crafts a malicious EXR file specifying 16,385 FLOAT channels at the maximum HTJ2K width of 32,767 pixels and delivers it via email, web upload, or a media library. When a VFX workstation or rendering farm node opens the file using OpenEXR 3.4.0-3.4.9, the ht_undo_impl() function attempts to allocate ~64 GB and, on a system with memory overcommit or generous virtual memory, proceeds to decompress. The signed integer overflow in bpl wraps to a negative value, causing subsequent per-scanline pointer arithmetic to write out of bounds, corrupting the heap and potentially achieving code execution or crashing the renderer.