wp2shellの感染をチェックする5か所と、見つかった時の対処

wp2shellの感染をチェックしたい。本体はもう修正版になっているはずだけれど、本当に何もされていないのか分からない。この記事は、その確認を自分のサイトで今日やるための手順です。

wp2shellは、2026年7月17日に修正版が公開されたWordPress本体の脆弱性の通称です。プラグインやテーマに関係なく、ログインなしで管理者アカウントを作られ、裏口を置かれるおそれがありました。対象は6.9.0〜6.9.4と7.0.0〜7.0.1。修正版は6.9.5、7.0.2、6.8.6です。公表の翌週には悪用が確認され、国内でも9月以降に不正アクセスの公表が続いています。

「自動更新されたから大丈夫」と思っている方が多いのですが、更新は入口をふさいだだけで、更新前に入られていたかどうかは教えてくれません。この記事では、管理画面で3か所、サーバーで2か所、合わせて5か所の見方と、公式ディレクトリにあるスキャナーの使い方、痕跡が見つかった時の最初の動きを順に書いています。対応事例が入り次第、この記事に追記します。

伊藤

「更新は済んでいます」と言われたサイトを見せてもらうと、更新の日付が8月下旬、ということがあります。公表は7月17日です。この数週間が空いているサイトは、一度は中を見ておいたほうがいいです。

更新が済んでいても、公表から更新までの期間は別に確かめる

WordPress.orgは7月17日の公開時に、影響を受けるバージョンに対して自動更新による強制更新を有効にしました。ただ、自動更新が効かない環境は珍しくありません。IPAの注意喚起にも、次のように書かれています。

自動更新が有効ではなかったり、更新に失敗している可能性も考えられます。

IPA「WordPressの脆弱性対策について(CVE-2026-60137、CVE-2026-63030：wp2shell)」2026年7月22日

レンタルサーバー側の対応も、時系列を見ると空白があります。たとえばXSERVERビジネスの告知では、7月19日に攻撃の入口となるbatch APIへの通信を遮断し、本体の自動更新は7月31日頃から8月25日にかけて順次実施、となっています。遮断は暫定措置で脆弱なコードは直っておらず、しかも遮断までの2日間は入口が開いていました。この期間に攻撃を受けていたサイトは、更新後も裏口が残ったままです。

ですから、確かめる順番は「今のバージョンが修正版か」→「空白の期間に入られた痕跡が無いか」の2段階になります。

まず今のバージョンが修正版かを管理画面で確かめる

「ダッシュボード」→「更新」を開きます。上部に「現在のバージョン」が出ます。6.9系なら6.9.5以上、7.0系なら7.0.2以上、6.8系なら6.8.6以上なら、この脆弱性は塞がっています。

この例のように6.9.4のままなら、他のことより先に更新してください。更新前にファイルとデータベースのバックアップを取るのは、画面に書いてあるとおりです。現在の最新は7.1系ですが、6.9系のまま6.9.5以上に上げるだけでもこの脆弱性は塞がります。大きく上げる作業は、別の手順で落ち着いてやって構いません。

自動更新に任せている場合も、この画面で実際の数字を見てください。「自動更新が予定されています」と出ていても、まだ実行されていないことがあります。

伊藤

更新画面に「サイトはバージョン管理されているようです。自動更新は無効化されています」と出ているサイトは、Gitで管理している制作会社の環境によくあります。この場合、自動更新は最初から動いていません。

管理画面で見る3か所は、管理者・プラグイン・メール

チェックする場所は5か所です。管理画面で3か所、サーバーで2か所。上から順に見ていきます。管理画面の3つは数分で終わります。

• ユーザー一覧（管理画面）: 知らない管理者、wp2_ で始まる名前
• プラグイン一覧（管理画面）: wp2shell_ で始まる見覚えのないもの
• 設定 → 一般（管理画面）: 管理者メールアドレスが変わっていないか
• wp-content の中（サーバー）: uploads・cache・upgrade に新しい zip や php
• アクセスログ（サーバー）: batch/v1 への POST

