CVE-2025-68686 が KEV 追加｜FortiGate 侵害確認の手順

はじめに

2026 年 7 月 27 日、CISA の Known Exploited Vulnerabilities（KEV）カタログに CVE-2025-68686 が追加されました。FortiOS の SSL-VPN に存在する情報漏えいの脆弱性で、Fortinet のアドバイザリ FG-IR-25-934 として 2026 年 2 月 10 日に公開されていたものです。

このアドバイザリは CVSSv3 スコア 5.3 の Medium 判定であり、Fortinet 側の Known Exploited フィールドは本稿執筆時点でも No のままです。攻撃の成立には「事前に別の脆弱性で侵害されていること」という前提条件も付いています。既知かつ中程度の評価だった脆弱性が、公開から半年近く経ったこのタイミングで KEV に載った理由がわかりにくく、対応の要否に迷う運用担当の方も多いのではないでしょうか。

先に結論を述べます。SSL-VPN を一度も有効化したことがない機器は本脆弱性の対象外です。SSL-VPN を利用している機器では、FortiOS 7.6.2 以上または 7.4.7 以上への更新が対処となり、7.2 以下のブランチには修正版が提供されないため、ブランチ内のアップグレードでは解決しません。そのうえで、本脆弱性は単独では成立せず過去の侵害が前提となる性質上、KEV 追加が示しているのはパッチ適用の緊急度というより、過去に侵害を受けた痕跡が残っていないかを確認する必要性です。

CVE-2025-68686 と KEV 追加の概要

本脆弱性は、攻撃者が別の脆弱性で FortiGate のファイルシステムへの読み取りアクセスを確立した後、その足がかりを維持し続けるために悪用されるものです。攻撃の起点そのものではなく、侵害後の永続化に関わる位置づけになります。

アドバイザリ FG-IR-25-934 の基本情報

Fortinet が公開しているアドバイザリの主要項目は以下のとおりです。

CVSSv3 のベクターは AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N です。機密性への影響は High と評価されている一方で、攻撃条件の複雑さが High（AC:H）であることがスコアを押し下げ、基本値が 5.3 に収まっています。AC:H が付いているのは、攻撃者が事前に別の脆弱性で侵害を成立させている必要があるためです。なお時間評価は E:P/RL:O/RC:C で、概念実証コードが存在する状態であることが示されています。

参考: SSL-VPN Symlink Persistence Patch Bypass（FG-IR-25-934）
“An attacker would need first to have compromised the product via another vulnerability”
（攻撃者はまず、別の脆弱性によって製品を侵害しておく必要があります）
https://fortiguard.fortinet.com/psirt/FG-IR-25-934

この前提条件は、リスク評価において二通りの読み方ができます。ひとつは「単独では成立しないため緊急度は低い」という読み方、もうひとつは「悪用が観測されたのであれば、その環境ではすでに別の侵害が成立している」という読み方です。KEV 追加は後者の見方を裏付ける材料になります。

ベンダー評価と KEV 掲載のずれをどう読むか

ここで実務上の混乱を招きやすいのが、Fortinet のアドバイザリと CISA KEV で悪用状況の記載が食い違って見える点です。アドバイザリの Known Exploited は No のままですが、KEV は悪用の証拠が確認されたものを掲載するカタログです。

このずれは、両者が異なる基準とタイミングで更新されていることに起因します。ベンダーのフィールドは自社のテレメトリや調査に基づいて更新され、KEV は CISA が独自に収集した悪用の証拠に基づいて追加されます。どちらか一方だけを監視していると、実際のリスク状況を見誤る可能性があります。 脆弱性管理の運用では、ベンダーアドバイザリと KEV の双方を確認する体制をおすすめします。ベンダー側の一次情報をどこで確認するかについては、関連記事『Fortinet 公式情報の探し方』も参考になります。

KEV エントリの内容も確認しておく価値があります。CVE-2025-68686 のエントリでは、Due Date が 2026 年 8 月 10 日に設定されています。追加日が 7 月 27 日ですので、猶予は 14 日間です。Action 欄には、ベンダーの指示に従った緩和策の適用に加えて、BOD 26-04 と「Forensics Triage Requirements」への準拠が求められる旨が記載されています。単なるパッチ適用ではなく、侵害の有無を判定するフォレンジック的な確認が対応内容に含まれている点が、本エントリの特徴です。

