FortiSandboxの未認証RCE(CVE-2026-25089/39808):管理UIの外部露出を自分で点検する
2026年7月16日、CISAのKEV(Known Exploited Vulnerabilities)カタログに、Fortinet FortiSandbox のOSコマンドインジェクション CVE-2026-25089 と CVE-2026-39808 が追加された。いずれもCVSS 9.1で、未認証の攻撃者が細工したHTTPリクエストで任意コマンドを実行できる。すでに実際の悪用が報告されている。
FortiSandbox は他のFortinet製品が脅威判定を委ねる基盤なので、ここが乗っ取られると連携製品のブロック判断や自動対応まで骨抜きになりかねない。最優先はFortinetの修正版への更新だが、それと並行して「そもそも管理UIが外から見えていないか」を点検する価値が大きい。攻撃の前提はWEB UI(管理インタフェース)へのネットワーク到達性だからだ。
本記事は自分が管理する資産に対する防御的な露出確認の手順である。他者の資産をスキャンしてはいけない。
前提:脆弱性の要点
- 対象: FortiSandbox / FortiSandbox Cloud / FortiSandbox PaaS
- 種別: 未認証のOSコマンドインジェクション(WEB UI経由)
- 対応: Fortinetの修正版へ更新(FortiGuard PSIRT で該当アドバイザリを確認)
- 悪用: 観測済み・KEV追加(2026-07-16)
手順1: 管理UIが外部から到達可能か確認する
まず、インターネット側から自社のFortiSandbox管理UI(HTTPS)に到達できてしまわないかを確認する。到達性の確認だけで、攻撃コードは一切送らない。
1 | |
到達できる場合、ログインページのタイトルやサーバーヘッダで製品を推定できる。ここも通常のHTTP GETのみで、脆弱性を突く操作は行わない。
1 | |
Fortinet製品はレスポンスにベンダ由来の文字列やログイン画面の特徴が出ることが多い。外部から管理画面が開けてしまうなら、それ自体が是正対象だ。
手順2: 資産の棚卸しと分類
FortiSandboxは物理アプライアンス・仮想アプライアンス・Cloud・PaaSと形態が複数ある。IaaS上に自前で立てている場合は、AWSのセキュリティグループ、GCP/Azureのファイアウォール規則を横断で確認する。
1 | |
出てきたグループにFortiSandboxのENIがぶら下がっていないかを突き合わせる。管理UIが全開放されていれば最優先で絞る。
手順3: 是正
- 更新: FortiGuard PSIRTの該当アドバイザリに従い、修正版へ更新する(未適用なら最優先)。
- 公開の停止: WEB UI/管理インタフェースのインターネット直接公開をやめる。管理は信頼済みIP・VPN・踏み台の背後に限定する。
- アクセス制御: セキュリティグループ/ファイアウォールで管理ポートの送信元を絞る。
- 痕跡確認: 想定外のプロセス生成や不審なHTTPリクエストのログを点検する。
クラウド別の考え方
FortiSandboxは基本的にベンダ提供の更新で直す製品だ。ディストリのパッケージ更新では対応できない。IaaS(AWS/GCP/Azure)上の仮想アプライアンスなら、更新に加えてネットワーク層での公開範囲の縮小が効く。Cloud/PaaS利用ならベンダ側の反映状況を確認する。
各クラウドでの対応状況の整理は、運用しているCVEウォッチのまとめが参考になる。
- CVE対応ウォッチ(AWS/GCP/Azure/Linuxの対応を整理・出典付き): cve.autoarticles.net
「更新」と「そもそも管理UIを外に出さない」の二段構えは、今回のFortiSandboxに限らず、未認証RCE系の脆弱性に共通して効く基本動作だ。KEV入りした脆弱性は実害が出ている証拠なので、露出点検は後回しにしない方がいい。