結論：マルウェアを「検査する箱」が乗っ取られると、検査をすり抜けた以上の被害になる。5.0.6／4.4.9へ即時更新を
Fortinetは6月9日、マルウェア解析アプライアンス FortiSandbox のOSコマンドインジェクション脆弱性 CVE-2026-25089（アドバイザリ番号FG-IR-26-141） を公表した。CVSSベクトルは 認証不要（PR:N）・ネットワーク経由・ユーザー操作不要 で、機密性・完全性・可用性すべてに高い影響（C:H/I:H/A:H）。つまり未認証の攻撃者にOSコマンドを実行され得る、事実上の認証不要RCEである。アドバイザリ公表時点で悪用は確認されていない。
影響を受けるのは FortiSandbox 5.0.0〜5.0.5 と 4.4.0〜4.4.8（Cloud/PaaS版は5.0.4〜5.0.5）。修正版は 5.0.6以降／4.4.9以降 だ。アドバイザリに回避策の記載はなく、対応はアップグレード一択である。
FortiGateを入れている中堅・中小は多いが、その検査強化のために併設したFortiSandboxは「入れた後に触らない」装置になりがちだ。守るための箱が、攻撃者の足場になる——今回はその典型例である。
押さえるべき1点：セキュリティ製品はOSコマンドレベルの高い権限で動き、社内トラフィックの要所に置かれる。だからこそ、乗っ取られたときの被害は一般のサーバより大きい。「セキュリティ製品自体のパッチ運用」を業務システムと同格以上で扱うべきだ。
EMERGENCY RESPONSE
この脆弱性、貴社システムは影響を受けますか？
影響範囲の一次評価を無料で実施。致命的脆弱性は24時間以内にアラートし、パッチ適用・恒久対応まで伴走します。
影響バージョンと修正版
| 製品 | 影響バージョン | 対応 |
|---|---|---|
| FortiSandbox 5.0 | 5.0.0〜5.0.5 | 5.0.6以降へ更新 |
| FortiSandbox 4.4 | 4.4.0〜4.4.8 | 4.4.9以降へ更新 |
| FortiSandbox Cloud 5.0 | 5.0.4〜5.0.5 | 5.0.6以降へ更新 |
| FortiSandbox PaaS 5.0 | 5.0.4〜5.0.5 | 5.0.6以降へ更新 |
-
脆弱性種別：OSコマンドで使用される特殊要素の不適切な無害化（CWE-78）
-
公表日：2026年6月9日
-
悪用：公表時点で確認なし
-
回避策：記載なし（アップグレードのみ）
CVSSが「9.1」と「9.8」で割れている理由
報道や脆弱性データベースによって9.8と表記される場合があるが、Fortinetのアドバイザリ原文が公表しているスコアは9.1である。原文のベクトルには基本評価（AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H）に加えて**現状評価（Temporal）指標（E:F/RL:O/RC:C）**が含まれており、9.1はこれを織り込んだ値だ。基本評価のみのベクトルは9.8に相当するため、二次情報では9.8と書かれることがある。本記事はアドバイザリ原文の公表値9.1を採用する。いずれにせよCritical級であり、対応の優先度は変わらない。
なぜ「守る箱」が狙われるのか
セキュリティアプライアンスは、①高い権限で動く、②社内ネットワークの要所に置かれる、③検査対象として外部からファイルや通信が流れ込む、という攻撃者にとって理想的な条件が揃っている。今年に入ってからもFortiClient EMSのゼロデイCVE-2026-35616やCheck Point VPNの認証バイパス悪用など、セキュリティ製品・境界機器そのものを突く事案が続いている。
特にFortiSandboxのような「導入後に存在感が薄れる」製品は、管理画面の露出やバージョンの放置が起きやすい。FortiGateは更新しているのにFortiSandboxは数世代前のまま、という非対称が今回の急所になる。
確認手順4ステップ
-
利用有無の確認：FortiSandbox（アプライアンス／VM／Cloud／PaaS）を使っているか。FortiGate導入時にセットで提案されていないか、構成書と保守契約を確認する
-
バージョン確認：管理画面でバージョンを確認し、5.0.0〜5.0.5／4.4.0〜4.4.8に該当するか判定する
-
更新の実施：該当するなら5.0.6／4.4.9以降へ定例を待たず更新する。回避策はないため、更新以外に塞ぐ手段がない
-
露出の点検：管理インターフェースがインターネットや不要なセグメントから到達可能になっていないかを併せて確認し、管理アクセスを制限する
チェックの勘所：手順4は今回の脆弱性に限らず効く恒久対策だ。認証不要の脆弱性は「攻撃者から届くかどうか」が被害の分かれ目であり、管理面の到達範囲を絞っておけば次のCVEでも時間を稼げる。
FortiSandbox利用企業が追加で見るべき範囲
FortiSandboxはマルウェア解析のために不審ファイルや通信を受け取る製品であり、通常の業務サーバよりも危険な入力を扱う。したがって、単にバージョンを上げるだけでなく、管理画面・API・解析投入経路がどのネットワークから到達可能かを確認する必要がある。
公表値のCVSSが9.1か9.8かに注目しすぎると、対応判断を誤る。実務上の判断材料は、認証不要、ネットワーク経由、ユーザー操作不要、OSコマンド実行の可能性という条件である。この4点が揃うなら、悪用公表前でも緊急対応として扱うべきだ。
よくある質問（FAQ）
Q. 悪用は確認されているのか？ A. アドバイザリ公表時点で悪用の確認はない。ただし原文のベクトルはエクスプロイトの存在を前提とする現状評価（E:F）を含んでおり、Fortinet製品の脆弱性は公表後に悪用が始まる例が繰り返されてきた。「悪用前の今」が最も安く対応できるタイミングだ。
Q. CVSSは9.1と9.8のどちらが正しいのか？ A. アドバイザリ原文の公表値は9.1（Temporal指標込み）で、基本評価のみなら9.8に相当する。どちらを採るかの違いであり、深刻度がCritical級である点は同じだ。
Q. FortiGateしか使っていない場合は関係ないか？ A. 本件の対象はFortiSandboxのみだ。ただしFortinet製品全般でアドバイザリは毎月のように出るため、自社で使っている製品の一覧とバージョンを把握し、PSIRT情報を定点観測する運用を整えることを勧める。
社内で今日確認する実務チェック
この記事のテーマを自社に当てはめるときは、次の順で確認する。第一に、対象製品・対象バージョン・対象サービスが資産台帳に載っているか。第二に、インターネットや不要な社内セグメントから到達できないか。第三に、更新・緩和・監視の担当者と期限が明確か。第四に、委託先やクラウド運用先が関係する場合、回答を口頭ではなくチケットやメールで記録しているか。第五に、対応後にバージョン・設定・ログで完了を確認したかである。
脆弱性対応で最も危険なのは、「使っているか分からない」「担当が分からない」「ベンダーに任せているはず」という状態だ。今回の記事を読んだ時点で対象有無を即答できないなら、それ自体が改善テーマである。個別のパッチ適用だけでなく、資産台帳、脆弱性通知の受信経路、緊急対応の承認権限まで点検したい。
GXOへ相談する前に整理しておくと早い情報
相談前には、対象製品名、バージョン、設置場所、外部公開の有無、管理者、保守契約、更新可能な時間帯、過去の障害履歴を分かる範囲でまとめる。すべて揃っていなくてもよいが、「分からない項目」が多いほど、最初の支援はパッチ作業ではなく棚卸しと露出確認から始めるべきである。
30日で整える脆弱性対応ロードマップ
初日から3日目までは、対象有無の確認と暫定緩和に集中する。資産台帳、EDR/MDM、クラウド管理画面、保守ベンダーへの照会を使って、対象製品がどこにあるかを洗い出す。対象が見つかった場合は、外部公開の停止、アクセス制限、管理画面のIP制限、監視強化など、更新前にできる緩和策を先に入れる。
4日目から10日目までは、更新・設定変更・影響確認を進める。業務影響が大きい製品では、検証環境で更新手順を確認し、失敗時の切り戻し手順を用意する。更新後はバージョン表示だけでなく、実際に脆弱な経路が閉じているか、ログに不審なアクセスが残っていないかを確認する。
11日目から30日目までは、再発防止に使う。通知を誰が受けるか、KEVやJPCERT/CCなどの情報をどう優先度付けするか、休日・夜間の緊急判断を誰が承認するかを決める。今回のような高リスク通知に対して、次回は「対象有無を24時間以内に答えられる」状態を目標にする。
よくある失敗パターン
第一の失敗は、CVE番号やCVSSだけを見て、対象資産の有無を確認しないことだ。スコアが高くても自社に対象がなければ対応は不要であり、逆にスコアが中程度でもKEV登録や悪用確認があれば最優先になる。優先順位は、CVSS、悪用状況、外部公開、権限条件、業務影響を組み合わせて決める。
第二の失敗は、更新完了を「ベンダーに依頼した」で止めることだ。更新後のバージョン確認、到達制限、ログ確認、再起動状態、冗長系への反映まで確認しなければ完了とは言えない。特にアプライアンスや管理基盤では、片系だけ更新されてもう片系が古いまま残ることがある。
第三の失敗は、今回だけの緊急対応で終わることだ。脆弱性情報は毎月出る。対応のたびに担当者探しから始まる組織は、次回も同じ遅れを繰り返す。今回の対応記録を使い、対象確認テンプレート、判断フロー、連絡先一覧、夜間休日の承認ルールまで更新することが重要である。
成果物として残すべきもの
公開記事を読んで終わらせず、社内には少なくとも4つの成果物を残したい。対象有無確認表、対応判断メモ、更新・緩和作業の証跡、再発防止タスクである。これらが残っていれば、監査や事故後説明でも「いつ、誰が、何を根拠に判断したか」を示せる。
また、委託先が関係する場合は、委託先回答をそのまま保存するだけでなく、自社として受け入れた判断も記録する。セキュリティ運用では、作業を委託できても説明責任は委託できない。
判断表：読むだけで終わらせないための整理
| 確認項目 | 見るべきポイント | NGサイン |
|---|---|---|
| 対象範囲 | どの部門・システム・データ・端末が関係するか | 「たぶん関係ない」で止まる |
| 責任者 | 判断者・作業者・承認者が分かれているか | ベンダー任せ、部門任せになっている |
| 期限 | いつまでに何を終えるか | 次回定例、落ち着いたら、など曖昧 |
| 証跡 | 判断根拠と作業結果を残せるか | 口頭確認だけで記録がない |
| 次の一手 | 今回の対応を仕組みに変えるか | 単発対応で終わる |
この表を埋めると、記事の内容を「読んだ情報」から「社内で動かすタスク」に変えられる。特に重要なのはNGサインである。NGサインが1つでも出る場合、問題は個別ニュースではなく、社内の判断プロセスにある。
公開情報は日々更新されるため、記事本文の数値や期限をそのまま固定値として扱うのではなく、一次情報の最新版、社内の対象有無、実施記録をセットで確認する。これにより、速報記事を一過性の話題で終わらせず、監査・稟議・改善計画に使える材料へ変換できる。
いつGXOに相談すべきか
-
セキュリティ製品を含む自社機器の一覧とバージョンを即答できない
-
ベンダー任せの構成で、アドバイザリへの該当判定を自社で検証できない
-
UTM・サンドボックス・EDRを入れたまま数年経ち、構成と設定の妥当性を第三者に点検してほしい
GXOは脆弱性診断によるセキュリティ機器を含む構成・露出の棚卸しと、セキュリティ顧問によるアドバイザリ監視・パッチ運用の体制づくりを支援している。→ Fortinet製品の脆弱性対応の相談はこちら
関連記事
編集部注：公開後の更新方針
本記事は速報性のある公開情報をもとに、GXOの商談領域であるシステム開発、AI導入、セキュリティ、レガシー刷新、データ基盤構築の観点へ翻訳したものである。公開後に一次情報の更新、ベンダー側の追記、制度要件の変更、悪用状況の変化が確認された場合は、本文・参考資料・CTAの導線を更新する。
読者が実務で使う場合は、記事の数値や期限を固定値として扱うのではなく、必ず一次情報と自社環境を突き合わせることが重要である。特に、契約条件、対象バージョン、制度要件、提供リージョン、価格、悪用状況は短期間で変わり得る。この記事の役割は、最新情報を自社の判断項目へ変換することであり、最終判断は一次情報と社内の対象有無確認にもとづいて行う。
参考資料
本記事は2026年6月12日時点の公開情報をもとに作成。CVSSスコアはFortinetアドバイザリ原文の公表値（9.1・Temporal指標込み）を採用した。影響バージョン・悪用状況は更新される可能性があるため、FortiGuard PSIRTの一次情報の最新版を必ず確認すること。
セキュリティ製品の脆弱性、「該当するか分からない」で止まっていませんか
UTM・サンドボックス・EDRなどセキュリティ機器を含む構成の棚卸しと該当判定、管理面の露出点検、パッチ運用の体制づくりまで支援します。ベンダー回答の妥当性チェックだけの相談にも対応します。
※ 営業電話はしません | オンライン対応可 | 構成資料がなくても相談可能