CVE-2025-25249 の FortiGate 脆弱性｜影響確認と対処

はじめに

FortiGate の運用では、公表済みの脆弱性が後から悪用され、対応の優先度が変わることがあります。CVE-2025-25249 はその一例です。Fortinet が 2026 年 1 月にアドバイザリー FG-IR-25-084 を公開した脆弱性ですが、2026 年 9 月に入って悪用の観測が公表され、CISA の Known Exploited Vulnerabilities Catalog（以下 KEV）へ追加されました。

新たに発見されたゼロデイではなく、修正版もすでに提供されています。運用担当者に求められるのは、自環境が対象かどうかと、攻撃経路が実在するかどうかを切り分け、必要であれば更新に着手する前に侵害の可能性を扱うことです。

先に結論を示します。確認は「稼働中のバージョンが対象範囲に含まれるか」「fabric サービス経由で該当プロセスへ到達できるか」「到達し得た期間に侵害を疑う情報がないか」の 3 つに分かれます。ここで順序が問題になります。過去に脆弱かつ到達可能だった機器や、侵害を疑う情報がある機器では、更新や再起動を行う前にセッション情報などの揮発性情報を保全し、専門窓口への相談を検討します。更新と再起動は、判断材料になり得る情報を失わせる操作でもあるためです。

あわせて 2 点を補足します。1 つは、過去に露出していたことは調査の必要性を判断する材料であり、侵害が成立したことの証明ではないという点です。もう 1 つは、露出低減や封じ込めといった措置は、調査の完了を待たずに進めてよいという点です。保全を優先するのは更新と再起動であり、通信の遮断や到達性の制限まで止める必要はありません。

CVE-2025-25249 の概要と 2026 年 9 月の更新点

CVE-2025-25249 は、FortiOS と FortiSwitchManager の cw_acd デーモンに存在するヒープベースのバッファーオーバーフローです。Fortinet は CWE-122 として分類し、認証されていないリモートの攻撃者が細工したリクエストによって任意のコードまたはコマンドを実行できる可能性があるとしています。cw_acd は、FortiAP や FortiSwitch を管理する CAPWAP の制御通信を処理するプロセスです。

Fortinet はアドバイザリーの中で、ASLR や PIE といった保護機構が悪用の難易度を押し上げると説明しています。後述する CVSS の攻撃複雑度の評価にも関係する記述です。

参考: Fortinet PSIRT FG-IR-25-084
“The presence of security controls such as ASLR and PIE considerably raises the complexity”
（ASLR や PIE といったセキュリティ制御の存在により、悪用に必要な複雑さが大きく高まる）
https://fortiguard.fortinet.com/psirt/FG-IR-25-084

なお、同じ CAPWAP 関連の処理に関する脆弱性でも、CVE 番号が異なれば対象バージョンも回避策も異なります。当ブログで扱った CVE-2025-53844（FG-IR-26-123）とは別の脆弱性であり、設定内容を流用せず、それぞれのアドバイザリーで確認することを推奨します。

KEV への追加で変わった点

2026 年 9 月 8 日にセキュリティ企業 SOCRadar が悪用の観測を公表し、翌 9 日に CISA が KEV へ追加しました。KEV の dateAdded はカタログへの追加日であり、脆弱性の公開日とは異なります。

対応期限の 2026-09-12 は、CISA の Binding Operational Directive 26-04 にひも付く値です。同指示の適用対象は米国連邦政府の行政機関であり、日本の一般企業へ同じ法的期限が課されるものではありません。一方で forensicTriage が Yes である点は、優先度を判断する材料になります。CISA は KEV エントリーの要求事項として、資産ごとのインターネット露出を評価する責任にも触れています。

参考: CISA KEV Catalog（CVE-2025-25249 エントリー）
“Stakeholders are responsible for evaluating each asset’s internet exposure”
（関係者は、資産ごとのインターネット露出を評価する責任を負う）
https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2025-25249

knownRansomwareCampaignUse の Unknown は、ランサムウェアでの悪用がないという意味ではありません。CISA が判断できていない状態を表す値であり、悪用なしと読み替えると優先度の判断を誤る可能性があります。

CVSS スコアが情報源によって異なる理由

本 CVE は、参照する情報源によってスコアが 7.4 から 9.8 まで分かれます。数字だけを比べると判断を誤るため、評価主体とベクターを合わせて確認すると、判断がぶれません。

