Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - OpenEXR 是 EXR 影像格式的參考實作和規範，廣泛應用於電影產業。在 的版本3.4.03.4.11中，OpenEXRCore 中的 HTJ2K （High-Throughput JPEG 2000） 解碼器 ht_undo_impl（） 容易受到堆積緩衝區溢位 READ 的影響。ht_undo_imp 函式會使用 EXR 通道宣告的寬度作為反覆專案計數，將解碼的圖元從每行 OpenJPH 緩衝區複製出來。內嵌在 EXR 區塊中的程式碼流可以宣告與 EXR 標頭公告的圖塊/線尺寸不同（更小），但 ht_undo_impl（） 不會驗證這一點，它會從 cur_line->i32[] 提取寬度 32 位元樣本，而無需檢查 OpenJPH 線緩衝區的實際長度。特製的 EXR 檔案會在 ojph：：local：：codestream：：finalize_alloc（） 配置的緩衝區之後立即產生 4 位元組堆積緩衝區溢位 READ。此錯誤可透過 exr_decoding_run/Imf：：checkOpenEXRFile 的每個消費者使用的標準掃描線解碼進入點來達成，包括縮圖、資產管線和 exrcheck 公用程式，即任何開啟不受信任 EXR 檔案的應用程式。結果是確定性損毀 （DoS） 和潛在的相鄰堆積洩漏。3.4.12 版已修正此問題。
    (CVE-2026-45696)

請注意，Nessus 依賴供應商報告的套件存在。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - OpenEXR 是 EXR 图像格式的参考实现和规范，广泛应用于电影行业。在 HTJ2K （High-Throughput JPEG 2000） 解码器 OpenEXRCore 中的 ht_undo_impl（） 版本3.4.11中3.4.0，容易受到堆缓冲区溢出读取的影响。ht_undo_imp 函数使用 EXR 通道声明的宽度作为迭代计数，将解码后的像素从每行 OpenJPH 缓冲区复制出来。内嵌在 EXR 区块中的码流可声明与 EXR 标头所宣传的不同（小）平铺/线条尺寸，但 ht_undo_impl（） 不会对此进行验证;它会从 cur_line->i32[] 中提取宽度的 32 位示例，而不检查 OpenJPH 线路缓冲区的实际长度。特制的 EXR 文件在 ojph：：local：：codestream：：finalize_alloc（） 分配缓冲区之后立即生成 4 字节堆缓冲区溢出读取。可通过每个 exr_decoding_run/Imf：：checkOpenEXRFile 使用者使用的标准扫描线解码入口点访问该错误，包括缩略图、资产管道和 exrcheck 实用工具（即任何打开不受信任的 EXR 文件的应用程序）。结果是确定性崩溃 （DoS） 和潜在的相邻堆泄漏。此问题已在 3.4.12 版本中修复。
    (CVE-2026-45696)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

遠端主機上安裝的 OpenEXR Python 套件版本早於 3.4.x3.4.12。因此，會受到多個弱點影響：

  - 解碼特製的 HTJ2K 壓縮 EXR 檔案時，src/lib/OpenEXRCore/internal_ht.cpp 中 ht_undo_impl（） 中的整數溢位會導致堆積緩衝區溢位。在行 188-189中，decode->channels[i].width 乘以 decode->channels[i].bytes_per_element，採用 32 位帶正負號算術。當寬度 >= 536870912時，具有 FLOAT 通道，乘積會超過 INT32_MAX，造成帶正負號的整數溢位。溢位的值會儲存在raster_line_offset中，稍後會用作指標位移，導致越界寫入超過堆積配置的解壓縮緩衝區。（CVE-2026-44663）

  - OpenEXR 的 HTJ2K 解碼器 OpenEXRCore 中的 ht_undo_impl（） 使用 EXR 通道宣告的寬度作為迭代計數，將解碼的像素從每行 OpenJPH 緩衝區複製出來。內嵌在 EXR 區塊中的程式碼串流可以宣告與 EXR 標頭通告的圖塊/線條尺寸不同 （更小），但 ht_undo_impl（） 不會驗證這一點。特製的 EXR 檔案會在 ojph：：local：：codestream：：finalize_alloc（） 配置的緩衝區之後立即產生 4 位元組堆積緩衝區溢位 READ。結果是確定性損毀 （DoS） 和潛在的相鄰堆積洩漏。（CVE-2026-45696）

