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 remote Alibaba Cloud Linux 3 host has packages installed that are affected by multiple vulnerabilities as referenced in the ALINUX3-SA-2026:0343 advisory.

    Package updates are available for Alibaba Cloud Linux 3 that fix the following vulnerabilities:

    CVE-2026-59184:
    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-59186:
    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, a     crafted tiled EXR can trigger a heap out-of-bounds write on 32-bit/ILP32 builds when read through the     public TiledRgbaInputFile RGBA API. The file uses a small 40x40 dataWindow but a 65537x65537 tile size. On     ILP32, the Array2D<Rgba> tile-conversion buffer size calculation overflows, allocates a much smaller heap     buffer, and tile decode writes past that allocation. This issue is fixed in versions 3.2.11, 3.3.13, and     3.4.14.

    CVE-2026-59189:
    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-59981:
    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-68515:
    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.

Tenable has extracted the preceding description block directly from the Alibaba Cloud Linux 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 remote SUSE Linux SLES12 / SLES_SAP12 host has packages installed that are affected by multiple vulnerabilities as referenced in the SUSE-SU-2026:4005-1 advisory.

    - CVE-2026-59186: On ILP32, the Array2D<Rgba> tile-conversion buffer size calculation overflows, allocates     a much       smaller heap buffer, and tile decode writes past that allocation (bsc#1276850).
    - CVE-2026-61555: crashing 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     (bsc#1276859).
    - CVE-2026-68515: 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       (bsc#1276848).

Tenable has extracted the preceding description block directly from the SUSE 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 remote MiracleLinux 8 host has packages installed that are affected by multiple vulnerabilities as referenced in the AXSA:2026-2069:07 advisory.

    * OpenEXR: OpenEXR: Out-of-bounds write vulnerability via crafted EXR files (CVE-2026-59184)
      * OpenEXR: OpenEXR: Heap out-of-bounds write via crafted tiled EXR file (CVE-2026-59186)
      * OpenEXR: OpenEXR: Information disclosure and denial of service due to out-of-bounds read     (CVE-2026-59189)
      * OpenEXR: OpenEXR: Heap out-of-bounds write in exrmultiview via crafted EXR files (CVE-2026-68515)
      * OpenEXR: OpenEXR: Information disclosure and denial of service via out-of-bounds read (CVE-2026-59981)

Tenable has extracted the preceding description block directly from the MiracleLinux 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	名称	产品	系列	发布时间	最近更新时间	严重程度
335504	FreeBSD : OpenEXR -- 3.4.14 fixes multiple vulnerabilities (56449320-97c5-11f1-84d7-3c7c3fba4204)	Nessus	FreeBSD Local Security Checks	2026/8/15	2026/8/26	high
378770	Alibaba Cloud Linux 3 : 0343: OpenEXR (ALINUX3-SA-2026:0343)	Nessus	Alibaba Cloud Linux Local Security Checks	2026/11/11	2026/11/11	high
348449	SUSE SLES12 Security Update : openexr (SUSE-SU-2026:4005-1)	Nessus	SuSE Local Security Checks	2026/9/21	2026/9/21	high
366371	MiracleLinux 8 : OpenEXR-2.2.0-12.el8_10.3 (AXSA:2026-2069:07)	Nessus	Miracle Linux Local Security Checks	2026/10/16	2026/10/16	high

检测

插件搜索

high

high

high

high