All-in-One WP Migrationの脆弱性（CVE-2026-19949）とは｜影響範囲と対処法を解説

WordPressの定番プラグイン「All-in-One WP Migration and Backup」に、深刻な脆弱性が見つかったそうです。

このプラグインのインストール数は500万件以上。

内容としては、サイトを丸ごと乗っ取られる可能性があるものです。

先に結論だけ書きます。

今すぐやること
①プラグインを7.110以降に更新する
②更新が終わるまで、バックアップの復元をしない
③すでに復元した心当たりがあるなら、点検する

2つ目が特に重要です。この脆弱性は「復元」の操作が引き金になります。

この記事では、何が起きているのか、自分のサイトが対象かの確認方法、そして具体的に何をすべきかを順に解説します。

なお本記事は2026年9月8日時点で確認できた公開情報にもとづいています。
状況は変わる可能性があるため、対応の際は記事末尾の一次情報もあわせて確認してください。

何が起きたのか

9月2日ごろ、WordPressで有名なバックアッププラグインである、「All-in-One WP Migration and Backup」から重大な脆弱性が発見されたと報じられました。

この脆弱性を悪用されると、認証されていない遠隔の攻撃者に機密情報を窃取される可能性があり、

この攻撃に成功した場合、RCE:（Remote Code Execution)、リモートからの操作も可能と懸念されています。

というわけでまずは脆弱性情報を整理してみます。

項目	内容
対象プラグイン	All-in-One WP Migration and Backup
CVE番号	CVE-2026-19949
深刻度	CVSS 8.8（重要）
脆弱性の種類	SQLインジェクション（CWE-89）
影響を受けるバージョン	7.109以前のすべて
修正済みバージョン	7.110（2026年8月20日リリース）
報告元	WordPressセキュリティ企業のDefiant（Wordfence）

修正版そのものは8月20日に出ています。

にもかかわらず9月に入って大きく報じられたのは、更新が進んでいないからです。

9月初旬の時点で更新済みのサイトは3割強にとどまり、300万件以上が古いバージョンのまま残っていると報じられました。

そして、攻撃手法の詳細もすでに公開されています。

この脆弱性の何が特殊なのか

今回いちばん押さえてほしいのは、攻撃の引き金を引くのが管理者自身だという点です。

公開された情報によると、これは第二次SQLインジェクションと呼ばれるタイプの脆弱性です。

攻撃者が仕込んだ時点では何も起きません。

データベースの中で静かに眠り、管理者がバックアップを復元した瞬間に動き出します。

つまり「サイトを守るための操作」が、そのまま攻撃の発火点になるということです。

だからこそ、更新が終わるまで復元してはいけないという順序が重要になります。

トラブルが起きて慌てて復元する、という流れがもっとも危険なパターンです。

攻撃の流れ

報じられている流れを、順を追って整理します。

1. 仕込み：ログインしていない第三者が、公開記事にトラックバックを送る形で不正なSQLをサイト内に保存させる
2. 待機：この時点では何も起きない。データベースの中で眠ったままになる
3. 発火：管理者がこのプラグインでバックアップを復元すると、保存されていた内容がSQLとして実行される
4. 鍵の窃取：復元処理で使われる秘密鍵がコメントに書き出され、攻撃者がコメントAPI経由で取得する
5. 乗っ取り：その鍵を使って認証を回避し、細工したアーカイブを復元させて、サーバー上に任意のコードを設置する

最終的にはサーバー上で任意のコードを実行できる状態、すなわち完全な乗っ取りに至ります。

攻撃者側にログイン情報は必要ありません。

必要なのは「公開記事があること」と「管理者がいつか復元すること」だけです。

自分のサイトが対象かを確認する

確認は1分で終わります。

1. WordPress管理画面にログインする
2. 左メニューの「プラグイン」→「インストール済みプラグイン」を開く
3. 「All-in-One WP Migration and Backup」を探す
4. プラグイン名の下に表示されているバージョン番号を確認する

