CVE-2026-84782 OpenSSL｜DTLS の影響確認と更新判断

はじめに

2026 年 9 月 29 日、OpenSSL プロジェクトはセキュリティアドバイザリーを公開し、14 件の脆弱性を修正しました。このうち OpenSSL が唯一 High と評価したのが、DTLS のハンドシェイク再送処理に関する CVE-2026-84782 です。

OpenSSL は OS、ミドルウェア、ネットワーク機器、業務アプリケーションに広く組み込まれています。そのため「自社のどのアプリケーションを確認すればよいか」「OS の更新とベンダーの修正のどちらを適用するのか」「何をもって対応完了とするか」を整理する必要があります。一方で、本脆弱性は DTLS を使う処理に限られた問題であり、一般的な HTTPS 通信と同じ扱いにはできません。

本記事では、DTLS の利用有無、OpenSSL の組み込み方、配布元の修正判定、更新後の反映と確認という順で、対応の判断材料を整理します。実機での検証は行っておらず、コマンドは公式資料に基づく確認例として掲載しています。

結論として、本脆弱性の影響を受けるのは、OpenSSL の DTLS 実装を使うアプリケーションです。OS パッケージ、製品同梱、コンテナーなど OpenSSL の提供元ごとに配布元の修正を適用し、対象のプロセスが修正済みのライブラリで稼働していることを確認した時点で、対応完了と判断します。なお、同時に修正された脆弱性には DTLS と無関係のものも含まれるため、DTLS を使っていないことは今回の更新全体を見送る理由にはなりません。

CVE-2026-84782 と DTLS の影響

CVE-2026-84782 は、DTLS のハンドシェイクメッセージを再送する処理の不備です。最初に OpenSSL の説明に沿って起き得ることを整理し、続いて評価主体ごとの深刻度と、誤解しやすい点を確認します。

書き込みが中断した状態で再送が起きると発生する

DTLS は、UDP など到達を保証しないトランスポート上で、TLS に相当する保護を提供するプロトコルです。ハンドシェイクメッセージが失われた場合に備えて、タイマーによる再送の仕組みを持っています。

OpenSSL のアドバイザリーによると、ハンドシェイクメッセージは複数の断片に分けて書き出され、下位のトランスポートが一時的にデータを受け付けられない場合、書き込みはメッセージの途中で中断（WANT_WRITE）します。この中断中に再送タイマーが発火すると、再送処理は中断中の書き込みと同じ内部バッファーと位置情報を使い、位置を先頭に戻さないまま読み出していました。その結果、送るべきでない別のメッセージの残りを含んだ再送メッセージが作られ、割り当てたバッファーの末尾を越えて読み出す場合があります。

参考: OpenSSL Security Advisory（2026 年 9 月 29 日）
“can disclose a heap memory to the peer as plaintext handshake data”
（ヒープメモリの内容を、平文のハンドシェイクデータとして通信相手へ露出させ得る）
https://openssl-library.org/news/secadv/20260929.txt

読み出しがマップされていないメモリ領域に達した場合は、クラッシュによる DoS になるとされています。また、再送が中断中の書き込みの管理情報を上書きする問題もあり、デバッグビルドではプロセスが中断（abort）すると説明されています。修正では、再送前に読み出し位置をメッセージの先頭へ戻し、書き込みが中断している間は再送を行わないように変更されました。

公式に説明されている影響は、ヒープメモリの一部の露出と、クラッシュによる DoS です。任意コード実行や、秘密鍵などの特定の情報が必ず漏えいするとは説明されていません。露出する内容はその時点でヒープ上に残っていたデータであり、何が含まれるかは状況に依存すると考えられます（編集部の補足）。

評価主体ごとの深刻度と悪用状況

深刻度の表現は評価主体によって異なります。OpenSSL は CVSS を付与せず、独自の基準で High と評価しています。

CISA-ADP と Red Hat では、攻撃の複雑さ（AC）と機密性への影響（C）の評価が分かれています。CVSS の値を優先度付けに使う場合は、どの主体の値かを明記して扱うことをおすすめします。

悪用状況について、OpenSSL のアドバイザリーには実際の悪用に関する記載がなく、CISA-ADP の SSVC では評価時点の Exploitation が none とされています。これは評価時点で悪用が確認されていないことを示すもので、今後も悪用されないことを意味するものではありません。KEV への掲載状況は、CISA の KEV カタログで最新の状況を確認し、掲載された場合は優先度を見直すことをおすすめします。