差の主因は攻撃複雑度です。Fortinet は ASLR と PIE を踏まえて High と評価し、NVD は Low と評価しています。SOCRadar は、CAPWAP の応答からメモリー上のアドレスを取得して ASLR を回避する手法を解析結果として公表しています。実際に悪用が観測されている状況を踏まえると、攻撃複雑度 High を対応不要の根拠にはできません。

対象製品と修正版

対象範囲は FG-IR-25-084 の Summary を基準にすると判定がぶれません。CVE Record では、説明文と構造化された affected 欄で範囲に差があり、説明文のほうが広い範囲を示しています。どちらか一方を機械的に転記すると、対象判定を誤る可能性があります。

FortiOS 6.4 は、修正版へのアップグレードではなく修正済みリリースへの移行が示されています。Fortinet が採番機関として提供する CVE Record の Solutions を見ても、記載があるのは FortiOS 7.0.18 以降、7.2.12 以降、7.4.9 以降、7.6.4 以降、および今後の 8.0.0 以降で、6.4 系の修正版は挙げられていません。6.4 系を運用している場合、6.4 内での更新では対応できない前提で計画を立てることになります。

本記事の対象・修正版は、FG-IR-25-084 の Summary と、Fortinet が提供する CVE Record の Solutions で確認できた範囲に基づいています。アドバイザリーは公開後に更新される場合があるため、対応判断の前に FG-IR-25-084 を直接参照し、表と Workarounds の内容を確認することを推奨します。

FortiSwitchManager と FortiSASE の扱い

FortiSwitchManager は FortiOS と同じく利用者側での更新が必要です。FortiSASE については、CVE Record の Solutions に、Fortinet 側で修正済みであり利用者の作業は不要である旨が記載されています。

参考: CVE Record CVE-2025-25249（Solutions）
“customers do not need to perform any action”
（利用者側で対応を行う必要はない）
https://www.cve.org/CVERecord?id=CVE-2025-25249

同じ Solutions では、修正が入ったバージョンとして FortiSASE 25.2.c と 25.1.b が挙げられています。NVD の解析結果では FortiSASE 25.2.b と 25.1.a.2 が影響を受ける版として記載されています。利用中のテナントがどのバージョンで稼働しているかは、管理画面または Fortinet のサポート窓口で確認できます。

最小修正版と実際の更新先を分けて考える

表に示した版は、この脆弱性を解消する最小限のバージョンです。運用上の更新先を決める際は、対象機種が動作可能な系列の中に修正版があるかどうかを、Fortinet のリリース情報とアップグレードパスツールで確認します。上位系列に対応していないという理由だけで機器更改が必要と判断せず、まず現行系列や対応可能な系列の修正版を確認する順序が実務的です。

系列のサポート期間も判断材料になります。公開されているライフサイクル情報では、FortiOS 7.0 は 2025 年 9 月 30 日、FortiOS 7.2 は 2026 年 9 月 30 日に End of Support を迎えるとされています。通常の End of Support と、FortiCare Elite 等の契約に付随する延長サポートは別の枠組みであり、適用条件も異なります。自社の契約が延長サポートの対象かどうかは、Fortinet のサポートポータルで確認することを推奨します。

系列をまたぐ更新では中間バージョンの経由が必要になる場合があります。経路の確認方法は『FortiGate アップグレードパス』で整理しています。

影響確認から対応までの流れ

対象判定と更新を同時に進めると、更新済みだから問題ないという判断に流れやすくなります。次の順序で進めると、脆弱性の解消と侵害調査を分けて扱えます。

この流れの中で、次の 3 つの問いを混同しないことが判断の分かれ目になります。

脆弱なバージョンか

アドバイザリーの表との照合だけで判定できます。設定や構成には依存しません。更新によって解消します。

攻撃経路があるか

fabric サービスの有効／無効と、どこから届くかで決まります。暫定対策の要否と、更新の順序を左右します。

すでに侵害された可能性があるか

過去に脆弱かつ到達可能だった期間があるかどうかで、調査の要否を判断します。露出していたこと自体は侵害の証明ではありません。この問いに答えるための情報は、更新と再起動で失われることがあります。

自環境の到達性確認と暫定対策