1 ユーザー一覧に知らない管理者がいないか

「ユーザー」を開き、「管理者」の人数を見ます。自分が作った覚えのある人数と合っているか、まずそこです。合っていたら、一覧をメールアドレスの列まで含めて見ます。

1つでも当てはまれば黒に近いサインは、この4つです。

• ユーザー名が wp2_ で始まる（公開された攻撃コードの初期値）
• メールアドレスが @wp2shell.invalid（同じく初期値）
• 7月17日以降に増えた管理者で、自分が作った覚えがない（登録日で並べ替える）
• 管理者の人数が記憶と合わない（消された管理者はユーザーIDの欠番として残る）

公式ディレクトリのスキャナーも、上の2つを「Critical」の項目にしています。ただし攻撃者が名前を変えているケースも当然あるので、7月17日以降に作られた管理者は、名前が普通でも自分で作ったものか思い出してください。管理者を作って、使い終わったら消す攻撃もあります。この場合、ユーザー一覧には何も残りませんが、ユーザーIDに欠番ができます。後で紹介するスキャナーがこの欠番を見てくれます。見つけても、まだ削除しないでください。画面を保存してから次の項目へ進みます。

2 プラグイン一覧に知らない名前が無いか

「プラグイン」→「インストール済みプラグイン」を開き、見覚えのないものを探します。wp2shellの攻撃は、管理者権限を取った後にプラグインの形で裏口を置きます。名前は「wp2shell_」に続いて英数字8桁、というのが観測されている形です。

ただし一覧に出ないように細工されていることもあるので、次のサーバー側のチェックで wp-content/plugins の中身も直接見ます。

3 一般設定の管理者メールが自分のものか

「設定」→「一般」の「管理者メールアドレス」を見ます。ここを書き換えられると、パスワードの再設定メールが攻撃者に届くようになり、後からいつでも管理者に戻れます。見覚えのないアドレスになっていたら、それ自体が侵害の証拠です。

サーバーではwp-contentとアクセスログの2か所を見る

ここからはFTPかサーバーのファイルマネージャーで入ります。見る場所は2つだけです。

4 wp-contentに新しいzipやphpが無いか

wp-content の中で、更新日時が7月17日以降の .php と .zip を探します。更新日時で並べ替えると早いです。セキュリティ各社の検知レポートで観測されている置き場所は、次の4つです。

• plugins/wp2shell_〜/（裏口として置かれるプラグインの形）
• uploads/wp2shell_〜.zip（裏口を入れるために上げられた圧縮ファイル）
• wp-content/temp-write-test-〜（書き込めるか試した跡）
• cache/ や upgrade/ の新しい .php（本来 .php が増える場所ではない）

uploads の中に .php があること自体が異常です。画像しか置かれないはずの場所なので、拡張子で検索して1つでも出たら保存してください。

5 アクセスログにbatchへのPOSTが無いか

攻撃の入口は1か所に決まっています。REST APIのバッチ用の窓口です。サーバーのアクセスログを7月17日以降の分だけ取り出し、「batch/v1」で検索します。

POSTが1行も無ければ、少なくとも入口は叩かれていません。あれば、直後の行まで読みます。ログの行は、たとえばこういう形です。

203.0.113.10 - - [18/Jul/2026:03:12:41 +0900] "POST /wp-json/batch/v1 HTTP/1.1" 207 16 "-" "wp2shell"
203.0.113.10 - - [18/Jul/2026:03:12:55 +0900] "POST /wp-admin/update.php?action=upload-plugin HTTP/1.1" 200 4812 "-" "wp2shell"

1行目が入口です。「/wp-json/batch/v1」か「/?rest_route=/batch/v1」へのPOSTで、User-Agentに「wp2shell」「cve-2026-63030/1.0」「rezwp2shell」と名乗るものが多く観測されています。ただし応答コードの207は正常なリクエストでも返るので、1行目だけでは成功したか分かりません。

