FileZenの脆弱性をCISAがKEVカタログに追加、JPCERT/CCも注意喚起――2021年内閣府事案と同じ構図が繰り返されている

本稿では、ソリトンシステムズのファイル転送アプライアンスFileZenに発見されたOSコマンドインジェクション脆弱性（CVE-2026-25108）について、CISAのKEV（悪用が確認された脆弱性）カタログへの追加と国内の対応状況を整理し、2021年に内閣府で発生したFileZen起因の情報漏洩事案との類似点を踏まえて、日本のIT現場が今すぐ取るべき対応と中長期的なファイル転送基盤のあり方を考察します。

事象の解説
実務視点での考察
対応チェックリスト
参考情報

事象の解説

CVE-2026-25108の概要

2026年2月24日（米国時間）、米国のCISA（Cybersecurity and Infrastructure Security Agency）は、ソリトンシステムズ製ファイル転送アプライアンスFileZenの脆弱性CVE-2026-25108を、Known Exploited Vulnerabilities（KEV）カタログに追加しました（The Hacker News、2026年2月25日）。KEVカタログは、実際の悪用が確認された脆弱性を集約したリストであり、追加は「この脆弱性が現実の攻撃で使われている」ことを示す強いシグナルです。米連邦政府機関に対しては、BOD 22-01に基づき2026年3月17日までの修正措置が義務づけられています。

本脆弱性はOSコマンドインジェクション（CWE-78）に分類され、CVSSスコアはv3.0で8.8、v4.0で8.7（いずれもHigh）です。FileZenにログイン済みのユーザーが、ログイン後の特定画面から細工されたHTTPリクエストを送信することで、アプライアンスのOS上で任意のコマンドを実行できる可能性があります。

悪用が成立するには2つの前提条件があります。

攻撃者がFileZenの有効なアカウント情報を持ちログイン可能であること — 一般ユーザー権限で十分であり、管理者権限は不要。アカウント情報の入手経路としては、パスワードの使い回し、退職者アカウントの未削除、共有アカウントの存在、パスワードスプレー攻撃（よく使われるパスワードを多数のアカウントに試す手法）などが考えられる。JPCERT/CCが「パッチ適用に加え全ユーザーのパスワード変更を検討すべき」と推奨しているのは、まさにこの経路を塞ぐためである
FileZenのウイルスチェックオプション（BitDefenderライセンスによるアンチウイルス機能）が有効であること — このオプションを購入・有効化していない環境は対象外

影響を受けるバージョンは以下の通りです（JVN#84622767）。

FileZen V5.0.0 〜 V5.0.10（物理版・仮想版とも）
FileZen V4.2.1 〜 V4.2.8（物理版・仮想版とも）

FileZen Sは影響を受けません。修正済みファームウェアはV5.0.11で、ソリトンシステムズが2026年1月13日にリリース済みです。V4.x系についてはファームウェアの提供が終了（EOL）しているため、V5.0.11への移行が必要です。

国内の対応状況：JPCERT/CCの注意喚起

JPCERT/CC（2026年2月13日、JPCERT-AT-2026-0004）は、ソリトンシステムズによる脆弱性情報の公開と同日に注意喚起を発行しています。JPCERT/CCは注意喚起の中で以下の点を指摘しています。

ソリトンシステムズは本脆弱性の悪用による被害報告を1件以上受けている
情報発行時点でも、本脆弱性の影響を受ける可能性がある製品の国内での利用を確認している
今後、脆弱性の詳細が公表されることで悪用が広がる可能性がある

つまり、パッチ（V5.0.11）は1月13日にリリース済みだったにもかかわらず、2月13日の時点で未適用の国内環境が存在しており、実際に被害が発生しているということです。

また、FileZenにはシステムディレクトリのファイル監視機能があり、ファイルが改変された場合にログに記録される可能性があります。JPCERT/CCは、痕跡確認の方法についてソリトンシステムズへ問い合わせることを推奨しています。

時系列で見る同時期のインシデント

本脆弱性の公開と同時期に、国内で注目すべきインシデントが発生しています。ワシントンホテルは2026年2月14日、同社の一部サーバーがランサムウェアに感染したと公表しました。検知日は2月13日22時で、FileZenの脆弱性公開と同日です。Help Net Security（2026年2月25日）は、CVE-2026-25108がランサムウェア攻撃に使用された可能性についての推測があると報じていますが、同時にCISAのKEVリスト自体はランサムウェアとの関連を示していないとも明記しています。ワシントンホテルの公表文にもFileZenへの言及はありません。同時期のインシデントという外形的な一致だけで製品起因と断定するのは危険であり、攻撃者が全く別の経路で侵入した可能性も含めて考える必要があります。現時点では因果関係は確認されていません。

2021年内閣府事案との類似点

