OpenVPN 2.7.8 CVE クラスター：88964、84790、84256 の解説

OpenVPN の 2.7.8 メンテナンスリリース（公開議論の日付は 2026年10月7日）は、CVE 付きの修正3件に加え、意図的に CVE ID を付けていない tls-crypt-v2 の堅牢性変更をまとめている。このセキュリティノートは主要なアドバイザリをつなぎ合わせ、運用者がマーケティングブログだけを唯一の情報源とせず、Windows および Android クライアント、証明書ツール、マルチクライアント DCO サーバーを優先できるようにする。

Encrypt-then-MAC authenticated encryption construction diagram — 出典： Wikimedia Commons (RokerHRO) — 認証付き暗号化 EtM

一次情報源

OpenVPN コミュニティWiki — CVE-2026-88964 （報告者 Cole Munz；2.7.8 で修正；Windows および Android 上の 2.7_alpha3 から 2.7.7 までが影響を受ける）。
Linux Compatible による OpenVPN 2.7.8 の概要（Philipp Esselbach、2026年10月7日）。CVE-2026-84790、CVE-2026-88964、CVE-2026-84256、tls-crypt-v2 の変更、および関連する DCO 安定化作業を列挙している。
OpenVPN 自身の openvpn-2.7.8 の ReleaseHistory エントリ CVE wiki からリンクされている。

CVE-2026-88964 — ドメイン検索アンダーフロー

コミュニティWikiによると、Windows および Android 上の OpenVPN における整数アンダーフローにより、認証済みのリモートサーバーが、PUSH_REPLY 処理における細工されたドメイン検索オプションを通じて、サービス拒否またはメモリ開示を引き起こすことができる。これは典型的な「信頼済みピア、敵対的オプション」というバグ分類である。認証はすでに成功しているにもかかわらず、オプション解析は長さの算術を過度に信頼していた。影響はサービス拒否と潜在的なメモリ開示であり、公開 wiki の記述では無条件のリモートコード実行は主張されていない。修正は 2.7.8 で提供される。

防御側は、影響を受ける期間内でなお 2.7.7 以前を使用しているクライアントが、侵害された企業コンセントレータや管理の不十分なラボサーバーを含む、敵対的だが認証済みのエンドポイントに接続する場合、引き続き露出していると想定すべきである。前提条件は誤解されやすい。これは、未認証の第三者が無作為なクライアントにパケットを浴びせる攻撃ではない。クライアントがすでにピアを十分に信頼し、認証を完了して PUSH_REPLY オプションを受け入れる必要がある。侵害されたコンセントレータ、悪意のあるテストラボ、誤発行されたプロファイルは、依然として現実的な経路である。OpenVPN wiki が主張していない未認証リモートコード実行という物語に、勧告を誇張してはならない。

CVE-2026-84790 — 証明書サブジェクト内の NULL バイト

Padlock symbol representing encrypted network traffic — 出典： Wikimedia Commons — Padlock.svg

Linux Compatible によると、サブジェクト文字列に埋め込まれた NULL バイトを含む証明書は今後拒否される。OpenSSL ビルドでは、パーサーが最初の NULL バイトで停止するリスクが以前あった。mbedTLS ビルドはすでにそのような証明書を拒否していた。問題は BreachX の Vivek Parikh が報告し、修正は Max Fillinger が実装した。運用上の影響：以前は OpenSSL 上で「動作していた」アーカイブ済みまたは悪意を持って細工された証明書が、アップグレード後に失敗する可能性がある。証明書ツール担当チームは一斉展開の前にインベントリをスキャンし、2.7.8 以降の突然のハンドシェイク失敗を、偶発的なネットワーク障害ではなく証明書衛生のシグナルとして扱うべきである。

この拒否は、サブジェクト文字列の生成時に誤って NUL 文字を埋め込んだレガシーツールも壊す可能性がある。パーサー安全性の観点からはこの破損は望ましいが、変更ウィンドウにはインベントリ手順が必要である。OpenVPN のアップグレードと、サブジェクト内の非印字バイトを検出する証明書テキストレビューまたはエンタープライズ PKI レポートを組み合わせてから、展開完了を宣言すべきである。

CVE-2026-84256 — Windows CreateProcess のクォート処理

バージョン 2.7.8 は、Windows のコマンドラインクォート処理の強化を継続し、cmd.exe にとって特殊な文字が引用符付き引数の内部で変数展開を引き起こせないようにする。実装は Lev Stipakov、報告は Darren Carreras。同じ CVE 番号は 2.7.7 で部分的に対処済みであるため、2.7.8 は無関係な Windows バグではなく、同一経路に対する二度目の対応である。Windows 上で OpenVPN 周辺にシェルアウトするスクリプトは、アップグレード後に回帰テストが必要であり、特にユーザー制御のプロファイルパスやヘルパー引数を CreateProcess 経由で渡す場合にそうである。

