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

  - 問題摘要當 OpenSSL TLS 1.3 伺服器的金鑰交換群組組態包含使用「DEFAULT」關鍵字的預設值時其可能無法交涉預期的偏好金鑰交換群組。影響摘要如果用戶端的初始述詞金鑰共用中不包含較偏好的金鑰群組即使用戶端和伺服器支援偏好較弱的金鑰交換該群組也可能使用該群組。如果用戶端選擇將其使用延遲到伺服器特別要求時新的 Hybrid post-quantum 群組有時會發生此情況。如果 OpenSSL TLS 1.3 伺服器的組態使用「DEFAULT」關鍵字將內建預設群組清單插入其自身的組態(可能會新增或移除特定元素)則實作缺失會造成「DEFAULT」清單遺失其「tuple ' 結構且所有伺服器支援的群組都被視為一個足夠安全的「tuple」而伺服器不會傳送 Hello Retry Request (HRR)即使在更偏好的 tuple 中的群組是相互支援的時候伺服器也不會傳送 Hello Retry Request (HRR)。因此如果用戶端的組態只產生「傳統」群組 (例如只有「X25519」群組則用戶端和伺服器可能無法交涉相互支援的 post-quantum 金鑰協議群組例如「X25519MLKEM768」用戶端的初始 keyshare 預測中)。
    OpenSSL 3.5 和更新版本支援用於選取 TLS 伺服器上最偏好的 TLS 1.3 金鑰協議群組的新語法。舊語法具有單一「平面」群組清單並將所有支援的群組視為足夠安全。如果伺服器支援用戶端預測的任何 keyshare即使有其他群組受用戶端支援但未包含在預測的 keyshare 清單中仍會選取其中最偏好的群組 (若包含)其會優先選用。新語法會將群組分割為安全性大致相同的不同「元組」。在每個 tuple 內會選擇用戶端預測 keyshare 中包含的最偏好群組但是如果用戶端支援來自較偏好 tuple 的群組但並未預測任何對應的 keyshare則伺服器會要求用戶端重試 ClientHello (藉由發出Hello Retry Request (HRR) 具有最偏好的相互支援群組。當伺服器的組態使用內建的預設群組清單時上述項目可如預期運作或透過直接定義各種所需的群組和群組「tuples」來明確定義自己的清單。此問題不影響 OpenSSL FIPS 模組有問題的程式碼位於 FIPS 邊界之外。
    OpenSSL 3.6 至 3.5 受此問題影響。OpenSSL 3.6 使用者應在 OpenSSL 3.6.2 發行後升級至該版本。OpenSSL 3.5 使用者應在 OpenSSL 3.5.6 發行後升級至該版本。OpenSSL 3.4、 3.3、 3.0、 1.0.2 和 1.1.1 不受此問題影響。 (CVE-2026-2673)

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

偵測

Linux Distros 未修補的弱點：CVE-2026-2673

medium Nessus Plugin ID 302195

版本 1.11