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.

There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - 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. (CVE-2026-44663)

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - 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. (CVE-2026-44663)

Note that Nessus relies on the presence of the package as reported by the vendor.

The version of the OpenEXR Python package installed on the remote host is 3.4.x prior to 3.4.12. It is, therefore, affected by multiple vulnerabilities:

  - 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. At line 188-189, decode->channels[i].width is multiplied by     decode->channels[i].bytes_per_element in 32-bit signed arithmetic. When width >= 536870912 with FLOAT channels,     the product exceeds INT32_MAX, causing signed integer overflow. The overflowed value is stored in     raster_line_offset and later used as a pointer offset, resulting in an out-of-bounds write past the     heap-allocated decompression buffer. (CVE-2026-44663)

  - OpenEXR's HTJ2K decoder, ht_undo_impl() in OpenEXRCore, copies decoded pixels out of a per-line OpenJPH buffer     using the EXR channel's declared width as the iteration count. The codestream embedded in the EXR chunk can     declare different (smaller) tile/line dimensions than the EXR header advertises, but ht_undo_impl() does not     validate this. A crafted EXR file produces a 4-byte heap-buffer-overflow READ immediately after a buffer     allocated by ojph::local::codestream::finalize_alloc(). The result is a deterministic crash (DoS) and potential     adjacent-heap leak. (CVE-2026-45696)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The version of FreeBSD installed on the remote host is prior to tested version. It is, therefore, affected by multiple vulnerabilities as referenced in the ca91c020-5820-11f1-b38d-9be2e6022e28 advisory.

    Cary Phillips reports:
    [The OpenEXR 3.4.12] release addresses the following security vulnerabilities:

Tenable has extracted the preceding description block directly from the FreeBSD security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

ID	Name	Product	Family	Type	Severity
465919	Echo: openexr: security update to 3.1.13-2	Tenable Cloud Security	Echo Local Security Checks	Local	high
465919	Echo: openexr: security update to 3.1.13-2	Tenable Self-Hosted Container Security	Echo Local Security Checks	Local	high
321778	Linux Distros Unpatched Vulnerability : CVE-2026-44663	Nessus	Misc.	Local	high
321448	Python Library OpenEXR 3.4.x < 3.4.12 Multiple Vulnerabilities	Nessus	Misc.	Local	high
317389	FreeBSD : OpenEXR -- 3.4.12 fixes multiple vulnerabilities (ca91c020-5820-11f1-b38d-9be2e6022e28)	Nessus	FreeBSD Local Security Checks	Local	high

Detections

Analytics

CVE-2026-44663

high

Tenable Plugins

high

high

high

high

high