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

  - OpenEXR 是 EXR 影像格式的參考實作和規範，廣泛應用於電影產業。之前的版本 3.2.11、 3.3.0 through 3.3.12和 3.4.0 through 3.4.13 允許具有非零 dataWindow.min 的特製 EXR 使 TypedFlatImageChannel：：row（） 傳回無效的堆積指標，導致越界或釋放後使用寫入。當應用程式透過 FlatHalfChannel：：row（） 寫入資料列時，就會發生這種情況。受影響的取用者是接受不受信任的 EXR 檔案並在載入的影像上使用 FlatHalfChannel：：row（） 的工具、轉換器、轉譯管線元件或影像處理服務。
    此問題已在 、 3.3.13和 3.4.14版本中3.2.11修正。（CVE-2026-59184）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

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

  - OpenEXR 是 EXR 图像格式的参考实现和规范，广泛应用于电影行业。低于 3.2.11、 3.3.0 和 3.4.03.3.12through 3.4.13 的版本允许带有非零 dataWindow.min 的特制 EXR 让 TypedFlatImageChannel：：row（） 返回无效的堆指针，进而造成越界或释放后使用写入。当应用程序通过 FlatHalfChannel：：row（） 写入行时，会发生这种情况。受影响的消费者是接受不受信任的 EXR 文件并在加载的图像上使用 FlatHalfChannel：：row（） 的工具、转换器、渲染管线组件或图像处理服务。
    在版本 3.2.11、 和 3.3.133.4.14中修复了此问题。（CVE-2026-59184）

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

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

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

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

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

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

  - OpenEXR は、映画業界で広く使用されている EXR 画像形式の参照実装および仕様です。3.2.11より前、3.3.0から3.3.12、3.4.0から3.4.13までのバージョンでは、0以外のdataWindow.minを持つ細工されたEXRがTypedFlatImageChannel::row()に無効なヒープポインターを返させ、領域外書き込みまたはメモリ解放後使用(Use After Free)書き込みを引き起こす可能性があります。これは、アプリケーションが FlatHalfChannel::row() を通じて行を書き込むときに発生します。影響を受けるコンシューマーは、信頼できないEXRファイルを受け入れ、読み込まれた画像でFlatHalfChannel::row()を使用するツール、コンバーター、レンダリングパイプラインコンポーネント、または画像処理サービスです。
    この問題は、バージョン 3.2.11、 3.3.13、 3.4.14 で修正されています。(CVE-2026-59184)

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 56449320-97c5-11f1-84d7-3c7c3fba4204 advisory.

    Cary Phillips reports:
    [The OpenEXR 3.4.14] 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. Versions before 3.2.11, 3.3.0 through 3.3.12, and 3.4.0 through 3.4.13 allow a     crafted EXR with a nonzero dataWindow.min to make TypedFlatImageChannel::row() return an invalid heap     pointer, causing out-of-bounds or use-after-free writes. This occurs when an application writes rows     through FlatHalfChannel::row(). Affected consumers are tools, converters, render pipeline components, or     image-processing services that accept untrusted EXR files and use FlatHalfChannel::row() on loaded images.
    This issue is fixed in versions 3.2.11, 3.3.13, and 3.4.14. (CVE-2026-59184)

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