Due Date は米国連邦政府の行政機関を対象とした期限であり、日本の民間企業に直接の拘束力はありません。ただし優先度を判断する目安としては参考になります。BOD 26-04 が KEV の位置づけをどう変えたかについては、記事後半で改めて整理します。

symlink 永続化とパッチ回避の技術的な仕組み

本脆弱性を理解するには、2025 年 4 月に Fortinet が公表した symlink による永続化手法を先に押さえる必要があります。CVE-2025-68686 は、その手法を封じるために実装されたパッチの検査ロジックを、パスの表記を変えるだけで素通りさせられるというものです。

2025 年 4 月の symlink 永続化手法

2025 年 4 月、Fortinet は攻撃者が FortiGate に対して読み取り専用のアクセスを維持し続ける手法を確認したと公表しました。攻撃者は FG-IR-22-398、FG-IR-23-097、FG-IR-24-015 といった既知の脆弱性を初期侵入に利用し、そのうえでユーザーファイルシステムとルートファイルシステムを結ぶシンボリックリンクを作成していました。設置先は、SSL-VPN が言語ファイルを配信するために使用するフォルダーです。

この手法が問題視されたのは、永続性の高さによるものです。シンボリックリンクの作成はユーザーファイルシステム上で行われるため、初期侵入に使われた脆弱性を修正したファームウェアに更新しても、リンク自体は残り続けます。 結果として、攻撃者は認証を経ずに設定ファイルを含むファイルを読み出せる状態を維持できていました。同社は、SSL-VPN を一度も有効化していない環境は本件の影響を受けないとしています。

Fortinet はこれに対し、AV/IPS シグネチャによる検出と自動削除、および FortiOS 7.6.2、7.4.7、7.2.11、7.0.17、6.4.16 の各リリースでの対応を実施しました。これらのリリースでは、アップグレード時に悪性のシンボリックリンクを削除するとともに、SSL-VPN 側が想定外のファイルを配信しないよう UI が修正されています。CVE-2025-68686 は、この後者の配信抑止の部分に関わる問題です。

ダブルスラッシュでパス検査を回避する仕組み

発見者である ITRESIT の Peter Gabaldon 氏は、修正済みファームウェアを解析し、追加された検査ロジックが strstr による部分文字列の一致判定に依存していることを確認しました。

参考: Bypassing the FortiGate Symlink Patch: The Double Slash Technique（Labs at ITRES）
“the patch relied on a weak string matching check (strstr) looking specifically for /lang/custom”
（パッチは /lang/custom を対象とした脆弱な文字列一致検査に依存していました）
https://labs.itresit.es/2026/02/11/fortigate-symlink-persistence-method-patch-bypass-cve-2025-68686/

実装されていた判定の流れは、要求されたパスに /lang/custom という文字列が含まれるかを調べ、含まれる場合のみシンボリックリンクの妥当性を検証し、含まれない場合は検証を行わずに処理を続けるというものでした。この設計は、当該ディレクトリにアクセスするリクエストには必ず /lang/custom という文字列が含まれる、という前提に立っています。

この前提が崩れる原因が、パスの正規化と文字列一致のずれです。 Linux のファイルシステムと一般的な Web サーバーは、/lang/custom と /lang//custom を同一のディレクトリとして解決します。一方で strstr にとって両者は完全に別の文字列です。スラッシュを 1 つ重ねるだけで検査対象から外れ、それでいてファイルは正しく配信されることになります。

同氏が修正済みの実機で検証した結果は次のとおりです。

つまり、2025 年 4 月の対策を適用済みの機器であっても、悪性のシンボリックリンクが残っていれば、読み取り専用アクセスが再び成立しうる状態にありました。セキュリティ上の判定を、入力を正規化する前の文字列比較で行うという設計は、パストラバーサル対策全般で繰り返し指摘されてきた典型的な失敗パターンでもあります。

