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

  - 問題のサマリー: OpenSSL TLS 1.3 サーバーが、鍵交換グループ構成に「DEFAULT」キーワードを使用するデフォルトが含まれる場合、期待される優先鍵交換グループのネゴシエートに失敗する可能性があります。影響のサマリーより優先されるグループがクライアントとサーバーの両方でサポートされているときでも、グループがクライアントの初期の事前鍵共有に含まれていない場合は、より優先されない鍵交換が使用される可能性があります。クライアントがサーバーから特にリクエストされるまで使用を延期することを選択した場合、これは新しいハイブリッド post-quantum グループに当てはまります。OpenSSL TLS 1.3 サーバーの構成が「DEFAULT」キーワードを使用して、組み込みデフォルトグループリストを独自の構成に内在する場合、特定の要素を追加または削除する可能性があります。実装の欠陥により、「DEFAULT」リストが「tuple」を失っています。 ' 構造体、およびサーバーでサポートされるすべてのグループは、単一の十分に安全な「tuple」として扱われ、より優先される tuple のグループが相互にサポートされている場合でも、サーバーは Hello Retry RequestHRRを送信しませんでした。結果として、クライアントの構成が「従来の」グループのみとなる場合「X25519MLKEM768」などの、相互にサポートされる post-quantum 鍵の合意グループのネゴシエートに失敗する可能性があります例「X25519」のみです。クライアントの初期キー共有予測で。
    OpenSSL 3.5 以降は、TLS サーバーで最も優先される TLS 1.3 キー合意グループを選択するための新しい構文をサポートします。古い構文には、単一の「フラット」なグループのリストがあり、サポートされるすべてのグループを十分に安全であると処理していました。クライアントによって予測されるキー共有のいずれかがサーバーによってサポートされている場合、これらのキー共有のリストに含まれていない他のグループが含まれている場合、より優先されるグループが選択されます。新しい構文は、グループをほぼ同じセキュリティの異なる「tuples」に分割します。各 tuple 内では、クライアントの予測される鍵共有に含まれる最も優先されるグループが選択されますが、クライアントが、より優先される tuple からのグループをサポートするものの、対応する鍵共有を予測しなかった場合は、サーバーはクライアントに 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 プラグイン ID 302195

バージョン 1.11