状態	判定
7.110以降	対応済み。このまま使って問題ない
7.109以前	対象。すぐに更新が必要
インストールしていない	この脆弱性の影響は受けない
停止中だがインストールされている	使わないなら削除しておくのが安全

停止中のプラグインについては、この脆弱性が復元処理で発火する性質上、停止したまま使わなければ復元も行われません。

ただし将来また有効化する可能性を考えると、更新するか削除するかをはっきり決めておくべきです。

今すぐやるべきこと

優先順位の高いものから並べます。

1. 7.110以降に更新する

管理画面のプラグイン一覧から「更新」を実行するだけです。

ここで多くの人が迷うのが、「更新前にバックアップを取るべきでは？」という点だと思います。

結論としては、バックアップの取得は行って問題ありません。

今回の脆弱性が発火するのは復元のときであって、書き出しのときではないためです。

危険なのは「古いバージョンのまま復元すること」なので、順序としてはバックアップを取る → 更新する → 必要なら復元するとなります。

更新作業そのものの進め方に不安がある方は、こちらの記事も参考にしてください。

2. 更新が終わるまで復元しない

繰り返しになりますが、ここが今回の肝です。

サイトに何か不具合が起きていて、これから復元しようとしていた方は、先に更新を済ませてください。

3. 使っていないなら削除する

「昔サイトを移設したときに入れて、そのまま」という状態のサイトは非常に多いはずです。

今後使う予定がないなら、更新するより削除してしまうほうが確実です。

使っていないプラグインは、それ自体が将来の攻撃対象になります。

すでに復元してしまった場合の点検

8月20日以降、古いバージョンのままバックアップを復元した心当たりがある場合は、念のため点検してください。

ただし先に正直にお伝えしておくと、「被害がなかった」と完全に言い切ることは、専門家でも簡単ではありません。

以下は、素人でも確認できる範囲のチェックリストとして読んでください。

見覚えのない管理者ユーザーがいないか

「ユーザー」の一覧を開き、権限が「管理者」になっているアカウントをすべて確認します。

サイト乗っ取りでもっとも典型的なのが、この管理者アカウントの追加です。

見覚えのないプラグイン・テーマ・ファイルがないか

プラグイン一覧とテーマ一覧に、入れた覚えのないものがないか確認します。

今回の攻撃ではmu-pluginsというディレクトリにコードを置く手口が報じられています。

ここは管理画面のプラグイン一覧に表示されず、自動的に読み込まれる特殊な場所です。

FTPやサーバーのファイルマネージャーでwp-content/mu-plugins/を開き、身に覚えのないファイルがないか確認してください。

そもそもこのディレクトリを作った覚えがないのに存在している場合は、特に注意が必要です。

コメント欄に不審なトラックバックがないか

攻撃の入り口はトラックバックです。

コメント一覧を開き、承認待ちやスパム扱いのものも含めて、意味のわからない文字列を含む投稿がないか見てください。

なお、トラックバックやピンバックを使っていないサイトであれば、設定でオフにしておくのは一般的な予防策として有効です。

「設定」→「ディスカッション」から変更できます。

スキャンとパスワードの変更

セキュリティ系プラグインでマルウェアスキャンを実行します。

そのうえで、全ユーザーのパスワード変更と、wp-config.phpの認証キー（ソルト）の再発行を行っておくと安全です。

認証キーを入れ替えると、既存のログインセッションがすべて無効になります。

不審な点が見つかった場合や、判断に迷う場合は、自力で消そうとせず専門業者やサーバー会社に相談してください。

中途半端に削除すると、侵入経路の痕跡だけが消えて状況が分からなくなります。

このプラグインは使い続けていいのか

結論から言えば、更新して使い続けて問題ありません。

今回は開発元が修正版をすでにリリースしています。

脆弱性が見つかること自体は、利用者の多いソフトウェアであれば避けられません。

むしろ判断材料にすべきなのは、報告を受けてから修正版を出すまでの速さと、その後の情報公開の姿勢です。

