リモートホストにインストールされている OpenSSL は、3.6.2 より前のバージョンです。したがって、3.6.2 のアドバイザリに記載されている複数の脆弱性の影響を受けます。

  - 問題の要約: OpenSSL TLS 1.3 サーバーが、鍵交換グループ設定に「DEFAULT」キーワードを使用するデフォルトが含まれる場合、期待される優先鍵交換グループのネゴシエートに失敗する可能性があります。影響のサマリーより優先されるグループがクライアントとサーバーの両方でサポートされているときでも、グループがクライアントの初期の事前鍵共有に含まれていない場合は、より優先されない鍵交換が使用される可能性があります。クライアントがサーバーから特にリクエストされるまで使用を延期することを選択した場合、これは新しいハイブリッド耐量子グループで生じる可能性があります。OpenSSL TLS 1.3 サーバーの設定が「DEFAULT」キーワードを使用して組み込みデフォルトグループリストを独自の設定に内在する場合、特定の要素を追加または削除すると、実装の欠陥により「DEFAULT」リストが「tuple」構造を失い、サーバーでサポートされるすべてのグループは単一の十分に安全な「tuple」として扱われ、もっと優先される tuple のグループが相互にサポートされている場合でも、サーバーは Hello Retry Request (HRR) を送信しませんでした。結果として、クライアントの設定が「従来の」グループのみとなる場合 (「X25519」が唯一のクライアントの初期鍵共有予測の場合など)、「X25519MLKEM768」などの相互にサポートされる耐量子鍵の合意グループのネゴシエートに失敗する可能性があります。
    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

  - Debian Linux - openssl - なし Red Hat Enterprise Linux - openssl openssl無効な RSA 公開鍵を介した初期化されていないメモリからの情報漏洩CVE-2026-31790

  - Debian Linux - openssl - なしCVE-2026-28389、 CVE-2026-28390、 CVE-2026-31789

  - 問題のサマリーDelta CRL Indicator 拡張を含む delta CRL が処理される際に、必要な CRL Number 拡張がない場合、NULL ポインターデリファレンスが発生する可能性があります。影響のサマリー: NULL ポインターデリファレンスにより、クラッシュがトリガーされ、アプリケーションのサービス拒否につながる可能性があります。X.509 証明書の検証中に CRL 処理および delta CRL 処理が有効な場合、delta CRL 処理は、CRL 番号拡張が NULL であるかどうかを逆参照する前に CRL 番号拡張が NULL であるかどうかをチェックしません。無効な形式のデルタ CRL ファイルが処理されている場合、このパラメーターは NULL になり、NULL ポインターデリファレンスが発生する可能性があります。この問題を悪用するには、検証コンテキストでX509_V_FLAG_USE_DELTASフラグが有効であること、証明書にfreshestCRL拡張機能またはベースCRLが含まれるように検証され、EXFLAG_FRESHESTフラグが設定されること、攻撃者が不正な形式のCRLを処理するアプリケーションに提供することが必要です。脆弱性はサービス拒否に限定されており、コード実行やメモリ漏洩につながることはありません。そのため、弊社のセキュリティポリシーに従って、この問題は重要度低と評価されました。 3.6、 3.5、 3.4、 3.3 、 3.0 の FIPS モジュールは、この問題による影響を受けません。これは、影響を受けるコードが OpenSSL FIPS モジュール境界の外にあるためです。OpenSSL 3.6.2 (3.6.0 以降が影響を受けます) で修正されました。
    (CVE-2026-28388)

  - 問題のサマリー: DANE TLSA ベースのサーバー認証を実行するクライアントの一般的でない構成により、一般的なサーバーの DANE TLSA レコードとペアリングされたとき、クライアント側で use-after-free や二重解放が引き起こされる可能性があります。影響の概要: use-after-free は、有効なデータの破損、クラッシュ、任意のコードの実行など、さまざまな影響を与える可能性があります。ただし、この問題の影響を受けるのは、PKIX-TA(0/PKIX-EE(1) 証明書使用率と DANE-TA(2) 証明書使用率の両方で TLSA レコードを使用するクライアントのみです。現時点で、最も一般的な DANE の展開は SMTP MTA です。これに対して RFC7672 は、クライアントが PKIX 証明書を使用している TLSA レコードを「使用不可」として扱うことを推奨しています。これらの SMTPまたは他の類似クライアントはこの問題に対して脆弱ではありません。逆に、 PKIX の使用だけをサポートし、DANE-TA(2) の使用を無視するクライアントも脆弱ではありません。クライアントはまた、両方のタイプの TLSA レコードで TLSA RRset を公開するサーバーと通信している必要があります。FIPS モジュールはこの問題の影響を受けません。問題コードは FIPS モジュール境界の外部にあります。OpenSSL 3.6.2 (3.6.0 以降が影響を受けます) で修正されました。(CVE-2026-28387)

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

検出

OpenSSL 3.6.0< 3.6.2複数の脆弱性

critical Nessus プラグイン ID 302501

バージョン 1.5