請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

远程主机上安装的 OpenEXR Python 程序包版本低于 3.4.x3.4.12. 因此，该应用程序受到多个漏洞的影响：

  - src/lib/OpenEXRCore/internal_ht.cpp 的 ht_undo_impl（） 中的一个整数溢出导致在解码构建的 HTJ2K 压缩的 EXR 文件时发生堆缓冲区溢出。在行 188-189中，decode->channels[i].width 乘以 32 位有符号算法中的 decode->channels[i].bytes_per_element。当宽度 >= 536870912，具有 FLOAT 通道时，乘积超过 INT32_MAX，从而造成有符号的整数溢出。溢出值存储在 raster_line_offset 中，稍后会用作指针偏移，从而导致越界写入超出堆分配的解压缩缓冲区。（CVE-2026-44663）

  - OpenEXR 的 HTJ2K 解码器 OpenEXRCore 中的 ht_undo_impl（），使用 EXR 通道声明的宽度作为迭代计数，将解码后的像素复制到每行 OpenJPH 缓冲区之外。嵌入在 EXR 区块中的码流可以声明与 EXR 标头所宣传的不同（更小）的平铺/线条尺寸，但 ht_undo_impl（） 未对此进行验证。特制的 EXR 文件在 ojph：：local：：codestream：：finalize_alloc（） 分配缓冲区之后立即生成 4 字节堆缓冲区溢出读取。结果是确定性崩溃 （DoS） 和潜在的相邻堆泄漏。（CVE-2026-45696）

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

リモートホストにインストールされているOpenEXR Pythonパッケージのバージョンは3.4.12より前の3.4.xです。そのため、以下の複数の脆弱性の影響を受けます。

  - src/lib/OpenEXRCore/internal_ht.cppのht_undo_impl()の整数オーバーフローにより、細工されたHTJ2K圧縮EXRファイルをデコードするときにヒープバッファオーバーフローが発生します。188-189行目で、decode->channels[i].widthに32ビット符号付き演算でdecode->channels[i].bytes_per_elementを乗算します。FLOAT チャネルで width >= 536870912の場合、積が INT32_MAX を超え、符号付き整数オーバーフローが発生します。オーバーフローの値が raster_line_offset に保存され、後でポインターオフセットとして使用されるため、ヒープ割り当て展開バッファを超えた領域外書き込みが発生します。(CVE-2026-44663)

  - OpenEXRのHTJ2Kデコーダー(OpenEXRCoreのht_undo_impl())は、EXRチャンネルの宣言された幅を反復カウントとして使用して、デコードされたピクセルを行ごとのOpenJPHバッファからコピーします。EXR チャンクに埋め込まれたコードストリームは、EXR ヘッダーがアドバタイズするものとは異なる(小さい)タイル/ラインの寸法を宣言できますが、ht_undo_impl() はこれを検証しません。細工されたEXRファイルは、ojph::local::codestream::finalize_alloc()によって割り当てられたバッファの直後に4バイトのヒープバッファオーバーフロー読み取りを生成します。その結果、決定論的クラッシュ(DoS)と隣接ヒープリークが発生する可能性があります。(CVE-2026-45696)

Nessus はこれらの問題をテストしておらず、代わりにアプリケーションが自己報告するバージョン番号にのみ依存していることに注意してください。

