またMOVEitに脆弱性。同じパターン、異なるリスク。

2026年4月30日、Progress Softwareは、数千の組織がエンタープライズファイル転送の自動化に利用しているワークフローおよびスケジューリングエンジン「MOVEit Automation」における2件の脆弱性を公表しました。National Vulnerability Database（NVD）には同日中にエントリーが掲載され、ベンダーのアドバイザリはProgress Customer Communityに投稿されました。MOVEit Automationを運用しているセキュリティチームは、現在、緊急パッチ適用のサイクルに追われています。

主なポイント

1. 2つの重大なバグ、1つの馴染み深い製品ファミリー。 Progress Softwareは2026年4月30日、MOVEit Automationに関してCVE-2026-4670（CVSS 9.8）およびCVE-2026-5174（CVSS 8.8 NIST/7.7 CNA）を公表しました。これらを組み合わせることで、攻撃者はアクセス権なしの状態から管理者権限の取得まで進行可能となります。
2. 回避策はありません。 対応には、完全インストーラーを用いてMOVEit Automation 2025.1.5、2025.0.9、または2024.1.8へアップグレードする必要があります。アップグレード中はシステムを停止する必要があります。
3. 現時点で確認された悪用事例はなし。 公表時点で、Progressは実際の悪用が確認されていないと報告しています。2023年のMOVEit Transferキャンペーンは公表の4日前に始まりました。パッチ適用までの猶予は長くなっていません。
4. これは例外ではなく、パターンです。 Cleo、CrushFTP、Wing FTP、そして今回のMOVEit Automation。マネージドファイル転送ソフトウェアは、境界に位置し、最も価値の高いデータを保持しているため、構造的な標的となっています。
5. 本質的な課題はアーキテクチャの問題。 MFTの脆弱性が増えるたびに、個別の緊急対応が必要となります。単一で強化されたシングルテナントのデータ交換プラットフォームへの統合が、状況を根本から変えます。

今回のMOVEitの主要な脆弱性は、CVE-2026-4670であり、NISTがCVSS 9.8（リモート脆弱性としては最大の深刻度）と評価したMOVEit Automationの認証バイパスです。2つ目のCVE-2026-5174は、不適切な入力検証の欠陥で、NISTはCVSS 8.8（高）、Progress（CNA）はCVSS 7.7と評価しています。いずれもサービスバックエンドのコマンドポートインターフェースに存在し、組み合わせて使用されることで、認証されていないネットワークアクセスからMOVEit Automation環境の管理者権限取得までの経路が生まれます。Progressは「悪用により不正アクセス、管理者権限の取得、データ漏洩が発生する可能性がある」と明言しています。

発見の功績は、The Hacker Newsによると、Airbus SecLabのAnaïs Gantet氏、Delphine Gourdou氏、Quentin Liddell氏、Matteo Ricordeau氏に帰属します。公表時点で実際の悪用は確認されておらず、公開されたPoC（概念実証）も存在しません。これは良いニュースですが、悪いニュースは、重大な認証前MFT脆弱性においてこの状態がどれほど長く続くかという過去の傾向です。

MOVEit Automationが狙われやすい理由

MOVEit Automation（旧MOVEit Central、さらにその前はIpswitch MOVEit Central）は、ニッチな製品ではありません。これは、組織が給与、金融取引、パートナーファイル、医療記録、エンジニアリングデータなどを自動サイクルで転送するために利用するスケジューラー兼ワークフローエンジンです。プラットフォームは自動化タスクに埋め込まれた認証情報を日常的に保存・利用しますが、これは自動化が機能する仕組みそのものです。

この特徴こそが、マネージドファイル転送がランサムウェアグループや初期アクセスブローカーの構造的な標的となった理由です。Dragos 2026 OT/ICS Cybersecurity Year in Reviewは、2024年と2025年に複数のMFTプラットフォームで同様のパターンが発生したことを記録しています。Cleo MFT（CVE-2024-50623、CVE-2024-55956）は2024年後半からCl0pにより悪用され、交通、製造、食品業界で300社以上の被害が報告されました。CrushFTPは2025年3月（CVE-2025-31161）と7月（CVE-2025-54309）に2度の攻撃を受け、Wing FTPはLuaインジェクションによるSYSTEMレベルのRCE（CVE-2025-47812）で侵害されました。Dragosの結論は明快です。ファイル転送プラットフォームは、ランサムウェアグループや初期アクセスブローカーが恐喝やアクセス再販による金銭的利益を狙って継続的に標的とする存在になっています。

2026年のMOVEitの脆弱性公表も、このパターンに当てはまりますが、必然ではありません。攻撃者の経済的動機が背景にあります。MFTは境界に位置し、価値の高いデータを保持し、広く導入されているうえ、ITチームが緊急対応でパッチを適用するとは限りません。攻撃者視点では、これは構造的に魅力的な標的です。購入者視点では、アーキテクチャの意思決定に影響を与える重要な情報です。

2023年に実際に明らかになったこと