決め手は2行目です。同じIPから数秒〜数分後に「update.php?action=upload-plugin」や「plugin-install.php」、「/wp-json/wp/v2/users?context=edit」へのアクセスが続いていれば、管理者権限を取った後の動きです。この並びがあれば、侵害されたものとして扱ってください。

ログの保存期間はサーバー会社によって違います。XSERVERは直近の分をサーバーパネルからダウンロードできますが、7月のログがもう残っていない場合は、この項目は確かめようがありません。その場合は他の4か所とスキャナーの結果で判断します。

伊藤

ログに「batch/v1」へのPOSTがあっても、ほとんどは世界中から来ている総当たりの試しです。慌てるのは、同じIPが数分後にプラグインを上げに来ている時です。

公式ディレクトリのスキャナーで13項目を一度に確かめる

ここまでの手作業を一度にやってくれるプラグインが、WordPress.orgの公式ディレクトリにあります。セキュリティ会社のEye Securityが公開している「Compromise Scanner for wp2shell」です。データベースとプラグインフォルダを読むだけで、サイトには何も書き込みません。

画面の左が本体のバージョンの判定、その右が痕跡の判定と点数です。下に13項目の結果が並びます。

13項目には、手作業では見にくいものが含まれています。消された管理者の痕跡（ユーザーIDの欠番、孤立したユーザーメタ）、攻撃コードが仕込む oembed_cache のエントリ、親IDが100万以上の不自然な投稿、7月17日以降に作られた customize_changeset などです。

読み方で大事なのは2つです。一致した項目があっても、それだけでは侵害の証明にはなりません。7月17日以降に自分で管理者を追加していれば、その項目は当たります。逆に「No indicators」でも安全の保証ではありません。痕跡を消す攻撃者もいますし、この脆弱性以外の攻撃は検出の対象外です。スキャナーは「どの項目が当たったか」を見るための道具で、判定を丸ごと信じるものではありません。

「Export report」で結果とログ収集の手引きをzipで出せます。専門家に相談するときは、このzipを一緒に渡すと話が早いです。確認が終わったら「Remove this plugin」で自分を消せます。

痕跡が見つかったら消さずに保全して切り離す

知らない管理者や wp2shell_ のフォルダを見つけると、すぐ消したくなります。消さないでください。別の裏口が残っていれば数日で戻ります。先にやることが3つあります。

1. 画面とファイルを保存する。ユーザー一覧のスクリーンショット、見つけたファイルのコピー、アクセスログを、サーバーの外（手元のPC）に保存します。何がどこにあったかが分からなくなると、他の裏口を探せません
2. 全部のパスワードと鍵を変える。WordPressの全ユーザー、FTP、サーバーパネル、データベース、wp-config.php の認証キー。管理者メールアドレスも自分のものに戻します
3. サイトを切り離すか判断する。問い合わせフォームや会員情報を扱うサイトなら、調査が終わるまでメンテナンス表示にします。表示だけの会社サイトなら、公開したまま調査しても構いません

そのあとの復旧は、見つけた裏口を1つ消して終わりにしないことが肝心です。wp2shellで管理者を取られたサイトは、その権限でテーマやプラグインに別の裏口を足されていることがあります。その場合は、全ファイルを保全してから、最新版で作り直すのが確実です。

見ても判断できない、FTPやログに入れない、という場合は無料のセキュリティ診断で状況をお聞かせください。こちらで上の5か所とスキャナーの結果を読み、痕跡があれば復旧の手順と費用をその場でお伝えします。

何も無くても更新だけで終わらせない

5か所とスキャナーで何も出なければ、今回は入られていないと考えて構いません。ただ、同じ型の脆弱性はこれからも出ます。wp2shellで分かったのは、プラグインを減らしても本体の穴は防げないこと、自動更新は効いていないことがあること、サーバー会社の遮断は代わりにならないこと、の3つです。