It is, therefore, affected by multiple vulnerabilities as referenced in the ALAS2023-2026-2154 advisory.

    OpenEXR is the reference implementation and specification for the EXR image format, widely used in the     motion picture industry. Versions prior to 3.2.10, 3.3.12 and 3.4.13 contain a heap out-of-bounds write in     Imf_4_0::SampleCountChannel::set(int r, unsigned int newNumSamples[]). The row-based sample-count setter     computes the target Y coordinate with dataWindow.min.x instead of dataWindow.min.y. For a valid deep image     data window where min.x != min.y, a valid row index can be translated into an invalid Y coordinate,     causing writes before the allocated _numSamples buffer. The vulnerability is reachable through the public     OpenEXRUtil DeepImage API and can lead to heap corruption and process crashes. This issue has been fixed     in versions 3.2.10, 3.3.12 and 3.4.13. (CVE-2026-55059)

    OpenEXR is the reference implementation and specification for the EXR image format, widely used in the     motion picture industry. Versions prior to 3.2.10, 3.3.12, and 3.4.13 contain an infinite-loop     vulnerability in SampleCountChannel. The helper roundListSizeUp() rounds a sample-list size up to the next     power of two using repeated unsigned left shifts, which terminates for normal values but fails for     UINT_MAX: the sequence reaches 0x80000000, and the next left shift wraps the 32-bit value to 0. Because 0     remains less than UINT_MAX, the loop never progresses and never exits. The bug is reachable through public     OpenEXRUtil APIs, either by editing the sample-count buffer through SampleCountChannel::Edit (whose     destructor calls endEdit()) or by calling SampleCountChannel::set(x, y, UINT_MAX) on a valid pixel. This     issue has been fixed in versions 3.2.10, 3.3.12, and 3.4.13. (CVE-2026-55373)

    OpenEXR is the reference implementation and specification for the EXR image format, widely used in the     motion picture industry. In versions 3.1.0 through 3.2.10, 3.3.0 through 3.3.12, and 3.4.0 through 3.4.13,     an int32_t multiplication in OpenEXRCore's unpack_sample_table() can overflow while decoding a crafted     deep tiled EXR file, producing an invalid pointer that leads to a read from an unmapped memory address and     a crash. Because the overflow occurs in the standard decoding path (exr_decoding_run), any application     that decodes deep tiled EXR files is affected. This issue is fixed in versions 3.2.11, 3.3.13, and 3.4.14.
    (CVE-2026-59183)

    OpenEXR is the reference implementation and specification for the EXR image format, widely used in the     motion picture industry. Versions before 3.2.11, 3.3.0 through 3.3.12, and 3.4.0 through 3.4.13 allow a     crafted EXR with a nonzero dataWindow.min to make TypedFlatImageChannel::row() return an invalid heap     pointer, causing out-of-bounds or use-after-free writes. This occurs when an application writes rows     through FlatHalfChannel::row(). Affected consumers are tools, converters, render pipeline components, or     image-processing services that accept untrusted EXR files and use FlatHalfChannel::row() on loaded images.
    This issue is fixed in versions 3.2.11, 3.3.13, and 3.4.14. (CVE-2026-59184)

    OpenEXR is the reference implementation and specification for the EXR image format, widely used in the     motion picture industry. In OpenEXRUtil versions 3.3.0 through 3.3.12 and 3.4.0 through 3.4.12, the     documented TypedDeepImageChannel<T>::row() API can return an out-of-bounds pointer when a deep image has a     non-zero dataWindow origin, resulting in a heap out-of-bounds read and crash, with potential information     disclosure under a controlled heap layout. The flaw arises because ImfDeepImageChannel uses two     conflicting coordinate models: at(x, y) uses absolute coordinates (with _base offset by dataWindow.min),     while row(r) is documented as 0-based logical access. For a non-zero dataWindow.min, row(0) therefore     points outside the _sampleListPointers allocation instead of at the first logical row. This issue is fixed     in versions 3.3.13 and 3.4.13. (CVE-2026-59189)

    OpenEXR is the reference implementation and specification for the EXR image file format, widely used in     the motion picture industry. In versions through 3.2.10, 3.3.0 through 3.3.12, and 3.4.0 through 3.4.13,     the OpenEXRUtil library returns an out-of-bounds pointer from the SampleCountChannel::row() API when a     deep image has a non-zero dataWindow origin. The row() accessor is documented as 0-based and computes its     address from an internal base that is offset for absolute pixel coordinates, so the two coordinate models     conflict whenever dataWindow.min is non-zero. For a deep image whose data window has a large negative     vertical origin, row(0) points far outside the allocated sample-count buffer. An application that opens an     attacker-controlled deep EXR file and accesses sample counts through row() performs an out-of-bounds read,     which can crash the process or, under a controlled heap layout, return adjacent heap memory as sample-     count values. This issue is fixed in versions 3.2.11, 3.3.13, and 3.4.14. (CVE-2026-59981)

    OpenEXR is the reference implementation and specification for the EXR image format, widely used in the     motion picture industry. OpenEXR versions before 3.2.11, 3.3.0 through 3.3.12, and 3.4.0 through 3.4.13     can return an out-of-bounds pointer from TypedDeepImageChannel::row() when a crafted deep EXR has a     nonzero dataWindow origin. This vulnerability occurs because the API combines zero-based row access with     an absolute-coordinate-adjusted base pointer, allowing a crash or limited information disclosure. This     issue is fixed in versions 3.2.11, 3.3.13, and 3.4.14. (CVE-2026-59982)

    OpenEXR is the reference implementation and specification for the EXR image format, widely used in the     motion picture industry. OpenEXR versions before 3.2.11, 3.3.0 through 3.3.12, and 3.4.0 through 3.4.13     are vulnerable to crashing. This occurs when Imf::GetChannelsInMultiPartFile() processes a crafted EXR     with an empty multiView header attribute and Imf::viewFromChannelName() indexes the empty vector for a     dotless channel name. This issue is fixed in versions 3.2.11, 3.3.13, and 3.4.14. (CVE-2026-61555)

    OpenEXR is the reference implementation and specification for the EXR image format, widely used in the     motion picture industry. In versions before 3.2.11, 3.3.0 through 3.3.12, and 3.4.0 through 3.4.13,     exrmultiview can write past a heap allocation when it combines two attacker-supplied, individually valid     scanline EXR files whose union dataWindow is not aligned to one view's channel subsampling. The utility     allocates sampled channel storage using a truncated union_width / xSampling, then reads the sampled input     through a Slice based on the misaligned union window, producing a heap out-of-bounds write. The trigger is     normal public-tool processing, such as exrmultiview left A.exr right B.exr out.exr with crafted but valid     inputs, so this is not solely an API or caller-precondition issue. This issue is fixed in versions 3.2.11,     3.3.13, and 3.4.14. (CVE-2026-68515)

Tenable has extracted the preceding description block directly from the tested product 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	Published	Updated	Severity
341341	Linux Distros 未修補弱點：CVE-2026-59184	Nessus	Misc.	8/28/2026	9/7/2026	high
341341	Linux Distros 未修补的漏洞：CVE-2026-59184	Nessus	Misc.	8/28/2026	9/7/2026	high
335504	FreeBSD:OpenEXR -- 3.4.14 は複数の脆弱性を修正します(56449320-97c5-11f1-84d7-3c7c3fba4204)	Nessus	FreeBSD Local Security Checks	8/15/2026	8/26/2026	high
341341	Linux Distros のパッチ未適用の脆弱性: CVE-2026-59184	Nessus	Misc.	8/28/2026	9/7/2026	high
335504	FreeBSD : OpenEXR -- 3.4.14 fixes multiple vulnerabilities (56449320-97c5-11f1-84d7-3c7c3fba4204)	Nessus	FreeBSD Local Security Checks	8/15/2026	8/26/2026	high
341341	Linux Distros Unpatched Vulnerability : CVE-2026-59184	Nessus	Misc.	8/28/2026	9/7/2026	high
345802	Amazon Linux 2023 : openexr, openexr-devel, openexr-libs (ALAS2023-2026-2154)	Nessus	Amazon Linux Local Security Checks	9/14/2026	9/14/2026	high

Detections

Analytics

Plugins Search

high

high

high

high

high

high

high