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, the HTJ2K (High-Throughput JPEG 2000) decoder, ht_undo_impl() in OpenEXRCore is vulnerable to a heap-buffer-overflow READ. The ht_undo_imp function 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 — it pulls width 32-bit samples from cur_line->i32[] without checking the OpenJPH line buffer's actual length. A crafted EXR file produces a 4-byte heap-buffer-overflow READ immediately after a buffer allocated by ojph::local::codestream::finalize_alloc(). The bug is reachable through the standard scanline-decode entry point used by every consumer of exr_decoding_run/Imf::checkOpenEXRFile, including thumbnailers, asset pipelines, and the exrcheck utility — i.e. any application that opens untrusted EXR files. The result is a deterministic crash (DoS) and potential adjacent-heap leak. This issue has been fixed in version 3.4.12.

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, the HTJ2K (High-Throughput JPEG 2000) decoder,     ht_undo_impl() in OpenEXRCore is vulnerable to a heap-buffer-overflow READ. The ht_undo_imp function     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  it pulls width     32-bit samples from cur_line->i32[] without checking the OpenJPH line buffer's actual length. A crafted     EXR file produces a 4-byte heap-buffer-overflow READ immediately after a buffer allocated by     ojph::local::codestream::finalize_alloc(). The bug is reachable through the standard scanline-decode entry     point used by every consumer of exr_decoding_run/Imf::checkOpenEXRFile, including thumbnailers, asset     pipelines, and the exrcheck utility  i.e. any application that opens untrusted EXR files. The result is a     deterministic crash (DoS) and potential adjacent-heap leak. This issue has been fixed in version 3.4.12.
    (CVE-2026-45696)

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	Severity
321771	Linux Distros Unpatched Vulnerability : CVE-2026-45696	Nessus	Misc.	high
321448	Python Library OpenEXR 3.4.x < 3.4.12 Multiple Vulnerabilities	Nessus	Misc.	high
317389	FreeBSD : OpenEXR -- 3.4.12 fixes multiple vulnerabilities (ca91c020-5820-11f1-b38d-9be2e6022e28)	Nessus	FreeBSD Local Security Checks	high

Detections

Analytics

CVE-2026-45696

high

Tenable Plugins

high

high

high