Linux/Unix ホストには、ベンダーが提供するパッチが利用できない脆弱性の影響を受ける複数のパッケージがインストールされています。

  - OpenEXR は、映画業界で広く使用されている EXR 画像形式の参照実装および仕様です。バージョン 3.4.0 から 3.4.11では、OpenEXRCoreのHTJ2K(ハイスループットJPEG 2000)デコーダーであるht_undo_impl()は、ヒープバッファオーバーフローの読み取りに対して脆弱です。ht_undo_imp関数は、EXRチャンネルの宣言された幅を反復カウントとして使用して、デコードされたピクセルを行ごとのOpenJPHバッファーからコピーします。EXRチャンクに埋め込まれたcodestreamは、EXRヘッダーがアドバタイズするものとは異なる(小さい)タイル/ラインの寸法を宣言できますが、ht_undo_impl()はこれを検証しません。OpenJPHラインバッファの実際の長さをチェックせずに、幅32ビットのサンプルをcur_line->i32[]からプルします。細工されたEXRファイルは、ojph::local::codestream::finalize_alloc()によって割り当てられたバッファの直後に4バイトのヒープバッファオーバーフロー読み取りを生成します。このバグは、サムネーラー、アセットパイプライン、exrcheckユーティリティ(信頼できないEXRファイルを開くアプリケーションなど)exr_decoding_run/Imf::checkOpenEXRFileのすべてのユーザーが使用する標準のスキャンラインデコードエントリポイントを介して発生する可能性があります。その結果、決定論的クラッシュ(DoS)と隣接ヒープリークが発生する可能性があります。この問題はバージョン 3.4.12で修正されています。
    (CVE-2026-45696)

Nessus は、ベンダーによって報告されたパッケージの存在に依存していることに注意してください。

リモートホストにインストールされている FreeBSD のバージョンは、テスト済みバージョンより前です。したがって、ca91c020-5820-11f1-b38d-9be2e6022e28 のアドバイザリに記載されている複数の脆弱性の影響を受けます。

    Cary Phillips 氏の報告:
    [OpenEXR 3.4.12]リリースは、次のセキュリティの脆弱性に対処しています:

Tenable は、前述の記述ブロックを FreeBSD セキュリティアドバイザリから直接抽出しています。

Nessus はこれらの問題をテストしておらず、代わりにアプリケーションが自己報告するバージョン番号にのみ依存していることに注意してください。

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.

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.

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
321771	Linux Distros 未修補弱點：CVE-2026-45696	Nessus	Misc.	2026/6/20	2026/8/27	high
321771	Linux Distros 未修补的漏洞：CVE-2026-45696	Nessus	Misc.	2026/6/20	2026/8/27	high
321448	Python 函式庫 OpenEXR 3.4.x < 3.4.12 多個漏洞	Nessus	Misc.	2026/6/17	2026/7/3	high
321448	Python 库 OpenEXR 3.4.x < 3.4.12 多种漏洞	Nessus	Misc.	2026/6/17	2026/7/3	high
321448	Python ライブラリ OpenEXR 3.4.x < 3.4.12 の複数の脆弱性	Nessus	Misc.	2026/6/17	2026/7/3	high
321771	Linux Distros のパッチ未適用の脆弱性: CVE-2026-45696	Nessus	Misc.	2026/6/20	2026/8/27	high
317389	FreeBSD:OpenEXR -- 3.4.12 は複数の脆弱性を修正します(ca91c020-5820-11f1-b38d-9be2e6022e28)	Nessus	FreeBSD Local Security Checks	2026/5/28	2026/6/26	high
317389	FreeBSD : OpenEXR -- 3.4.12 fixes multiple vulnerabilities (ca91c020-5820-11f1-b38d-9be2e6022e28)	Nessus	FreeBSD Local Security Checks	2026/5/28	2026/6/26	high
321771	Linux Distros Unpatched Vulnerability : CVE-2026-45696	Nessus	Misc.	2026/6/20	2026/8/27	high
321448	Python Library OpenEXR 3.4.x < 3.4.12 Multiple Vulnerabilities	Nessus	Misc.	2026/6/17	2026/7/3	high

检测

插件搜索

high

high

high

high

high

high

high

high

high

high