FileZenの脆弱性が大規模なセキュリティインシデントに至ったのは、今回が初めてではありません。2021年4月、内閣府はFileZenの脆弱性（CVE-2020-5639およびCVE-2021-20655）を悪用された不正アクセスにより、231名分の個人情報（氏名、所属、連絡先等）が漏洩した可能性があると発表しました（内閣府公表）。内閣府の発表では、ファイル流出の事実はアクセスログが残っていないため特定できないとされています。この「ログ不在による被害範囲の特定不能」は、2021年事案における最大の教訓の一つです。

当時の問題点を整理すると以下の通りです（piyologによる詳細まとめ）。

内閣府のFileZenはV4.2.2のまま2年以上アップデートされていなかった
ソリトンシステムズが2020年12月に脆弱性を公表し緊急アップデートを呼びかけたが、内閣府への修正パッチ適用は2021年3月まで約3ヶ月を要した
不正アクセスは遅くとも2020年3月から行われており、検知までに約10ヶ月を要した
操作ログが残っておらず、実際のファイル流出の有無を特定できなかった
当時の報道では、FileZenは国内で公共系組織を中心に広く利用されていたとされている

今回のCVE-2026-25108と2021年の事案を並べると、「OSコマンドインジェクション型の脆弱性」「パッチ公開から適用までのタイムラグ中に悪用」「国内の公共・企業環境で広く利用されている製品」という構図が繰り返されていることが分かります。

実務視点での考察

パッチは1月13日にあった――「通常保守」では間に合わない

今回のタイムラインで最も注目すべきは、修正ファームウェア（V5.0.11）が1月13日にリリースされていたにもかかわらず、2月13日のJPCERT/CC注意喚起時点で未適用の環境が存在し、その間に被害が発生しているという事実です。パッチ公開から1ヶ月以上が経過しています。

これを「パッチ適用が遅い」と批判するのは簡単ですが、ファイル転送アプライアンスのパッチ適用が遅れる構造的な理由があります。FileZenのような製品は組織間のファイル交換基盤として稼働しており、パッチ適用にはサービスの停止が伴います。取引先との受け渡しスケジュールとの調整が必要で、「今すぐ止めてパッチを当てる」という判断は、IT部門だけでは完結しません。加えて、ファームウェアアップデートの検証環境を持っていない組織では、本番環境への直接適用となるため、リスク回避の心理からどうしても後回しになります。

しかし、2021年の内閣府事案でも同じ構造で被害が発生しています。5年間で同じ製品、同じ種類の脆弱性、同じ「パッチ適用タイムラグ」による被害が繰り返されているという事実は重い。ファイル転送アプライアンスのパッチ適用を「通常のIT保守サイクル」に載せたままでは、この繰り返しは止まりません。

具体的には、CISAのKEVカタログ追加やJPCERT/CCの緊急注意喚起が出た時点で、通常の変更管理プロセス（CAB審議等）を省略する「緊急変更」として扱うルールを事前に策定しておくべきです。運用SLAの目安としては、以下のような粒度が考えられます。

24時間以内：影響有無の確認（FileZenの利用有無、バージョン、ウイルスチェック設定の確認）
72時間以内：暫定緩和策の実施（接続元IPの制限強化、不要アカウントの停止、管理画面のアクセス分離、ログの外部退避）
7日以内：恒久対応の実施または更改計画の承認取得（パッチ適用、V4.x系の場合は移行計画の経営承認）

重要なのは、このSLAを「インシデント発生後に考える」のではなく、「何も起きていない今のうちに決めておく」ことです。

V4.x系のEOL問題――意思決定の順序を間違えない

今回の脆弱性でもう一つ深刻なのは、V4.x系（V4.2.1〜V4.2.8）がすでにファームウェアの提供を終了しており、パッチが提供されないという点です。JPCERT/CCも「V5.0.11にアップデートしてください」と明記していますが、これはV4.x系からのメジャーバージョン移行を意味し、単純なパッチ適用とは作業規模が根本的に異なります。設定の再構築、ユーザーアカウントの移行、取引先への接続情報変更通知、場合によってはハードウェアの交換まで含む可能性があります。

ここで重要なのは、暫定策と恒久策を混同しないことです。

まず暫定策として、ウイルスチェックオプションの無効化があります。本脆弱性はこのオプションが有効な場合にのみ悪用可能なため、無効化することで脆弱性の悪用経路を断てます。ただし、これはアンチウイルス機能を犠牲にするトレードオフであり、かつ「すでに侵害されていた場合」の対処にはなりません。無効化と並行して、侵害調査（ログの確認、不審なアカウント操作の有無）と全ユーザーのパスワード変更は必須です。また、接続元IPの制限や管理画面のネットワーク分離など、脆弱性とは独立した防御策も同時に講じるべきです。

