All-in-One WP Migration脆弱性｜危ないのは今取るバックアップ

バックアップは、何かあったときのための備えです。ところが今回の脆弱性は、そのバックアップを取って戻す動作そのものを発火点にします。しかも危ないのは、古い控えではなく、いま取るほうです。500万を超えるインストールを持つプラグインで、何が起きていたのかを見ていきます。

Wordfenceは2026年9月1日、WordPressのバックアップ・移行プラグイン「All-in-One WP Migration and Backup」に未認証のSQLインジェクションの脆弱性があると公表した。CVE-2026-19949、CVSSは8.8。7.109以下が対象で、ServMaskが8月20日に7.110で修正した。アクティブインストールは500万を超える。

攻撃者は認証なしでトラックバックを送り、コメントとして保存させる。この値は、そのあとに管理者がサイトをエクスポートしてインポートした際にSQLとして実行され、シークレットキーai1wm_secret_keyが公開コメントに書き出される。攻撃者はこれを読み取って未認証のインポートを実行し、リモートコード実行に至る。

From: 5 Million WordPress Sites Affected by SQL Injection Vulnerability in All-in-One WP Migration and Backup WordPress Plugin

【編集部解説】

8月のinnovaTopiaは、WordPressのSQLインジェクションからリモートコード実行へつながる連鎖を続けて追いました。コアのREST APIを叩くwp2shellと、それを受けてエックスサーバーが顧客のWordPressを更新した対応です。今回の脆弱性も、形だけ見れば同じ「SQLインジェクションからRCEへ」です。ただ、当たり方がまるで違います。

wp2shellは、リクエストを送ればその場で結果が出るものでした。今回は、攻撃者がリクエストを送る瞬間と、被害が起きる瞬間が、時間的に切り離されています。セカンドオーダーと呼ばれる型です。

攻撃者が仕込みの段階でやることは、ピンを受け付けている公開投稿にトラックバックを2件送ることです。認証は要りません。WordPressのコアはこれをコメントとして保存します。この時点では何も起きません。ただのコメントです。

火が着くのは、そのあとで管理者がサイトをエクスポートし、そのアーカイブをインポートしたときです。

危ないのは、いま取るバックアップのほう

ここが今回いちばん重たい部分です。そして、条件を正確に押さえておく必要があります。

Wordfenceは「Important Note」という節をわざわざ立てて、こう限定しています。攻撃者は終始未認証だが、悪意あるトラックバックが保存されたあとに管理者がエクスポートとインポートを行わない限り、仕込まれたSQLは実行されない。つまり、種が撒かれる前に取った古い控えを戻すだけなら、この経路は成立しません。

裏返すと、危ないのは古い控えではなく、いま取るバックアップです。種が入った状態で書き出せば、種はそのままアーカイブに収まる。それを戻したときに火が着く。そしてバックアップと移行は、このプラグインの本来の用途です。Wordfenceもこれを日常的な操作だと位置づけています。安全網を張る手つきが、そのまま導火線を敷く手つきになる。

もうひとつ、記事のコメント欄で読者が投げた質問が的を射ていました。「使うときだけ有効化して、普段は無効にしている場合はどうなるのか」。プラグインを止めても、コメントテーブルに入った値のほうは消えません。仕込みはWordPressコアの機能で行われるので、プラグインの状態とは関係がないからです。

壊れていたのは、入口ではなく書き換えの側

原因を一言でいうと、正規表現の取りこぼしです。

このプラグインは、インポート時にSQL文の中のURLやテーブル接頭辞を書き換えます。そのために、どこからどこまでが文字列かを正規表現で見分けている。ところが、閉じ引用符の直前を1バイトしか見ておらず、バックスラッシュが何個続いているかを数えていませんでした。

バックスラッシュが2個並んでいれば偶数なので、その引用符は本物の終端です。しかしこの正規表現は「エスケープされた引用符」と判断し、次の文字列まで飲み込んでしまう。飲み込んだ値をアンエスケープし、置換し、もう一度エスケープする。この往復でバックスラッシュの数が合わなくなり、MySQLから見た文字列の境界が反転します。データだったものが、SQLに昇格する。

攻撃者が仕込むトラックバックの末尾にバックスラッシュを置いていたのは、このためです。

注目したいのは、入力を受け取る場所には問題がなかったということです。WordPressのコアはトラックバックをそのまま保存し、エクスポート処理もバックスラッシュを正しく二重化しています。壊れていたのは、そのあとで文字列を書き換える工程でした。入口を固めるという発想だけでは、この種の欠陥には手が届きません。