運用側の観点では、この仕組みは検知の手がかりにもなります。言語ファイル配信のパスに対して、スラッシュが重複した形のリクエストが記録されていないかは、確認する価値のある観点です。 ログの保持期間内であれば、遡って調査できる可能性があります。

影響を受けるバージョンと修正リリース

対応方針は、稼働している FortiOS のブランチによって大きく異なります。7.6 と 7.4 はブランチ内のアップグレードで解決しますが、7.2 以下では修正版が提供されておらず、上位ブランチへの移行が必要になります。

バージョン別の対応表

Fortinet のアドバイザリが示す影響範囲と対処は以下のとおりです。

前提として押さえておきたいのが、SSL-VPN を一度も有効化したことがない機器は本脆弱性の影響を受けないという点です。アドバイザリにもその旨が明記されています。SSL-VPN を無効のまま運用してきた環境であれば、本件を理由とした緊急のアップグレードは不要と判断できます。ただし、過去に一時的にでも有効化していた期間がある場合は対象に含まれるため、設定変更の履歴を確認したうえで判断することをおすすめします。

なお、アドバイザリの影響対象に FortiOS 8.0 の記載はありません。

7.2 / 7.0 / 6.4 が「全バージョン影響」となる理由

ここが本件で最も誤解を生みやすい箇所です。2025 年 4 月の symlink 永続化への対策では、7.6.2 と 7.4.7 に加えて 7.2.11、7.0.17、6.4.16 でも対応が行われていました。

参考: Analysis of Threat Actor Activity（Fortinet PSIRT Blog）
“Upgrading to this release will remove the malicious symbolic link”
（このリリースへアップグレードすることで、悪性のシンボリックリンクが削除されます）
https://www.fortinet.com/blog/psirt-blogs/analysis-of-threat-actor-activity

そのため「前回は 7.2.11 で対応できたのだから、今回も 7.2 系の最新版に上げれば済む」と考えたくなりますが、今回のバイパス修正が提供されているのは 7.6.2 以上と 7.4.7 以上のみです。アドバイザリが 7.2 以下について「修正済みリリースへ移行」という表現を用いているのは、当該ブランチ内に修正版が存在しないことを意味します。7.2 系の最新パッチを適用しても、本脆弱性は残ったままになります。

この背景には、各ブランチのライフサイクル上の位置づけがあると考えられます。FortiOS 7.0 と 6.4 はすでにサポートが終了しており、7.2 についても終了時期が近いとする第三者の集計があります。ただし正確な日付は Fortinet の Product Life Cycle ページで確認する必要があり、本稿では断定を避けます。いずれにせよ、7.2 以下で運用している環境では、本脆弱性への対応がブランチ移行の検討と一体になります。

ブランチをまたぐアップグレードでは、途中のバージョンを経由する必要があるかどうかの確認が欠かせません。アップグレードパスの調べ方や作業時間の見積もり、HA 構成での進め方については、関連記事『FortiGate アップグレードパスの確認方法』にまとめていますので、あわせて参照してください。Fortinet が提供している Upgrade Path Tool（https://docs.fortinet.com/upgrade-tool ）も、アドバイザリ内で案内されています。

IPS 仮想パッチによる暫定緩和

すぐにアップグレードできない事情がある場合の選択肢として、Fortinet は仮想パッチを提供しています。アドバイザリによると、FG-VD-60389.0day. という名称の仮想パッチが FMWP データベースのアップデート 26.033 で利用可能です。

また、2025 年 4 月の対策の時点で、悪性のシンボリックリンク自体は AV/IPS エンジンによって検出および自動削除の対象となっていました。この動作にはエンジンのライセンスが有効であることが前提となります。

仮想パッチはあくまでアップグレードまでの時間を確保するための手段であり、恒久的な対処ではありません。 適用にあたっては FortiGuard のサブスクリプション状態と、データベースが該当バージョン以上に更新されているかの確認が必要です。仮想パッチの有効化手順やデータベースバージョンの確認方法は、関連記事『FortiGate 仮想パッチの設定手順』で扱っています。

自組織の FortiGate で確認する手順

確認は 3 段階に分けて進めることをおすすめします。まず稼働バージョンと SSL-VPN の利用状況から該当可否を切り分け、該当する場合は侵害痕跡の有無を調べ、痕跡が見つかった場合は復旧手順に移ります。