TLS と DTLS を区別して影響を判断する

影響の判断で誤りやすい点を、区分ごとに整理します。

TCP 上の一般的な TLS 通信

本脆弱性は DTLS の再送処理の問題です。TCP 上の TLS で動作する HTTPS サーバーなどが、OpenSSL を使っていることだけで本脆弱性の対象になるわけではありません。

UDP・WebRTC・VPN の利用

UDP の通信、WebRTC、VPN を利用していることだけでは、該当の根拠になりません。その機能が OpenSSL の DTLS 実装を使っているかを、製品ドキュメントやベンダーの回答で確認します。

クライアント側の利用

アドバイザリーでは、中断した書き込みを再開する呼び出しとして SSL_accept() と SSL_connect() の両方が挙げられています。サーバーだけでなく、DTLS で接続するクライアント側のアプリケーションや機器も確認対象に含めることをおすすめします（編集部の解釈）。

FIPS モジュールの利用

OpenSSL は、影響を受けるコードが FIPS モジュール境界の外側にあるとしています。FIPS モジュールに影響がないことは、FIPS プロバイダーを使うアプリケーション全体が安全であることを意味しません。DTLS を使っていれば、同様に確認と更新の対象です。

Red Hat も、RHEL の大半のワークロードを占める TCP 上の標準的な TLS 接続は影響を受けないとしたうえで、影響範囲を次のように説明しています。

参考: Red Hat（CVE-2026-84782）
“the flaw strictly affects software using Datagram Transport Layer Security (DTLS) over UDP”
（この欠陥は、UDP 上で DTLS を使うソフトウェアに限って影響する）
https://access.redhat.com/security/cve/cve-2026-84782

Red Hat は、ノンブロッキング I/O の構成であることも条件に挙げています。これは Red Hat による評価で、OpenSSL のアドバイザリーは「トランスポートが一時的にデータを受け付けられない場合」と説明しています。アプリケーションの I/O 方式を確認できない場合は、条件を満たし得る前提で扱うことをおすすめします。

OpenSSL の修正版と提供条件

上流の修正版は 7 系列に用意されていますが、3.0 以前の系列は有償サポートの契約者だけに提供されます。ここでは、提供条件と系列のサポート期限との関係を整理します。

出典: OpenSSL Security Advisory、OpenSSL Release Strategy（2026 年 10 月 2 日に確認）

アドバイザリーは、サポート中の系列だけを分析の対象とし、サポートが終了した 3.1、3.2、3.3 は分析していないと明記しています。表にない系列を「非該当」と扱わず、サポート対象の系列への移行や配布元の修正で対応することをおすすめします。

OpenSSL 3.0 のサポート終了後の対応

OpenSSL 3.0 は、2026 年 9 月 7 日に上流の公開サポートを終了しました。OpenSSL の告知では、次のように説明されています。

参考: OpenSSL 3.0 End of Life
“it will no longer receive publicly available security fixes”
（今後、一般公開のセキュリティ修正は提供されない）
https://openssl-library.org/post/2026-09-16-eol30/

ただし、これは上流からの提供条件です。OS や製品のベンダーは、自社のサポート期間に基づいて修正を取り込み、提供する場合があります。後述する Ubuntu 22.04 LTS / 24.04 LTS は 3.0 系を基にしたパッケージで、今回の修正を取り込んだ版が公開されています。3.0 系を使う環境では、次のいずれかで対応します。

• OS・製品のベンダーが提供する修正済みのパッケージやリリースを適用する
• 自前ビルドで 3.0 系を使っている場合は、OpenSSL の有償サポート契約で 3.0.23 を入手する
• サポート中の系列へ移行する

OS が管理するライブラリを、上流のソースから手動でビルドした版で置き換える方法は、一律にはおすすめしません。パッケージ管理と競合し、以降の配布元の修正が適用されない状態を招くおそれがあるためです（編集部の見解）。

今回のパッチ適用と系列の移行を分けて考える

3.4 と 3.6 は、それぞれ 2026 年 10 月 22 日と 11 月 1 日に上流のサポート期限を迎えます。今回は同じ系列内の修正版（3.4.8、3.6.5）を適用し、系列の移行は別の計画として扱うことをおすすめします。