CVE なしの tls-crypt-v2 堅牢性

tls-crypt-v2 ハンドシェイク中、OpenVPN は鍵材料が利用できない場合でもラップされたクライアント鍵を追加しようとし、ピアの再送要求を過度に信頼することがあった。2.7.8 の変更はこの盲目的な信頼を止める。Linux Compatible が伝えたイタリアの Computer Resilience Agency のガイダンスによれば、「悪意あるサーバーがクライアントの正常動作を停止させられる」ことは、機密性または完全性の CVE ではなく堅牢性の低下として扱われた。運用者はそれでもインストールすべきである。VPN クライアントに対する可用性攻撃は、CVE の体裁がなくても運用コストが高く、変更管理システムは非 CVE の強化を明示的に追跡すべきである。

欠落した識別子は、VPN セキュリティプログラムへのより広い教訓を示している。既に認証済みのピアに対する純粋な可用性問題について CVE ID を省略するポリシーは、運用者が明示的な堅牢性項目を記録しない限り、2.7.8 の一部を隠すことになる。Linux Compatible の 2026年10月7日の記事は有用な二次的文脈だが、変更チケットは依然として OpenVPN ReleaseHistory と CVE wiki ページを一次証拠としてリンクすべきである。

運用者が無視すべきでない隣接する可用性作業

CVE リストを超えて、2.7.8 はマルチクライアントおよびデータチャネルオフロードの動作を変更する。クライアントごとのルートは、遅延したマルチインスタンスクリーンアップ中ではなく実際の終了時に削除され、システムからルートが消えてしまうレースを修正する。専用の netlink ソケットが同期作業と非同期通知を分離する。ピアまたは鍵操作が、ピアがすでにカーネルから消えた後に失敗した場合、OpenVPN はサーバー全体を終了させる代わりに単一インスタンスを再起動する。これらの可用性と正確性の修正は、再接続ストーム下の大規模サーバーにとって CVE と同等に重要であり、Linux Compatible によれば一部は OpenVPN Inc. の Access Server チームによって報告された。

これは何ではないか

WireGuard のアドバイザリではない。2026年10月の個別の WireGuard 議論、LKML のハンドシェイク応答パッチおよび Zephyr keepalive 認証 CVE-2026-13735 を含むものは、独自のノートに属すべきである。
商用コンシューマーVPNブランド向けのベンダーリリースノートによるマーケティングではない。
認証済みサーバーのバグクラスを「テストする」ために、信頼できないサーバーを稼働させる許可ではない。

2026年10月には、運用者がOpenVPNのパッチと混同する可能性のあるWireGuard関連の議論も見られた。LKMLのhandshake-responseスレッドとNVDのCVE-2026-13735 Zephyr keepalive問題は実在するが、これらはOpenVPN 2.7.8に対するパッチではなく、OpenVPN 2.7.8もこれらを是正しない。インベントリはバイナリごとに分けて維持すること：コミュニティOpenVPN、カーネル内WireGuard、ユーザー空間WireGuard、Zephyrスタック、およびプロプライエタリなモバイルVPNアプリ。これらの系統を単一の「VPN CVE」スプレッドシートに混在させるのは、CVE-2026-88964が実際に指名しているWindowsおよびAndroidのOpenVPNクライアントをチームが見落とす原因となる。

防御側チェックリスト

2.7.xウィンドウ内のWindowsおよびAndroid OpenVPNクライアントを棚卸しし、2.7.8以降を展開すること。
OpenSSLフリートのアップグレード前に、証明書ストア内の埋め込みNULLバイトをスキャンすること。
インスタンス再起動の挙動変化を吸収するため、ステージングノードでDCOおよびマルチクライアント再起動をリハーサルすること。
修正にCVE IDがなくても、tls-crypt-v2の導入環境はパッチ済みビルドに維持すること。
変更チケットでは二次的なブログだけに頼らず、一次アドバイザリを引用すること。
OpenVPNクライアントのチケットを、WireGuardカーネルおよびZephyrのチケットから分離すること。

結論：OpenVPN 2.7.8を、制御チャネル解析、証明書衛生、Windowsプロセスのクォーティング、および大規模サーバーのデータチャネルオフロード安定性向けのセキュリティ兼可用性バンドルとして扱うこと。そのうえで、CVEクラスタをクローズと宣言する前に、自前のパッケージハッシュとステージングラボで検証すること。