この脆弱性の入口は fabric サービスを通じた CAPWAP の制御通信です。SSL-VPN の無効化や管理 GUI の非公開は、この経路とは別の話であり、対象外と判断する根拠にはなりません。

fabric サービスの設定を確認する

まず、稼働バージョンと、各インターフェースの allowaccess に fabric が含まれるかを確認します。以下は確認用のコマンドです。

get system status
show system interface

出力の着眼点は 2 つです。1 つ目は、set allowaccess の値に fabric を含むインターフェースがあるかどうか。2 つ目は、そのインターフェースがインターネット側や委託先との接続点など、管理外の相手から到達し得る位置にあるかどうかです。VDOM を使用している場合は、VDOM ごとに確認します。

fabric を含むインターフェースが存在しない場合、外部から cw_acd へ到達する経路は想定しにくくなります。ただし、これは更新を見送る根拠ではなく、更新までの猶予を判断する材料として扱うのが妥当です。設定変更や機器追加によって fabric が有効化される場面は運用の中で起こり得ます。過去に有効だった時期があるかどうかも、設定変更履歴や構成管理の記録で確認します。

FortiAP を使っていない環境でも確認が必要な理由

Fortinet のドキュメントによると、FortiOS 6.4 以降の allowaccess における fabric は Security Fabric Connection を指し、FortiTelemetry と CAPWAP がまとめて有効になります。CAPWAP は FortiAP の管理だけでなく、FortiSwitch や FortiExtender の管理、Security Fabric における下流機器との接続にも使用されます。

つまり、無線 LAN を導入していない環境でも、FortiSwitch の管理や Security Fabric の構成のために fabric が有効になっている可能性があります。FortiAP の有無ではなく、実際の allowaccess の設定を根拠に判断します。

暫定対策 1: fabric アクセスを外す

FG-IR-25-084 の Workarounds では、対象インターフェースから fabric を外す方法が示されています。以下は公式アドバイザリーに記載された設定例です。

config system interface
    edit "port1"
        set allowaccess ssh https
    next
end

ここで注意が必要なのは、set allowaccess が既存の値を置き換える点です。公式例は fabric、ssh、https が設定された状態から fabric を除いた形になっています。実環境で ping や fgfm などが併せて設定されている場合、例をそのまま適用すると、それらのアクセスまで失われます。事前に show system interface で現在の値を確認し、残したいサービスをすべて列挙してから設定することを推奨します。

運用影響は、対象インターフェースと実際の構成によって変わります。そのインターフェースを経由して FortiAP、FortiSwitch、FortiExtender、下流の FortiGate が接続している場合、その接続に影響します。管理通信が別のインターフェースを経由している場合や、対象インターフェースに接続機器がない場合は、影響が生じないこともあります。どのインターフェースを経由して管理通信が流れているかを確認したうえで判断します。

暫定対策 2: local-in policy で CAPWAP-CONTROL を制限する

fabric を有効なまま運用する必要がある場合は、送信元を限定する方法が示されています。以下も公式アドバイザリーに記載された設定例です。

config firewall service custom
    edit "CAPWAP-CONTROL"
        set udp-portrange 5246-5249
    next
end

config firewall addrgrp
    edit "CAPWAP_DEVICES_IPs"
        set member "my_allowed_addresses"
end

config firewall local-in-policy
    edit 1
        set intf "port1"
        set srcaddr "CAPWAP_DEVICES_IPs"
        set dstaddr "all"
        set service "CAPWAP-CONTROL"
        set schedule "always"
        set action accept
    next
    edit 2
        set intf "port1"
        set srcaddr "all"
        set dstaddr "all"
        set service "CAPWAP-CONTROL"
        set schedule "always"
        set action deny
    next
end

この例は、local-in policy が未設定で、同名のオブジェクトも存在しない環境を前提にした記述になっています。既存設定がある環境では、次の点を確認します。

