OpenVPNに7件の脆弱性が公表され、修正版2.6.21／2.7.5が2026年7月2日に公開されました。さらに8月6日には別の問題を修正した2.6.22／2.7.6が出ています。影響の多くは「VPNサーバを落とされる（サービス妨害）」もので、情報漏えい型の脆弱性ではありません。ただしリモートアクセスの入口が止まれば、在宅勤務者は業務ごと止まります。
そして実務上いちばんの落とし穴は、7月に慌てて対応した組織が「もう当てたから大丈夫」と思い込むことです。1か月のあいだに2回、修正版が出ています。
この記事でわかること
- 7件のCVEの内容と、影響を受けるバージョンの範囲
- 7月版（2.6.21／2.7.5）と8月版（2.6.22／2.7.6）の違い
- 「OpenVPNを入れた覚えがない」組織でも影響しうる理由
- 可用性の問題を、経営層にどう説明して優先度を取るか
何が起きたのか
OpenVPNプロジェクトは2026年7月2日、OpenVPN 2.6.21および2.7.5を公開し、7件のCVEを修正しました。報告者はセキュリティ研究者のValton Tahiri氏です。内容はuse-after-free（解放済みメモリの使用）、メモリリーク、バッファ処理の不備など、いずれもメモリの扱いに関する不具合が中心です。
さらに8月6日には2.6.22および2.7.6が公開されました。こちらはWindows版のサービス（openvpnserv）に関するCVE-2026-63649と、DCO（カーネル側でのデータ処理機能）における鍵状態の不整合の修正です。リリースノートでは、コントロールソケットから渡されるコマンドラインの検証が不十分で、管理者が設定した「使ってよい設定ファイルの置き場所」の制限を回避できる問題だったと説明されています。
つまり、7月のパッチで打ち止めではありません。バージョン確認は「2.6.21以上か」ではなく、今の時点では「2.6.22以上／2.7.6以上か」で行う必要があります。
影響を受けるバージョンとCVE一覧
7月2日の2.6.21／2.7.5で修正された7件は次のとおりです。CVSSスコアは、JVNDB（JPCERT/CCとIPAが運営する日本語の脆弱性データベース）で確認できたものを記載しています。
| CVE | 内容 | 影響を受けるバージョン | CVSS v3 |
|---|---|---|---|
| CVE-2026-13379 | Windows版サービスのDNSサーチリスト処理。細工されたサーチドメインでDNS設定の汚染やクラッシュ | 2.7_alpha1〜2.7.4（Windows） | 9.1 |
| CVE-2026-13117 | TLSセッション昇格時のuse-after-free（tls_wrap_reneg） | 2.6.0〜2.6.20、2.7_alpha1〜2.7.4 | 8.1 |
| CVE-2026-12996 | ack_write_buf処理のuse-after-free | 2.6.0〜2.6.20、2.7_alpha1〜2.7.4 | — |
| CVE-2026-11771 | NTLMv2プロキシ応答処理での1バイトのバッファ書き込み超過 | 2.1.0〜2.6.20、2.7_alpha1〜2.7.4 | 7.5 |
| CVE-2026-13698 | tls-crypt-v2パケット受信時のメモリリーク（メモリ枯渇でサーバ停止） | 2.5.0〜2.5.11、2.6.0〜2.6.20、2.7_alpha1〜2.7.4 | 7.5 |
| CVE-2026-12932 | tls-crypt-v2クライアント鍵の取り出し処理でのメモリリーク | 2.5.0〜2.6.20、2.7_alpha1〜2.7.4 | — |
| CVE-2026-13122 | –auth-gen-token external-auth有効時、不正な認証トークンでサーバがクラッシュ | 2.6.0〜2.6.20、2.7_alpha1〜2.7.4 | 5.3 |
「—」は、本稿執筆時点でJVNDBに該当項目を確認できなかったものです。海外のデータベースにはスコアが掲載されていますが、記載内容に揺れがあったため、ここでは日本語の一次情報で裏の取れた数値のみを載せています。
特に見ておきたい3件
- CVE-2026-13379（CVSS 9.1）：唯一の「クリティカル」相当で、しかもサーバではなくWindowsクライアント側の問題です。対象は2.7系のみですが、サーバだけ直しても終わらない点に注意してください。
- CVE-2026-13117（CVSS 8.1）：認証済みのピア（＝接続してきた正規のクライアント）が引き起こせるuse-after-freeです。「外部から誰でも」ではありませんが、社員端末が乗っ取られていれば前提条件は満たされます。
- CVE-2026-13698 / CVE-2026-12932：どちらもtls-crypt-v2に関するメモリリークです。2.5系も影響範囲に含まれているのがポイントで、古い環境ほど放置されている可能性があります。
自社は影響を受けるのか？
「OpenVPNを導入した記憶がない」組織でも影響しうる、というのが答えです。OpenVPNはオープンソースであり、単体のソフトとしてだけでなく、さまざまな製品に組み込まれた形で動いています。
- NAS製品のVPNサーバ機能
- オープンソース系ファイアウォール／UTM（pfSense、OPNsenseなど）のVPN機能
- 各種ルータ・アプライアンスの「VPN接続」メニュー
- LinuxサーバにOSのパッケージとして入っているopenvpn
- クラウド上に構築した検証用の踏み台VPN（作った本人が異動して誰も見ていない、という典型例）
したがって棚卸しの対象は「OpenVPNという製品」ではなく、「OpenVPNを内蔵している機器」です。組み込み製品の場合、ベンダーがファームウェアを出すまで利用者側では手を出せません。まずは自社の機器がどのバージョンを使っているかをベンダー情報で確認し、提供時期を問い合わせるところからになります。
資産の把握そのものが曖昧なら、個別対応の前に仕組みを整える段階です。手順の型は脆弱性管理とは？プロセスと情シスの進め方を解説にまとめています。
情報漏えいではないのに、なぜ急ぐのか
今回のCVEは、影響のほとんどが「サービス妨害（DoS）」です。データが盗まれるわけではないため、社内の優先度づけでは後回しにされがちです。ここは説明の仕方を変えたほうが通ります。
VPNサーバが落ちるとは、在宅勤務者・出張者・支社の全員が社内システムに入れなくなるということです。しかもメモリ枯渇によるクラッシュは、再起動してもまた同じパケットを送られれば再発します。これは情報漏えいリスクではなく事業継続（BCP）の問題であり、その言葉で説明したほうが経営層には響きます。「何人が何時間、何もできなくなるか」が具体的な数字になるからです。
現場目線の課題
正論としては「速やかに最新版へ更新」で終わる話ですが、VPNサーバほど触りたくない機器もありません。更新には再起動が伴い、再起動すれば接続中の全員が切断されます。日中はもちろん、夜間でも当番や海外拠点がつながっている。結果として「次の連休に」と先送りされ、その連休がまさに攻撃者に狙われる、という繰り返しになりがちです。今年はお盆と月例パッチの時期が重なるため、体制が薄くなる点も含めて夏季休暇のセキュリティ対策と合わせて段取りを組んでおきたいところです。
もう一つ厄介なのがクライアント側です。CVSS 9.1のCVE-2026-13379はWindowsクライアントの問題ですが、OpenVPNのGUIクライアントは自動更新が効かない構成も多く、配布・展開の手間がかかります。管理外の私物端末や委託先の端末となると、そもそも把握できているかどうかから怪しい。サーバのバージョンを上げて「対応完了」と報告した後で、クライアントが残っていたと気づく——ありがちな抜けです。
情シスはどうすべきか
まずやることはシンプルです。
- バージョンの確認：サーバ・クライアントの双方。基準は2.6.22以上／2.7.6以上（7月版の2.6.21／2.7.5では8月修正分が入っていません）。
- 設定の確認：tls-crypt-v2を使っているか、
--auth-gen-token external-authを有効にしているか、プロキシ経由でNTLM認証をしているか。使っていない機能に関するCVEは、自組織での優先度を下げられます。 - 2.5系の洗い出し：メモリリーク2件は2.5系も影響範囲です。古い機器に残っていないか確認し、残っていれば計画的な移行対象に上げます。
- 組み込み製品はベンダーに確認：NASやUTM内蔵のVPN機能は、ベンダーのファームウェア公開待ちになります。
そのうえで、パッチ適用の段取りや運用体制の整え方は、自前でチェックリストを作り込むより公的機関の資料を土台にしたほうが早く、社内説明にも使えます。IPA「中小企業の情報セキュリティ対策ガイドライン」は、規模を問わず「何をどの順で決めるか」の骨組みとして使えます。VPNが止まった場合の連絡・代替手段を事前に決めておきたいなら、IPA「セキュリティインシデント対応 机上演習教材」で一度演習しておくと、当日の判断が段違いに速くなります。
中長期の視点
VPNの脆弱性が公表されるたびに全社が緊張する構造そのものが、そろそろ限界だという指摘もあります。VPNは「入れた人は中の人」という前提で作られているため、入口が一点集中になり、そこが落ちれば全員が止まります。この構造を見直す選択肢としてZTNA（ゼロトラストネットワークアクセス）やゼロトラストの考え方がありますが、乗り換えれば脆弱性がなくなるわけではありません。移行は数年がかりの話であり、今回のような月次の更新作業は当面続きます。まずは目の前のバージョンを上げつつ、更新のたびに全社が止まる運用でよいのかを、中期の課題として置いておくくらいが現実的でしょう。
まとめ
- OpenVPNは7月2日の2.6.21／2.7.5で7件のCVEを修正し、8月6日にはさらに2.6.22／2.7.6が公開。「7月に対応済み」で止まっていないか確認が必要です。
- 最大はCVSS 9.1のCVE-2026-13379で、これはWindowsクライアント側の問題。サーバだけ更新しても対応は完了しません。
- 影響の中心はDoS（可用性）。情報漏えいではなく事業継続の問題として説明したほうが、優先度と作業時間を確保しやすくなります。
出典
- OpenVPN — Release v2.7.5（2026年7月2日）
- OpenVPN — Release v2.6.22（2026年8月6日）
- JVN iPedia — JVNDB-2026-027113（CVE-2026-13379）
- JVN iPedia — JVNDB-2026-027088（CVE-2026-13117）
- JVN iPedia — JVNDB-2026-027108（CVE-2026-11771）
- JVN iPedia — JVNDB-2026-023519（CVE-2026-13122）
- JPCERT/CC — Weekly Report 2026-08-05
- IPA — 中小企業の情報セキュリティ対策ガイドライン