本当に危険なのは、放置されて更新の止まったプラグインのほうです。

今回の件で問題だったのは、プラグインそのものよりも修正版が出て2週間以上たっても、6割以上のサイトが更新していなかったという運用側の状況でした。

同じことを繰り返さないために

プラグインの自動更新をオンにする

プラグイン一覧の右端にある「自動更新を有効化」をクリックするだけです。

自動更新には「意図しないタイミングで見た目が崩れる」というリスクもありますが、今回のようなケースでは自動更新がそのまま防御になります。

デザインに直接関わらない機能系のプラグインは、オンにしておく価値が高いと考えています。

使っていないプラグインを棚卸しする

停止しているだけのプラグインはファイルとして残り続けます。

年に一度でいいので、使っていないものを削除する日を決めておくと安全です。

脆弱性の情報が入ってくる状態を作る

今回のように、修正版が出ていても知らなければ意味がありません。

セキュリティ企業のブログを購読する、セキュリティプラグインの通知を受け取るなど、情報が向こうから届く仕組みを作っておくことが実質的な対策になります。

修正前の脆弱性を突く攻撃については、こちらの記事もあわせてどうぞ。

まとめ

All-in-One WP Migration and Backupの7.109以前には、サイトの乗っ取りにつながる深刻な脆弱性があります。

修正版の7.110はすでに公開されているので、やるべきことは更新する、それだけです。

ただし順序を守ってください。更新が終わるまで、バックアップの復元をしないこと。

この脆弱性は復元の操作で発火するため、慌てて復元すると自分で引き金を引くことになります。

そして今回の件の教訓は、脆弱性そのものよりも「修正版が出ていても、更新しなければ意味がない」という一点に尽きます。

この記事を読み終えたら、まず管理画面を開いてバージョンを確認してみてください。

よくある質問

プラグインを停止していれば安全ですか？

停止したまま復元操作を行わないのであれば、この脆弱性が発火することはありません。ただし停止中もファイルはサーバー上に残っています。今後使う予定がないなら、削除してしまうほうが確実です。

今からバックアップを取っても大丈夫ですか？

バックアップの取得（書き出し）は問題ありません。今回の脆弱性が発火するのは復元のときです。バックアップを取ってから更新し、復元が必要な場合は更新後に行う、という順序で進めてください。

更新すれば、それまでに仕込まれたものも無効になりますか？

更新後は、仕込まれた内容が復元時にSQLとして実行されることはなくなります。ただし、更新前にすでに復元を行っていた場合は、その時点で攻撃が成立している可能性があります。心当たりがあるなら、記事内の点検リストを確認してください。

実際に攻撃された事例は報告されていますか？

本記事の作成時点で確認できた情報源には、実際の悪用が確認されたという明確な記載はありませんでした。ただし攻撃手法の詳細はすでに公開されており、未更新のサイトが300万件以上残っているとされています。悪用がないという保証にはならないため、更新は先延ばしにしないでください。

自動更新をオンにしていれば大丈夫でしたか？

今回のケースでは、自動更新が有効なら8月20日の修正版が適用され、対策済みの状態になっていたはずです。デザインに直接関わらない機能系のプラグインは、自動更新をオンにしておく価値が高いと言えます。

このプラグインはもう使わないほうがいいですか？

更新したうえで使い続けて問題ありません。利用者の多いソフトウェアで脆弱性が見つかること自体は避けられず、今回は修正版がすでに提供されています。より注意すべきなのは、長期間更新されていない放置状態のプラグインのほうです。

参考リンク

• Wordfence「5 Million WordPress Sites Affected by SQL Injection Vulnerability in All-in-One WP Migration and Backup WordPress Plugin」
• SecurityWeek「Over 3 Million WordPress Sites Affected by Migration Plugin Vulnerability」
• SentinelOne Vulnerability Database「CVE-2026-19949」
• WordPress.org「All-in-One WP Migration and Backup」プラグインページ