更新は、届く経路があってはじめて届く

8月のエックスサーバーの件では、事業者が影響対象のWordPressコアを顧客に代わって更新しました。今回必要なのはプラグインの更新です。誰が押すのかは、ホスティング事業者の権限と運用方針によって変わります。

あのとき浮かび上がったのは、押す人が誰かという話だけではありませんでした。WordPress.orgは7月17日にコアの強制自動更新を有効にしています。それでも更新が届かなかったサイトが残りました。原因は公表されていません。ただ、更新経路が塞がれる背景の一つとして、制作側が自動更新を切り、更新を止めるプラグインまで入れて納品したサイトが実在します。WordPressの修復を請け負う瀬尾真氏は、プラグインの更新まで止められているケースがあると指摘していました。

経路が塞がれているサイトは、今回も同じように取り残される可能性があります。500万を超えるアクティブインストールという数字の重さは、脆弱性そのものよりも、そこへ更新を届ける道がどれだけ開いているかにあります。

開発元のServMaskの動きは速いものでした。8月17日に報告を受け止め、20日には7.110を出しています。Wordfenceも記事の中でその迅速さに触れています。

その7.110のチェンジログには「末尾がバックスラッシュの値に対する検索と置換」という記述と、発見者への謝辞があります。CVE番号は載っていません。同じプラグインの7.98では、格納型XSSの修正にCVE-2025-8490と明記されていました。チェンジログは、利用者が管理画面で目にする更新判断の材料の一つです。そこに深刻度を読み取れる情報を置くかどうかは、この開発元に限った話ではなく、プラグインの世界がこれから揃えていく作法だと思います。

ファイアウォールが守るのは、種まきの側

Wordfenceは8月16日、有料版の利用者にファイアウォールルールを配信しました。無償版への配信は30日後の9月15日です。

見ておきたいのは、そのルールがどこで止めるかです。Wordfenceが公開した図では、遮断地点はトラックバックが到達する瞬間、つまり種が撒かれる側に置かれています。復元時の発火を止めるものではありません。

あとからWAFを入れても、すでにコメントテーブルに入っている値は消えない。9月15日にルールが届いても、それより前に撒かれたものはそのまま残ります。

やることは3つです。プラグインを7.110に上げること。身に覚えのないトラックバックやピンバックがコメントに残っていないかを見ること。使う予定がないなら、トラックバックの受け付けを閉じること。ただし「設定」の「ディスカッション」で既定を切っても、原則としてこれから作る投稿にしか効きません。すでに公開している投稿は、個別または一括編集で閉じる必要があります。攻撃の入口はwp-trackback.phpです。アクセスログが残っているなら、足跡はそこにあります。

日本の読者にとって

日本でも、企業や自治体、メディアのサイトにWordPressが使われています。制作や保守を外部へ委託しているサイトでは、サーバー移行や復元を受託側が担当することがあります。

この構図を今回の脆弱性に重ねると、少し落ち着かない絵になります。トラックバックを撒いた者と、エクスポートとインポートを実行する者と、被害を受けるサイトの持ち主が、それぞれ別人です。実行した人に悪意はありません。仕事をしただけです。

だから、移行や復元を請け負う側にとって、着手前にプラグインのバージョンを確かめることは、顧客のためであると同時に、自分を守る手順でもあります。

なお、公開されているCVSSベクターは、低い権限が必要（PR:L）で、利用者の操作は不要（UI:N）とするものになっています。Wordfenceの本文が説明する経路は「攻撃者は終始未認証で、管理者のエクスポートとインポートが必要」ですから、両者は噛み合っていません。スコアと、そこに至る経路の説明は、別々に読んだほうがよさそうです。8.8という数字だけで順番を決めると、この脆弱性の形は見えません。

Wordfenceの記事に、実際の悪用を確認したという記述はありません。ただし、観測の報告がないことは、悪用されていないことを意味しません。確認を待つ理由にはならない、ということです。

正規表現の否定後読みが1バイトしか見ていなかった。その一行の見落としが、500万を超えるアクティブインストールを持つプラグインの、移行と復元の手順まで届いてしまう。ソフトウェアの欠陥がどれほど遠くへ運ばれるかを、これほど素直に見せてくれる事例もそう多くありません。バックアップを取る習慣は正しい。そのうえで、戻す道具そのものを点検する日を、どこかに入れておきたいと思わされる一件でした。