その上で恒久策として、V5.0.11への移行またはファイル転送基盤そのものの更改を計画します。V4.x系を使い続けている組織は、今回のCISA KEV登録を「予算確保の根拠」として活用すべきです。「CISAが悪用を確認し連邦政府に修正を義務づけた脆弱性を、パッチ未提供のEOL製品で運用している」という説明は、経営層や予算権者に対して十分な説得力を持ちます。

2021年の最大の教訓は「ログがなかった」こと

2021年の内閣府事案で最も深刻だったのは、被害の全容が把握できなかったことです。内閣府は「ファイル流出の事実は、アクセスログが残っていないため特定できていない」と発表しています。つまり、侵害されたことは分かっているが、何が持ち出されたのかが分からないという状態です。

FileZenのようなアプライアンス製品は、ログの保存容量や保持期間が限られていることが多く、長期間の侵害ではログが上書きされてしまいます。さらに、攻撃者がOS上でコマンドを実行できるレベルのアクセスを得た場合、アプライアンス内のログ自体を改ざん・削除することも可能です。

今回のCVE-2026-25108でも同じ問題が起こり得ます。対策として、アプライアンス内のログだけに依存しない仕組みを構築しておく必要があります。具体的には、syslogによるログの外部転送（SIEMやログ管理サーバへの即時転送）を設定し、アプライアンス側で改ざん・削除されても外部に原本が残る構成にすること。また、ネットワーク機器側のログ（ファイアウォール、プロキシ、フロー情報）をFileZenのログと突合できるようにしておくこと。これらは今回の脆弱性対応とは別に、平時から整備しておくべき基盤です。2021年の「ログがなくて被害が特定できない」を2026年に繰り返さないために、最も投資対効果が高いのはこのログ設計の見直しです。

ファイル転送アプライアンスという製品カテゴリ自体のリスク

FileZenの問題を「ソリトンシステムズ特有の問題」として矮小化すべきではありません。ファイル転送アプライアンスという製品カテゴリ全体が、近年サイバー攻撃者の主要な標的になっています。Progress SoftwareのMOVEit Transfer（2023年、Clopランサムウェアグループによる大規模悪用）、Fortra GoAnywhere MFT（2023年）、Citrix ShareFile（2023年）など、同種の製品で重大な脆弱性が相次いでいます。

狙われる理由は明確です。組織間の境界に設置され、機密性の高いファイルが集中し、インターネットに公開された状態で運用されることが多い。攻撃者にとっては、1台を侵害するだけで大量の機密文書にアクセスでき、さらに取引先ネットワークへの横展開の足がかりにもなります。

中長期的には、専用アプライアンスによるファイル転送という運用モデル自体を見直す時期に来ているのかもしれません。クラウドストレージ（Box、SharePoint等）やゼロトラスト対応のSaaSベースのファイル共有基盤への切り替えは、パッチ適用の運用負荷を軽減し、EOL問題も解消できる選択肢です。ただし、オンプレミスのアプライアンスからの移行には、データ分類の見直し、取引先との調整、社内承認フローの変更など、技術以外のハードルも多い点は認識しておく必要があります。

FileZenは国内のファイル転送領域ではシェアもあり、実際のIT現場でも依存度が高い。だからこそ、『自社でも稼働しているが、まだ被害がないから大丈夫』という正常性バイアスが最大のリスクとなる。CISAからも警告されている以上、未対応の環境を運用する担当者は、迅速な具体的なアクションを起こす必要があるでしょう

対応チェックリスト

本脆弱性に対して、組織が今すぐ確認すべき項目を整理します。

FileZenの利用有無を確認 — IT資産台帳でFileZenの有無を確認。部門が独自に導入しているケースも想定して広めに調査
バージョンを確認 — V5.0.10以下またはV4.2.x系であれば影響あり
ウイルスチェックオプションの設定を確認 — 有効な場合に悪用が成立。パッチ適用までの暫定策として無効化も検討（ただしアンチウイルス機能喪失のトレードオフあり。無効化しても侵害調査とパスワード変更は必須）
V5.0.11へ即時アップデート — V4.x系の場合はV5.0.11への移行が必要（EOLのためパッチ提供なし）
全ユーザーのパスワード変更 — 悪用された場合、攻撃者がアカウント情報を取得している可能性があるため
ログの外部退避 — アプライアンス内ログが改ざん・削除される前に、syslog転送やSIEMへの即時転送を設定。ネットワーク機器側のログも保全
侵害痕跡の調査 — システムディレクトリのファイル監視ログを確認（詳細はソリトンシステムズに問い合わせ）。不審な認証済みHTTPリクエストの有無をWebアクセスログで確認
接続元の制限強化 — 許可IPの絞り込み、管理画面のネットワーク分離、不要アカウントの停止