• 「ダッシュボード」→「更新」で、本体の自動更新が有効になっているかを見る。無効なら有効にするか、月1回は手で更新する
• レンタルサーバーのWAFは有効のままにする。ただし入口を塞ぐだけなので、本体の更新の代わりにはならない
• 使っていないプラグインとテーマは、無効化ではなく削除する。今回の入口には関係なかったが、次の脆弱性の入口になる
• アクセスログを手元に残す。サーバーの保存期間が短いと、次に何かあった時に空白の期間を調べられない
• スキャナーは入れっぱなしにせず、確認が終わったら削除する。必要な時にまた入れればよい

伊藤

更新を止めている理由が「古いテーマが壊れるかもしれないから」でも、更新を止めたまま穴を抱えるより、テスト環境で確かめてから上げるほうが安全です。

よくある質問（FAQ）

サーバー会社から「自動更新しました」とメールが来ました。それでもチェックは必要ですか？

必要です。更新は入口を塞ぐ作業で、更新前に入られていたかは教えてくれません。メールの更新日と7月17日の間が空いていれば、その期間に入られた痕跡が無いかを5か所で見てください。10分あれば管理画面の3か所は終わります。

サーバー会社がbatch APIを遮断していたなら安全ですか？

遮断の開始までの期間は開いていました。XSERVERビジネスの告知では遮断は7月19日からで、公表は7月17日です。この2日間と、遮断をすり抜ける形のリクエストがあった可能性を考えると、遮断だけでは安全とは言えません。遮断は暫定措置で、脆弱なコードは直っていないと告知にも書かれています。

スキャナーが「No indicators」でした。これで安全と考えていいですか？

この脆弱性の既知の痕跡は無い、という意味です。痕跡を消す攻撃者もいますし、別の脆弱性からの侵入は見ていません。アクセスログに batch/v1 へのPOSTが無く、ユーザーとファイルにも異常が無ければ、今回は入られていないと判断して構いません。

6.9系のままです。7.1まで上げないと危険ですか？

この脆弱性に関しては6.9.5以上なら塞がっています。7.1まで一気に上げる必要はありません。ただ6.9系のセキュリティ更新がいつまで続くかは保証されていないので、テーマやプラグインの互換を確かめたうえで、落ち着いて最新系に上げる計画は立ててください。

ログインもFTPもできない状態です。自分で確かめる方法はありますか？

外からできるのは、検索結果で site:自社ドメイン を見て知らないページが無いか、サイトの表示が別サイトに飛ばされないか、の2つだけです。管理画面に入れないなら、サーバーパネルからのパスワード再設定が先です。それもできない場合は、ログイン情報を渡す前に、状況だけ無料診断で聞かせてください。

まとめ

• 本体が修正版でも、7月17日の公表から更新までの期間に入られていたかは別に確かめる
• 管理画面では、知らない管理者（wp2_ や @wp2shell.invalid）、wp2shell_ で始まるプラグイン、管理者メールアドレスの3か所
• サーバーでは、wp-content の7月17日以降の .php と .zip、アクセスログの batch/v1 へのPOSTとその直後の行
• 公式ディレクトリの Compromise Scanner for wp2shell で13項目を一度に見る。一致は侵害の証明ではなく、なしも安全の保証ではない
• 痕跡が見つかったら削除より先に保全。全パスワードと鍵を変え、別の裏口を前提に復旧する

wp2shellの痕跡チェックを含む、WordPressの無料セキュリティ診断、代行できます

費用目安 無料

想定工数 即日（調査結果をメールで）

• WordPress本体のバージョンと自動更新の状態の確認
• ユーザー一覧・プラグイン・wp-content の痕跡チェック
• アクセスログの batch/v1 へのPOSTの有無
• 公式スキャナーの結果の読み解き
• 痕跡があった場合は、復旧の手順と費用をその場でお見積り

合同会社キューブリック

まずは状況をお聞かせください。作業前に内容と金額をお伝えし、追加料金はいただきません。

代表社員 / WEBエンジニア

無料で相談する

まずは状況をお聞かせください。診断は無料、痕跡が見つかった場合の復旧（¥17,800〜）は内容を見てお見積りします。営業の電話・メールはしません。