因此，它會受到 ALAS2023-2026-2154 公告中所提及的多個弱點影響。

    OpenEXR 是 EXR 影像格式的參考實作和規範，廣泛應用於電影產業。之前的版本，3.2.103.3.12並在 3.4.13 Imf_4_0：：SampleCountChannel：：set（int r， unsigned int newNumSamples[]） 中包含堆積越界寫入。資料列型樣本計數設定器會使用 dataWindow.min.x 而不是 dataWindow.min.y 來計算目標 Y 座標。對於 min.x ！= min.y 的有效深層影像資料視窗，有效的資料列索引可能會轉譯成無效的 Y 座標，導致在配置的 _numSamples 緩衝區之前寫入。此弱點可透過公用 OpenEXRUtil DeepImage API 存取，並可能導致堆積損毀和處理程序損毀。此問題已在 3.2.10、3.3.12 和 3.4.13 版中修正。(CVE-2026-55059)

    OpenEXR 是 EXR 影像格式的參考實作和規範，廣泛應用於電影產業。、 和 3.3.12之前3.4.13的版本在 3.2.10SampleCountChannel 中包含無限迴圈弱點。協助程式 roundListSizeUp（） 使用重複的無符號左移位，將樣本清單大小四捨五入為 2 的下一個冪，對於正常值會終止，但對於UINT_MAX會失敗：序列會達到 0x80000000，而下一個左移會將 32 位元值包裝為 0。因為 0 仍小於 UINT_MAX，所以迴圈永遠不會進行，也永遠不會結束。此錯誤可透過公用 OpenEXRUtil API 達成，方法是透過 SampleCountChannel：：Edit （其析構函式呼叫 endEdit（）） 編輯範例計數緩衝區，或在有效圖元上呼叫 SampleCountChannel：：set（x， y， UINT_MAX）。此問題已在 、 3.3.12和 3.4.13版本中3.2.10修正。（CVE-2026-55373）

    OpenEXR 是 EXR 影像格式的參考實作和規範，廣泛應用於電影產業。在 、 3.3.0 through 3.3.12和 3.4.03.4.13through 的3.2.10版本3.1.0中，OpenEXRCore 的 unpack_sample_table（） 中的int32_t乘法在解碼特製的深層平鋪 EXR 檔案時可能會溢位，從而產生無效指標，導致從未映射的記憶體位址讀取並崩潰。由於溢位發生在標準解碼路徑 （exr_decoding_run） 中，因此任何解碼深層並排 EXR 檔案的應用程式都會受到影響。此問題已在 、 3.3.13和 3.4.14版本中3.2.11修正。
    (CVE-2026-59183)

    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）

    OpenEXR 是 EXR 影像格式的參考實作和規範，廣泛應用於電影產業。在 OpenEXRUtil 版本3.3.03.4.123.3.123.4.0中，當深度影像具有非零 dataWindow 來源時，記錄的 TypedDeepImageChannel<T>：：row（） API 可能會傳回越界指標，導致堆積越界讀取和損毀，並在受控堆積配置下可能洩露資訊。出現此缺陷是因為 ImfDeepImageChannel 使用兩個衝突的座標模型：at（x， y） 使用絕對座標 （_base位移量由 dataWindow.min） ，而 row（r） 則記錄為從 0 開始的邏輯存取。因此，對於非零 dataWindow.min，row（0） 指向_sampleListPointers配置之外，而不是第一個邏輯列。此問題已在 3.3.13 和 3.4.13 版中修正。(CVE-2026-59189)

    OpenEXR 是 EXR 影像檔案格式的參考實作和規範，廣泛應用於電影產業。在 、 3.3.0 和 3.3.123.4.03.4.13透過 的3.2.10版本中，當深層影像具有非零 dataWindow 來源時，OpenEXRUtil 程式庫會從 SampleCountChannel：：row（） API 傳回越界指標。row（） 存取子會記錄為從 0 開始，並從絕對圖元座標位移的內部基數計算其位址，因此每當 dataWindow.min 為非零時，兩個座標模型就會衝突。對於資料視窗具有較大負垂直原點的深層影像，row（0） 指向遠遠超出配置的樣本計數緩衝區。開啟攻擊者控制的深層 EXR 檔案並透過 row（） 存取樣本計數的應用程式會執行越界讀取，這可能會使處理程序當機，或在受控的堆積配置下，將相鄰的堆積記憶體傳回為樣本計數值。此問題已在 、 3.3.13和 3.4.14版本中3.2.11修正。（CVE-2026-59981）

    OpenEXR 是 EXR 影像格式的參考實作和規範，廣泛應用於電影產業。當特製的深層 EXR 具有非零 dataWindow 來源時，OpenEXR 3.2.11之前的 、 3.3.0 through 3.3.12和 3.4.0 through 3.4.13 都可以從 TypedDeepImageChannel：：row（） 傳回越界指標。發生此弱點的原因是 API 結合了從零開始的資料列存取與絕對座標調整的基底指標，導致損毀或有限的資訊洩漏。此問題已在 、 3.3.13和 3.4.14版本中3.2.11修正。（CVE-2026-59982）

    OpenEXR 是 EXR 影像格式的參考實作和規範，廣泛應用於電影產業。之前的 OpenEXR 版本 3.2.11、 3.3.03.3.12through 和 through 3.4.13 都3.4.0容易當機。當 Imf：：GetChannelsInMultiPartFile（） 處理具有空白 multiView 標頭屬性的特製 EXR 並且 Imf：：viewFromChannelName（） 為無點通道名稱編製空向量索引時，就會發生這種情況。此問題已在 、 3.3.13和 3.4.14版本中3.2.11修正。（CVE-2026-61555）

    OpenEXR 是 EXR 影像格式的參考實作和規範，廣泛應用於電影產業。在之前的版本3.2.113.4.03.3.03.3.123.4.13中，當 exrmultiview 結合兩個攻擊者提供的個別有效的掃描行 EXR 檔案時，其 union dataWindow 未與一個檢視的通道子取樣對齊，則 exrmultiview 可以寫入堆積配置。公用程式會使用截斷的 union_width / xSampling 配置取樣通道儲存體，然後根據未對齊的聯集視窗透過 Slice 讀取取樣輸入，產生堆積越界寫入。觸發器是正常的公共工具處理，例如 exrmultiview 左 A.exr 右 B.exr out.exr 具有特製但有效的輸入，因此這不僅僅是 API 或調用方先決條件問題。此問題已在 、 3.3.13和 3.4.14版本中3.2.11修正。（CVE-2026-68515）

Tenable 已直接從所測試產品的安全公告擷取前置描述區塊。

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

偵測

Amazon Linux 2023：openexr、openexr-devel、openexr-libs (ALAS2023-2026-2154)

high Nessus Plugin ID 345802

版本 1.1