稼働バージョンと SSL-VPN 設定の確認

稼働中のファームウェアバージョンは、CLI から確認できます。

get system status

このコマンドは、ファームウェアのバージョン、ビルド番号、ブランチポイントのほか、シリアル番号やウイルス定義のバージョンなどをまとめて表示します。出力された Version の行を、前掲のバージョン別対応表と照合してください。

SSL-VPN の設定状況は、以下で確認できます。

show vpn ssl settings
show full-configuration vpn ssl settings

show vpn ssl settingsはデフォルト値以外の設定のみを表示するため、SSL-VPN を構成していない機器では出力がほとんど得られません。デフォルト値も含めてすべて確認したい場合はshow full-configurationを使用します。あわせて、SSL-VPN 向けのファイアウォールポリシーが存在するかどうかも確認しておくと判断材料が増えます。

参考: Troubleshooting Tip: Recommended steps to execute in case of a compromised host（Fortinet Community）
“A FortiGate with these versions will not boot if integrity is compromised”
（これらのバージョンの FortiGate は、整合性が損なわれている場合には起動しません）
https://community.fortinet.com/fortigate-3/troubleshooting-tip-recommended-steps-to-execute-in-case-of-a-compromised-host-118585

ここで注意したいのが、現在の設定を見るだけでは「過去に SSL-VPN を有効化していたか」は判断できないという点です。本脆弱性の前提となるシンボリックリンクは 2025 年 4 月以前に設置された可能性があるため、その当時に SSL-VPN が動作していたかどうかが判断の分かれ目になります。過去の設定バックアップが保管されているようであれば、あわせて確認することをおすすめします。

なお FortiOS 7.4.1 以降では、SSL-VPN の Web モード設定がデフォルトで無効かつ GUI と CLI から非表示となり、SSL-VPN のメニュー自体も GUI でデフォルト非表示に変更されています。7.4 系にアップグレードした環境では、設定が残っていても GUI 上で見えていないことがあるため、CLI での確認をおすすめします。

侵害痕跡が残っていないかの確認

バージョンと SSL-VPN の利用状況から該当すると判断された場合、次に確認すべきは悪性のシンボリックリンクが残っていないかです。本脆弱性は、リンクが残存している機器でのみ実害につながるためです。

この確認には、発見者である ITRESIT が公開している検査スクリプトを利用する方法があります。修正の適用状況と、シンボリックリンクへのアクセス可否の 2 点を外部から検査するものです。ただし、外部からの HTTP 応答に基づく検査であるため、判定できる範囲には限界があります。 導入手順と結果の読み方、判定できない条件については、関連記事『FortiGate symlink 残存の検査手順』にまとめています。（別途掲載予定）

なお、検査の対象は自組織が管理する機器に限定してください。

侵害が疑われる場合の対応

痕跡が確認された場合、あるいは判断がつかない場合は、設定情報がすでに窃取されている前提で復旧を進める考え方が推奨されています。Fortinet も 2025 年 4 月の公表時点で、影響を受けた顧客に対して設定を侵害された可能性があるものとして扱うよう案内していました。

Fortinet Community の復旧手順では、おおむね次の流れが示されています。

• ログ、設定バックアップ、診断出力を作業前に保全する
• ファームウェアを Fortinet サポートサイトから取得し、SHA512 でチェックサムを検証する
• 機器をネットワークから切り離す
• フラッシュをフォーマットし、TFTP でクリーンインストールを実施する
• ログディスクのパーティションもフォーマットする
• 推奨アップグレードパスに従って最新版へ更新する

設定を復元した後の資格情報の扱いが、実務では見落とされやすい部分です。 管理者、ローカルユーザー、VPN ユーザーの資格情報に加えて、RADIUS シークレットと IPsec の事前共有鍵のリセット、証明書の入れ替えと失効も対象に含まれます。あわせて、管理アクセスを外部インターフェースで無効化する、信頼済みホストからのログインに限定する、多要素認証を導入するといったハードニングも案内されています。