移行先を検討する際は、互換性の範囲に注意が必要です。OpenSSL の Release Strategy では、3.0 以降の API / ABI の互換性は同じメジャー番号の範囲で保証するとされています。3.x から 4.0 への更新はメジャー番号が変わるため、アプリケーションの再ビルドや動作確認を伴う可能性があります。移行先は、2030 年 4 月 8 日までサポートされる 3.5 LTS などを候補に、利用製品の対応状況、互換性、配布元の方針を確認したうえで判断します。

自環境への影響を確認する手順

確認は「DTLS を使っているか」「その OpenSSL はどこから提供されているか」「提供元は修正を出しているか」の順で進めます。判断できない項目は非該当とせず、追加調査の対象として残します。

対象と DTLS の利用を洗い出す

サーバー、クライアント、ネットワーク機器、コンテナーを対象に、DTLS を使う機能があるかを調べます。根拠として使える情報は次のとおりです。

• アプリケーションや機器の設定（DTLS の有効化、UDP の待ち受けや接続先）
• 製品ドキュメントやリリースノートにある、暗号ライブラリと DTLS の記載
• SBOM に記載された OpenSSL のコンポーネントとバージョン
• ベンダーのセキュリティアドバイザリーや、問い合わせへの回答

DTLS や OpenSSL の利用を確認できない対象は「不明」として追加調査に回し、非該当として処理しないことをおすすめします。OpenSSL 以外のライブラリで DTLS を実装した製品は本 CVE の対象外ですが、その判断もベンダーの情報に基づいて行います。

OpenSSL の組み込み方を区別する

同じサーバー上でも、OpenSSL の提供元はアプリケーションごとに異なる場合があります。提供元によって、修正の入手先と反映方法が変わります。

Ubuntu の CVE ページでは、同じ OS 上でも OpenSSL を内包するパッケージが別に扱われています。たとえば 22.04 LTS の nodejs は OpenSSL 1.1.1m を内包するとされ、2026 年 10 月 2 日の確認時点で Vulnerable（影響あり）と表示されています。edk2 も各リリースで Needs evaluation（評価が必要）の状態です。ホスト OS の libssl を更新しただけで、同梱版やコンテナー内の OpenSSL まで修正済みとは扱わないことをおすすめします。

製品本体と同梱ライブラリを分けて確認する考え方は、Apache Tomcat の脆弱性｜構成別の影響確認と更新判断でも Tomcat Native を例に整理しています。ただし、Tomcat が扱うのは TCP 上の TLS であり、本 CVE の DTLS とは対象が異なります。

Linux では、稼働中のプロセスが読み込んでいる libssl のパスを、プロセスのメモリマップ（/proc/pid/maps）で確認できます。<PID> は、確認したいプロセスの実際のプロセス ID に置き換えて実行します。OS のライブラリディレクトリーか、製品のディレクトリー配下かによって、提供元を切り分ける材料になります。

grep libssl /proc/<PID>/maps

表示されるのはマッピング元のファイルのパスで、現在ディスク上にある同じパスのファイルと同一とは限りません。マニュアルでは、マッピング元のファイルが削除されている場合はパス名の末尾に (deleted) が付くとされており、パッケージの更新でファイルが置き換えられた後も旧ファイルを読み込み続けているプロセスでは、この表示になる場合があります。ただし、マニュアル自体がこの表示はあいまいになり得ると注記しています。(deleted) がないことだけで修正済みとは判断せず、提供元の修正状況、更新後のプロセスの再起動、再起動後の読み込み先を組み合わせて確認することをおすすめします。また、静的リンクの場合は libssl が表示されないため、何も表示されないことを OpenSSL 不使用の根拠にはしません。

openssl version -a は入口として使う

openssl version -a は、コマンドラインの openssl が使う OpenSSL のバージョン、ビルド日、OPENSSLDIR などを表示します。公式リファレンスでは、-a はほかのすべてのオプションを指定した場合と同じ情報を表示するとされています。

openssl version -a

ただし、この出力が示すのは、そのコマンドが使う OpenSSL です。同梱版、静的リンク、コンテナー内のライブラリを使うアプリケーションとは一致しない場合があります。また、配布元のパッケージでは上流の番号を基にした表示となるため、修正の取り込み（バックポート）の有無をこの出力だけでは判断できないことがあります。DTLS の実使用や、全アプリケーションの安全性をこの出力で判断しないことをおすすめします。

Ubuntu で配布元の修正版を照合する例