2023年5月、ProgressはCVE-2023-34362（MOVEit TransferにおけるSQLインジェクション脆弱性）を公表しました。これはMOVEitファミリーの中でもMOVEit Automationとは異なる製品、異なる脆弱性です。数日以内に、CISAがTA505として追跡しているCl0pランサムウェアグループが、LEMURLOOTウェブシェルを通じて大規模に悪用を開始。CISAは2023年6月2日にこのCVEを既知の悪用済み脆弱性カタログに追加しました。キャンペーンが収束した時点で、2,700を超える組織が影響を受け、数千万人もの個人に被害が及んでいました。連邦裁判所で集団訴訟が統合されました。

この歴史を活用する正しい方法は、CVE-2026-4670で同じことが起こると予測することではありません。製品も脆弱性も異なります。公表時点では2026年の脆弱性が悪用されている証拠はありません。しかし、リスク評価に無関係とみなすのは誤りです。2023年の教訓は、重大な認証前MFT脆弱性は短期間で武器化されるというベースレートを示しました。Cl0pキャンペーンは2023年5月27日に開始されました。これは、Progress社の公開アドバイザリが発表される4日前のことです。公開アドバイザリの後に対応したディフェンダーは、すでに攻撃者に対して4日遅れを取っていました。

これは、現在MOVEit Automationを運用するセキュリティチームが直面している判断です。完全インストーラーでパッチを適用し、計画的な停止を受け入れ、過去のパターンが繰り返されないことを願う。より長期的な課題は、ベンダーを問わずMFTを運用している全ての組織にとって、独立したコマンドポートを境界に設けるというアーキテクチャが今も妥当かどうかです。

最新のMFTセキュリティを示すデータ

そのアーキテクチャ上の問いに対して説得力のある答えを出すには、データが必要です。Kiteworks Data Security and Compliance Risk: 2025 MFT Survey Reportによると、過去1年で59%の組織がMFT関連のセキュリティインシデントを経験しており、成熟したセキュリティプログラムを自称していたにもかかわらずです。その理由は脅威の高度化ではなく、アーキテクチャにあります。63%がMFTとSIEMやSOCを統合しておらず、脅威検知に大きな死角が生じています。62%はMFT、メール、ファイル共有、Webフォームで分断されたシステムを運用しており、それぞれが別個のポリシー、監査ログ、緊急パッチ体制となっています。

自動化の成熟度は、インシデント発生率とさらに明確に連動しています。2025年MFT調査レポートでは、MFT自動化率が50%未満の組織は71%のインシデント率を報告。逆に90～100%の自動化を実現している13%の組織（手作業ではなく戦略的コントロールとして運用）は、わずか29%でした。この差は偶然ではありません。エンドツーエンドの自動化は、緊急公表時にも耐えうるコントロールへの統合を促します。手作業プロセスは、重大なCVEが突く隙間を生み出します。

Black Kiteの2026年サードパーティ侵害レポートによるサプライチェーンの視点はさらに鋭いものです。2025年には136件のサードパーティ侵害イベントが検証され、719社の被害企業が公表されました。さらに約26,000社が非公表で影響を受けたと推定されています。公表までの中央値は73日。MOVEitのようなMFTプラットフォームが大規模に悪用された場合、多くの下流組織は平均2カ月以上、自身が影響を受けたことに気付けません。購入者がコントロールできるのは上流です。攻撃対象領域が最小かつ監査耐性が最も高いデータ交換インフラを選ぶことが重要です。

2026年の脅威環境

2026年のMOVEit脆弱性は、静かな脅威環境で発生したわけではありません。CrowdStrike 2026 Global Threat Reportは、AIを活用した攻撃者活動が前年比89%増加、初期アクセスから水平展開までの平均eCrimeブレイクアウトタイムが29分、検知の82%がマルウェア非依存型に分類されていると報告しています。つまり、攻撃者はより高速に動き、シグネチャではなくIDや設定の弱点を突き、AIで偵察やソーシャルエンジニアリングを加速させています。

一方、データ管理体制は追いついていません。2026 Thales Data Threat Reportによれば、自社データの保存場所を完全に把握している組織はわずか33%。3分の2の組織が機密データの所在を把握できていなければ、そのデータを移動するプラットフォームが侵害された際に、影響範囲を特定できません。WEF Global Cybersecurity Outlook 2026も、経営層の視点から同様の傾向を示しています。サプライチェーンの混乱はCISOのサイバー懸念事項で2位に浮上し、CEOの懸念リストでも上昇中。AI脆弱性は高レジリエンス組織のCEOにとってトップ5入りしました。

これらのシグナルを2026年MOVEit公表と重ね合わせると、セキュリティチームへの示唆は明白です。パッチサイクルは短縮し、攻撃者の動きは加速し、データの可視性は改善せず、MFTソフトウェアの構造的リスク集中も変わっていません。パッチは脆弱性を修正しますが、アーキテクチャ上の露出は修正できません。

Kiteworksによるアーキテクチャの選択肢

KiteworksはMOVEit脆弱性公表を利用しているのではなく、購入者が検討すべきアーキテクチャの選択肢を提示しています。その提案は構造的です。マネージドファイル転送、セキュアメール、ファイル共有、SFTP、Webフォーム、AIデータ連携を、単一の強化された仮想アプライアンス上に統合し、1つのポリシーエンジン、1つの統合監査ログ、1セットのセキュリティコントロールで管理するというものです。このアーキテクチャは3つの観点で状況を変えます。