なお FortiOS 7.6.0、7.4.0、7.2.5、7.0.12、6.4.13 以降では、起動プロセスに整合性チェックが組み込まれています。ただし、これは起動時のチェックであり、本件のようにユーザーファイルシステム上に残されたシンボリックリンクを検出するものではない点に留意してください。判断に迷う場合は、Fortinet TAC に相談することで整合性の検証支援を受けられます。

恒久的な攻撃面の削減と優先度の考え方

本脆弱性への直接の対処はアップグレードですが、同じ経路を起点とする問題が繰り返し発生している以上、攻撃面そのものを見直す価値があります。あわせて、KEV 追加をどの程度の優先度として扱うかの考え方も整理します。

SSL-VPN 自体を廃止するという選択肢

本脆弱性が成立する条件を突き詰めると、SSL-VPN を有効化していないことが最も確実な対策になります。 アドバイザリも、SSL-VPN を一度も有効化していない製品は影響を受けないとしています。

Fortinet 自身も、FortiOS におけるリモートアクセスの代替手段として IPsec VPN と ZTNA を挙げています。FortiOS 7.4.1 以降で SSL-VPN の Web モード設定がデフォルト無効となり、GUI 上でも非表示に変更されたことは、この方針を反映したものと読み取れます。

ただし、SSL-VPN の廃止は移行計画を伴うため、本脆弱性への即時の対処にはなりません。今回はアップグレードで対応し、中期的な課題として移行を検討する、という二段構えが現実的です。TCP/443 を維持したまま IPsec VPN へ移行する方法については、関連記事『FortiGate SSL-VPN 廃止と IPsec VPN への移行手順』で扱っています。

BOD 26-04 が変えた KEV の位置づけ

KEV 追加の重みは、2026 年 6 月 10 日に CISA が発出した BOD 26-04 によって変化しています。この指令は BOD 19-02 と BOD 22-01 を廃止し、一律の期限による対応から、リスクに基づく優先度付けへと枠組みを切り替えたものです。

参考: BOD 26-04: Prioritizing Security Updates Based on Risk（CISA）
“efficiently prioritizing high-risk vulnerabilities for timely action, while deferring action against low-risk vulnerabilities”
（高リスクの脆弱性を効率的に優先して速やかに対応し、低リスクのものへの対応は先送りする）
https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk

優先度は、資産がインターネットに公開されているか、KEV に掲載されているか、悪用を自動化できるか、技術的影響がどの程度かという 4 つの変数で決まります。組み合わせに応じて、3 日、14 日、60 日、次回のアップグレード時という段階的な期限が割り当てられます。CVE-2025-68686 は 14 日の区分に該当しています。

実務上の示唆として押さえておきたいのが、BOD 19-02 の廃止によって CVSS が必須の判断材料から外れたという点です。CVSS 5.3 という数値だけを見て後回しにする判断は、この枠組みでは成立しません。KEV に掲載されている時点で、実際に悪用が観測された脆弱性として扱われます。

日本の民間企業に直接の拘束力はありませんが、脆弱性管理の優先度を組み立てる際の参考にはなります。特に本件では、対応内容に侵害の有無を判定するフォレンジック的な確認が含まれている点が重要です。パッチを当てて終わりにせず、過去に痕跡が残っていないかを確認するところまでを一連の対応として設計することをおすすめします。

まとめ

CVE-2025-68686 は、FortiGate の SSL-VPN に対する symlink 永続化への対策を、パスの表記を変えるだけで回避できるという脆弱性です。CVSS 5.3 の Medium 判定でありながら KEV に追加された背景には、すでに侵害を受けた機器が一定数残っているという現実があります。対処はアップグレードですが、実務上の要点は過去の痕跡の確認にあります。

• SSL-VPN の symlink 対策を回避する情報漏えいの脆弱性
• 2026 年 7 月 27 日に CISA KEV へ追加、期限は 8 月 10 日
• 対処は FortiOS 7.6.2 以上または 7.4.7 以上への更新
• 7.2 以下は修正版がなく上位ブランチへの移行が必要
• SSL-VPN を有効化したことがない機器は影響対象外
• 実害が生じるのは過去の侵害痕跡が残る機器に限られる
• 仮想パッチは時間を確保する手段であり恒久対処ではない

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