• ポリシー ID の 1 と 2 は例示。既存の local-in policy がある場合、同じ ID を指定すると既存ポリシーを書き換える。show firewall local-in-policy で使用済み ID と内容を確認し、未使用の ID を割り当てる
• local-in policy は ID の順に評価される。既存ポリシーより後ろに置くと、先に一致した既存ポリシーの動作が優先される場合がある。既存ポリシーを含めた評価順を確認したうえで配置する
• CAPWAP-CONTROL は例示のサービス名。同名のサービスオブジェクトが存在する場合、上書きによって他のポリシーへ影響する。show firewall service custom で確認し、必要であれば別名で作成する
• CAPWAP_DEVICES_IPs と my_allowed_addresses も例示の名称。許可対象となる FortiAP、FortiSwitch、下流機器のアドレスオブジェクトを先に作成し、アドレスグループへ登録してからポリシーを作成する
• 適用対象は fabric を有効にしているインターフェースごとに指定する。複数ある場合は set intf の値を分けて設定する
• 許可を先、拒否を後の順序にする。順序が入れ替わると、正規の管理通信も遮断される
• 5246-5249 は既定のポート範囲に基づく指定。独自にポートを変更している環境では、実際の値を確認してから定義する
• 適用後は show firewall local-in-policy で設定内容を確認し、FortiAP や FortiSwitch の管理状態、Security Fabric のトポロジ表示が維持されているかを併せて確認する

local-in policy は FortiGate 自身へ向かう通信を制御する仕組みで、通過する通信を制御するファイアウォールポリシーとは別に評価されます。Fortinet のドキュメントでも、両者は同じポリシーでは扱われないと説明されています。ファイアウォールポリシー側で CAPWAP を拒否しても、FortiGate 自身の cw_acd 宛ての通信は止まりません。

過去の CAPWAP 関連アドバイザリーでは、FMWP のバーチャルパッチを用いる回避策が案内された例があります。FG-IR-25-084 の Workarounds に同じ内容は含まれていないため、別アドバイザリーの設定をそのまま流用しないことを推奨します。

侵害の確認と更新

暫定対策は到達性を下げる措置であり、脆弱性そのものは残ります。修正版への更新を計画に組み込むことになりますが、その前に確認しておく点があります。

更新と再起動の前に扱うこと

セッションテーブルやプロセスの状態は、再起動すると失われます。ファームウェア更新は再起動を伴うため、過去に脆弱かつ到達可能だった機器では、更新に着手する前に次の順序で進めることを推奨します。

• セッション情報、プロセスの状態、設定、ログを取得して保全する
• 疑わしい点があれば、Fortinet TAC および自社のインシデント対応窓口へ相談し、以降の手順を確認する
• 露出低減や通信の遮断といった封じ込めは、調査の完了を待たずに実施してよい
• 保全と相談の結果を踏まえ、更新のタイミングを決める

過去に到達し得た経路がなく、侵害を疑う情報もない機器については、保全を待たずに更新を進めて差し支えありません。

侵害を疑う情報を確認する

ここからは SOCRadar の観測と評価に基づく内容です。同社は、2026 年 7 月以降に CVE-2025-25249 を悪用する活動を観測し、PivotC2 と名付けた Node.js 製のリモートアクセスツールが設置されると報告しています。攻撃者のファイルからは 30,000 を超える標的 IP アドレスの一覧と、178 台の感染セッションが確認されたとしています。

運用上の観点として重要なのは、報告されている機能のうち 2 点です。1 つは FortiGate の設定ファイルを収集し、保存された認証情報を復号する機能。もう 1 つは、SOCKS5 やポートフォワードによって内部ネットワークへ展開する機能です。侵害が成立していた場合、確認対象は FortiGate 単体にとどまりません。

確認に使う情報は、出典を分けて扱います。確認対象となる IoC は SOCRadar が公開したもの、コマンドの構文は Fortinet の公式資料で確認できるものです。以下は、SOCRadar が公開した C2 サーバーの IP アドレスとの通信を確認する例です。既存のフィルターが残っていると意図しない結果になるため、確認の前後でフィルターを解除します。

diagnose sys session filter clear
diagnose sys session filter dst 146.103.99.177
diagnose sys session list

diagnose sys session filter clear
diagnose sys session filter dst 46.151.29.58
diagnose sys session list

diagnose sys session filter clear

Fortinet のドキュメントでは、diagnose sys session filter のオプションとして clear（フィルターの解除）と dst（宛先 IP アドレス）が示されており、diagnose sys session list でフィルターに一致するセッションを表示します。

セッションを削除するコマンドは、フィルターが設定されていない状態で実行すると通信中のセッションに影響します。確認だけであれば表示系のコマンドで完結するため、この場面では削除系のコマンドを使用しないことを推奨します。