第一に、プラットフォームは顧客のインフラ層ではなく、アプライアンスレベルで強化されています。ネットワークファイアウォール、Webアプリケーションファイアウォール、侵入検知はKiteworks側で維持され、顧客側のセキュリティ設定依存度がMFT製品とは異なります。多層防御モデルは実証可能です。Log4Shellが業界でCVSS 10と評価された際も、Kiteworksアーキテクチャ内では多層コントロールにより影響がCVSS 4に抑えられました。これはKiteworksが脆弱性に無縁という主張ではなく、脆弱性が発生した際にアーキテクチャが露出を制限するという主張です。

第二に、Kiteworksの導入はすべてシングルテナントです。データベース、ファイルシステム、実行環境は顧客間で共有されません。マルチテナントクラウドサービスで発生するクロステナント攻撃は、存在しない境界を越えることができません。金融取引、医療記録、防衛データ、パートナー認証情報など規制対象データ交換において、シングルテナントの分離は構造的なコントロールであり、設定オプションではありません。

第三に、統合によりポイントソリューションを置き換えます。MFTは1つのチャネルに過ぎません。実際の企業は、メール、Webフォーム、ファイル共有、SFTP、API、そしてAIアシスタントやエージェントを通じて機密データをやり取りしています。各チャネルが異なるベンダー、異なるパッチサイクルで運用されていれば、脆弱性公表ごとに個別の緊急対応が必要です。1つのプラットフォームと1つの監査ログで統合すれば、攻撃対象領域も運用負荷も削減できます。これが、繰り返されるMFTのCVEサイクルへのアーキテクチャ的な解答です。

今週・今四半期・今年やるべきこと

理想論ではなく、具体的なアクションです。まず、MOVEit Automationを運用している場合は、今すぐパッチを適用してください。Progressのアドバイザリに従い、完全インストーラーで2025.1.5、2025.0.9、または2024.1.8へアップグレードしてください。回避策も近道もありません。ダウンタイムを計画し、影響を受ける事業部門に周知し、ベンダーのアドバイザリーが求めるスケジュール通りにアップグレードを完了してください。アップグレード後は、[ヘルプ] > [バージョン情報]でバージョン状況を確認してください。

次に、MFTの露出状況を監査しましょう。すべてのMOVEit Automationインスタンスを特定してください（在庫内に旧MOVEit CentralやIpswitch MOVEit Centralの名称が残っているものも含む）。レガシー環境は新規構築ではなく現状のままアップグレードされることが多く、パッチサイクルから漏れるコンポーネントが残りがちです。長期間稼働している自動化環境こそ、管理されていないインスタンスが潜みやすい場所です。

三番目に、サービスバックエンドコマンドポートインターフェースのネットワーク露出を制限しましょう。これらはインターネットから直接アクセスできないようにすべきです。アクセスが既知の認可済みシステムに限定されていることを確認し、設定レビューではなくネットワークスキャンで制限を検証してください。Kiteworks 2025 MFT調査レポートによると、63%の組織がMFTとSIEMやSOCを統合していません。つまり、露出状況が変化しても、多くのチームは監視で気付けません。

四番目に、公表からパッチ適用までの期間の監査ログを確認しましょう。予期しない権限変更、新規管理者アカウント、バックエンドサービスインターフェースに紐づく異常なアクティビティ、ドキュメント化されたワークフローと一致しないファイル転送などを探します。2026年Black Kiteサードパーティ侵害レポートによれば、サードパーティ侵害の公表までの中央値は73日。自社環境での発見は、他者から知らされるのを待つよりも迅速です。

五番目に、今四半期中にアーキテクチャレビューを計画しましょう。問うべきはMOVEitをパッチするかどうかではなく、現行アーキテクチャであと何回MFTクラスの脆弱性サイクルに耐えられるかです。Kiteworks 2025 MFT調査レポートによれば、62%の組織がMFT、メール、ファイル共有、Webフォームで分断されたシステムを運用しています。それぞれが潜在的な緊急対応体制となっています。

六番目に、法務・コンプライアンス部門と議論を始めましょう。CVEがNVDに掲載されると、既知の脆弱性の修正を義務付けるコンプライアンスフレームワーク（HIPAA、CMMC、SEC開示、州の漏洩法など）に対して組織は「建設的な認識」を持ったとみなされます。公表の瞬間に発見体制が変わります。パッチ適用のタイムライン、監査レビュー、アーキテクチャ判断を記録してください。対応の正当性は証拠の記録に依存し、パッチの速さだけでは十分ではありません。

最後の問いは、「MOVEit Automationが実際に悪用されるかどうか」ではありません。されるかもしれませんし、されないかもしれません。すべての組織がMFTソフトウェアを使って機密データをやり取りする際に問うべき本質的な疑問は、次に発生する重大な情報開示が混乱を招くものになるのか、それとも単なる注釈で済むのかということです。決めるのはアーキテクチャです。