Ubuntu は USN-8847-1 で、本 CVE を含む修正を 26.04 LTS、24.04 LTS、22.04 LTS 向けに公開しています。対象パッケージと修正版は次のとおりです（2026 年 10 月 2 日に確認）。

24.04 LTS の 3.0.13-0ubuntu3.16 は、上流の修正版 3.0.23 より番号が小さく見えますが、配布元が修正を取り込んだパッケージです。修正の有無は上流の番号ではなく、配布元が公開した、リビジョンまで含むパッケージバージョンで判断します。バージョンの比較は文字列の大小ではなく、パッケージ管理の比較規則に従う必要があります。なお、20.04 LTS 以前のリリースについては、Ubuntu の CVE ページで Ubuntu Pro 経由の修正版が案内されています。上流のバージョンと配布元の判定を分けて扱う考え方は、Linux カーネル脆弱性 3 件｜KEV 掲載後の影響判定と完了確認でも整理しています。

ホスト上では、インストール済みのパッケージバージョンを確認します。24.04 LTS / 26.04 LTS では libssl3t64、22.04 LTS では libssl3 を指定します。

apt policy libssl3t64

Installed の行が USN の修正版以上であるかを確認します。policy は、Ubuntu の apt マニュアルで apt-cache の機能として案内されているサブコマンドです。Ubuntu Pro Client を利用できる環境では、システムを変更しない --dry-run を付けて、CVE 単位で影響を受けるパッケージと修正版の有無を確認できます（Ubuntu Pro Client のドキュメント）。

pro fix --dry-run CVE-2026-84782

これらはホストの OS パッケージを対象とした判定です。USN の修正版を、製品同梱版やコンテナー内のライブラリの判定に流用しないことをおすすめします。

確認結果を棚卸し表に残す

確認結果は、対象ごとに次の項目で記録することをおすすめします。表は記入する観点の例で、確認済みのデータではありません。

更新の反映と対応完了の確認

パッケージやライブラリを更新するだけでは、すべての対象プロセスへの反映を保証できません。提供元に応じた修正の適用、プロセスへの反映、完了の確認までを一連の作業として扱います。

sudo apt update && sudo apt upgrade

sudo needrestart -r l

パッケージを入れただけ、または再起動しただけの状態は、対応完了として扱わないことをおすすめします。途中の状態は、次のように区別して記録します。

同時修正された脆弱性の確認点

今回のアドバイザリーでは、CVE-2026-84782 を含む 14 件が修正されました。OpenSSL の評価は High が 1 件、Moderate が 1 件、Low が 12 件です。Low の多くは QUIC、SM2、証明書の処理などに関するもので、DTLS とは別の条件で成立します。たとえば CVE-2026-35189 は証明書の CRL 配布点の処理に関する問題で、クライアントや、クライアント証明書を求めるサーバーで DoS につながり得るとされ、アドバイザリーが分析した 7 系列（4.0、3.6、3.5、3.4、3.0、1.1.1、1.0.2）が対象です。

DTLS を使っていないことは本 CVE を非該当とする材料になりますが、今回の更新全体を見送る理由にはなりません。主題と混同しやすい 2 件を、本 CVE と比較します。

CVE-2026-75806 も DTLS の問題ですが、対象はハンドシェイク後の確立済みの通信で、情報の露出は伴いません。CVE-2026-84783 は 4.0 のみが対象のため、4.0 を使う自前ビルドや製品同梱版で確認が必要になります。Ubuntu の場合、CVE-2026-75806 を含む修正は同じ USN-8847-1 で提供されています。

まとめ

CVE-2026-84782 は DTLS のハンドシェイク再送処理に限られた問題ですが、OpenSSL の組み込み方が多様なため、確認の範囲は OS パッケージにとどまりません。DTLS の利用、OpenSSL の提供元、配布元の修正、稼働プロセスへの反映を順に確認することが対応の要点です。

• OpenSSL が High と評価した DTLS ハンドシェイク再送処理の脆弱性
• 公式の影響はヒープメモリの一部露出とクラッシュによる DoS
• 上流の 3.0 以前の修正版は有償サポートの契約者だけに提供
• 修正の判定は上流の番号ではなく配布元のパッケージで行う。
• ホスト OS の更新だけでは同梱版やコンテナーは修正されない。
• 稼働プロセスが修正済みのライブラリを使うまで確認する。
• DTLS を使わない環境も同時修正分を踏まえて更新を検討する。

以上、最後までお読みいただきありがとうございました。