プロセスの確認には diagnose sys top 系のコマンドを使用します。Fortinet のドキュメントによると、diagnose sys top は CPU 使用率の高いプロセスを中心に表示するため、表示件数を増やす指定や、名前で絞り込む方法が案内されています。grep との併用は FortiOS 7.0.1 GA 以降でサポートされるとされています。

diagnose sys top 2 99 3
diagnose sys top-summary | grep node

ここで前提として押さえておきたいのは、Node.js が FortiOS に正規に含まれるという点です。Fortinet の公式資料に掲載されているプロセス一覧の例にも node は現れます。したがって、プロセス名の有無だけでは判断できません。プロセス数、起動の経緯、通信先と組み合わせて評価します。

SOCRadar は、ファイルシステム上の痕跡を確認する方法として fnsysctl を用いた例も示しています。Fortinet のドキュメントによると、fnsysctl の実行にはスーパー管理者権限が必要です。権限と実行可否を確認したうえで使用し、取得した結果は保全対象として扱うことを推奨します。

着眼点は、公開された C2 アドレスへのセッションが残っていないか、説明のつかない Node.js プロセスが動いていないか、想定外のファイルが配置されていないかです。実機での検証は行っていないため、本記事では出力例を掲載していません。

重要なのは、一致するものがなかったことが、侵害がなかったことの証明にはならないという点です。セッション情報は再起動で失われ、報告されたツールには痕跡を削除する機能も含まれています。公開 IoC は特定の観測に基づく限られた指標であり、C2 が変更されている可能性もあります。ログの保存期間、SIEM へ転送している範囲、機器の再起動履歴も併せて確認することを推奨します。

参考: SOCRadar Threat Research Unit（CVE-2025-25249 に関する調査）
“Patching closes the exploitation path but does not remove an implant”
（更新は悪用の経路を塞ぐが、設置済みのインプラントを除去するものではない）
https://socradar.io/blog/cve-2025-25249-pivotc2-fortigate-rat/

侵害が疑われる場合の進め方

• 更新、再起動、初期化を行う前に、設定、ログ、セッション情報、プロセスの状態を取得して保全する
• Fortinet TAC および自社のインシデント対応窓口へ連絡し、以降の手順を確認する
• 業務影響を踏まえ、通信の遮断や機器の切り離しといった封じ込めを、調査と並行して判断する
• 設定内に保存された認証情報の見直しを検討する。管理者アカウント、SSL-VPN 利用者、LDAP バインド、無線の事前共有鍵、IPsec の事前共有鍵が対象になる
• 内部側の調査へ広げる。認証情報の使い回しがある範囲と、FortiGate から到達できる内部ホストを確認する

復旧の具体的な手順は機器の状態と契約内容によって異なります。初期化や再構築の判断は、ベンダーの指示を確認したうえで進めることを推奨します。

更新の進め方と更新後の確認

Fortinet はアドバイザリー内で、アップグレードパスツールを用いた経路の確認を案内しています。系列をまたぐ場合は中間バージョンの経由が必要になることがあります。更新前の設定バックアップと、切り戻し手段の準備も併せて推奨します。手順は『FortiGate バックアップとリストア』で整理しています。

更新後は get system status でバージョンを確認し、業務通信と、FortiAP や FortiSwitch の管理状態が復帰しているかを確認します。HA 構成では両系のバージョンが揃っているかも確認対象です。更新によって脆弱性は解消しますが、更新前に判断を保留していた侵害の調査は、更新後も引き続き扱う必要があります。

まとめ

CVE-2025-25249 は、2026 年 1 月に公表された脆弱性が、9 月の悪用報告と KEV への追加によって対応の優先度を変えた事例です。修正版は提供済みであり、対応の中心は更新そのものよりも、対象判定と到達性の確認、そして更新に着手する前に侵害の可能性を扱うかどうかの判断にあります。

• 2026 年 1 月公開の脆弱性に対する 9 月の悪用報告と KEV への追加
• FortiOS 6.4 は対応可能な系列の修正版を確認したうえで移行を計画
• FortiAP の有無ではなく fabric サービスの設定で到達性を判断
• 暫定対策は既存のポリシー ID、オブジェクト名、評価順を確認してから適用
• 過去に到達可能だった機器は更新と再起動の前に揮発性情報を保全
• 露出低減と封じ込めは調査の完了を待たずに進める
• 過去の露出は調査要否の判断材料であり侵害の証明ではない

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