CVE-2026-44663
MediumCVSS 6.1Exploitation Probability (EPSS)
Low risk10th percentile — higher than 10% of all known CVEs
Summary
In OpenEXR versions 3.4.0 through 3.4.11, an integer overflow in ht_undo_impl() in internal_ht.cpp leads to a heap-buffer overflow when decoding a crafted HTJ2K-compressed EXR file. The multiplication of channel width (int32_t) by bytes_per_element in 32-bit signed arithmetic can overflow, causing an out-of-bounds write. The same pattern appears in two other HTJ2K paths.
Risk Assessment
An attacker could exploit this vulnerability to execute arbitrary code or cause a denial of service via a malicious EXR file, posing a significant risk to systems using OpenEXR in motion picture production or other applications.
Recommendation
Immediately update OpenEXR to version 3.4.12, which contains the fix. Before updating, avoid opening EXR files from untrusted sources.
Original NVD description (English source)
OpenEXR is the reference implementation and specification for the EXR image format, widely used in the motion picture industry. In versions 3.4.0 through 3.4.11, an integer overflow in ht_undo_impl() in src/lib/OpenEXRCore/internal_ht.cpp leads to a heap-buffer overflow when decoding a crafted HTJ2K-compressed EXR file. decode->channels[i].width (int32_t) is multiplied by bytes_per_element in 32-bit signed arithmetic. With large widths (e.g., >= 536870912 for FLOAT data), this overflows, producing a corrupted offset that is later used for pointer arithmetic and can cause a heap out-of-bounds write. The same unchecked multiplication pattern appears in two other HTJ2K paths (bytes-per-line accumulation and pixel-line pointer advancement). As with related CVE-2026-34378 through CVE-2026-34589 fixes in other codecs, validating only after the multiplication is too late because the value may already be overflowed. This issue has been fixed in version 3.4.12.