バックアップ復元が乗っ取りの引き金に、All-in-One WP Migrationを7.110へ

2026年9月2日時点で、WordPress向けプラグイン「All-in-One WP Migration and Backup」の7.109以前には、認証されていない攻撃者が保存させたデータを管理者のバックアップ復元操作がSQLとして実行し、サイト乗っ取りへ進み得る脆弱性CVE-2026-19949が確認されている。ServMaskが修正版7.110を8月20日に公開したことと、影響範囲、復元が発火条件になる攻撃経路は、9月2日のBleepingComputer報道 でも確認できる。

7.109以前を使っている管理者は、まずエクスポート済みアーカイブのインポートや復元を止め、復元先を含む全環境を7.110以降へ更新する必要がある。攻撃データはトラックバックとして保存された時点では作動せず、その後に脆弱な版でサイトをエクスポートし、アーカイブをインポートしたときに実行されるため、通常の復旧作業が乗っ取りの引き金になり得る。

7.109以前では、保存された入力が復元時にSQLへ変わる

CVE-2026-19949は、入力を保存する処理と実行につながる処理が分かれたセカンドオーダーSQLインジェクションで、CVSS評価は8.8である。Wordfenceの技術解析 によると、公開投稿がPingを受け付けている場合、未認証の攻撃者は末尾にバックスラッシュを付けたブログ名と細工したURLを含む2件のトラックバックを送り、その値をWordPressのコメントテーブルへ保存させられる。

攻撃が成立するには、そのデータが存在するサイトを管理者がエクスポートし、続いて脆弱な版でインポートする必要がある。復元中にプラグインがSQL内のURLやテーブル接頭辞を書き換える際、引用符とバックスラッシュの境界を誤って解釈し、コメント内の入力を実行可能なSQLへ変えてしまう。

SQLが実行されると、プラグインのインポート処理を保護する秘密鍵「ai1wm_secret_key」が承認済みの公開コメントへ書き出される可能性がある。攻撃者がその値を取得すると、悪意あるMust-Useプラグインを含む.wpressアーカイブをインポートし、次のページ要求でコードを実行してサイトを掌握する経路が生じる。

復元を止め、全環境を7.110以降へ更新する

対応の起点は、脆弱なコードで復元処理を始めないことだ。本番サイトだけでなく、バックアップを戻すステージング環境、移行先、災害復旧用環境も対象にし、インポートを再開する前に版をそろえる。

1. 進行中または予約済みのインポート、復元、移行ジョブを停止する。
2. WordPressのプラグイン一覧や管理用CLIで、各環境のインストール済みバージョンを確認する。
3. 7.109以前なら7.110以降へ更新し、更新できない環境ではプラグインを無効のままにして復元を保留する。
4. 配布用イメージ、複製したステージング環境、長期停止中のサイトにも旧コードが残っていないか確認する。

WordPress.orgの公式変更履歴 は7.110を修正版として掲載し、末尾がバックスラッシュの値に対する検索・置換処理を修正したと記している。プラグインを無効化している間は攻撃面が狭まるが、古い版を再び有効化して復元すれば保存済みデータが処理されるため、無効化は更新の代わりにならない。

復元前にトラックバックと旧アーカイブを照合する

旧版で作成したアーカイブは、出所が正規であるだけでは安全と断定できない。管理者自身が書き出したファイルでも、その前に細工されたトラックバックがサイトへ保存されていれば、攻撃用の値を含み得るからだ。ただし7.110は問題の検索・置換処理を修正しており、旧アーカイブの存在だけで侵害済みと判断する必要はない。

確認時はアーカイブの作成日時、作成元、復元履歴を記録し、原本を変更せず検査用コピーを隔離する。バックアップ取得前のコメントとトラックバックを調べ、投稿者名の末尾に不自然なバックスラッシュがあるレコード、通常のトラックバック先に見えないURL、近い時刻に組み合わせて届いた不審な2件を優先して確認する。

不審なレコードを見つけても、調査前に本番データから削除すると証跡を失う。まずデータベース、Webサーバー、WAFのログを保全し、同じデータを含む可能性があるバックアップ世代とステージング環境を特定する。トラックバックを停止する措置は新規入力の抑制にはなるが、すでに保存されたレコードや作成済みアーカイブには作用しない。

旧版で復元済みなら管理者とMUプラグインを調べる

脆弱な版で、攻撃データの保存後にエクスポートとインポートを行った可能性がある場合、7.110への更新だけで調査は終わらない。秘密鍵の露出や悪意あるアーカイブの投入が更新前に起きている可能性を考え、復元時刻を軸にサイトの変更を追う。

• 作成日時、メールアドレス、権限に心当たりのない管理者アカウントがないか確認する。
• wp-content/mu-plugins配下を既知の正規ファイル一覧と照合し、復元後に追加または変更されたPHPファイルを調べる。
• 公開コメントとREST APIへの参照、All-in-One WP Migrationのインポート処理へのアクセスをログで確認する。
• 侵害が疑われる場合はサイトを隔離し、WordPressの認証キー、管理者認証情報、データベースや連携サービスの資格情報について影響範囲を評価し、必要なものを更新する。

Must-Useプラグインは通常のプラグインとは別のディレクトリから自動的に読み込まれるため、管理画面の通常一覧だけでは点検が不十分になる。未知のファイルや管理者を削除する前にコピーとログを保全し、それらを使った設定変更、ファイル操作、認証の時系列を確認する必要がある。

WAFは補助策、更新の代替にはならない

Wordfenceは有料版の利用者向けに2026年8月16日に防御ルールを配布し、無料版には同じルールを9月15日に提供するとしている。WAFは既知の攻撃入力を遮断する防御層だが、プラグイン本体の不具合を修正せず、すでにコメントテーブルやバックアップへ保存された値も除去しない。このため、WAFの有無にかかわらず7.110以降への更新が必要だ。

9月2日の報道では、500万超の有効インストールのうち最新版へ移行した割合は約35％で、約325万サイトが脆弱な版に残ると推計された。この数字は更新統計に基づく推計であり、侵害されたサイト数を示すものではない。確認されている安全策は、旧版での復元を止めて7.110以降へ更新し、旧版で復元した履歴がある場合にはトラックバック、公開コメント、管理者アカウント、MUプラグインを一続きの調査対象にすることだ。