wp2shellで最初に確認することは、WordPress本体のバージョンです。WordPress.orgは2026年7月17日に、深刻度の高いセキュリティ修正版としてWordPress 7.0.2を公開し、対象バージョンには自動更新を強制的に有効化したと案内しています。とはいえ、自動更新が有効でも実際に更新が終わっているとは限りません。
結論として、WordPress 7.0系なら7.0.2以降、6.9系なら6.9.5以降、6.8系なら6.8.6以降になっているかを確認してください。対象バージョンのままなら、記事を読むより先にバックアップを確認し、WordPress本体を更新するのが優先です。
脆弱性とは何か
脆弱性とは、ソフトウェアの中にある「攻撃に使われる弱点」のことです。WordPressでいえば、管理画面、REST API、データベース処理、ファイル処理などに、本来許してはいけない操作を通してしまうすき間がある状態です。
家で例えるなら、鍵をかけているつもりでも、別の小窓から中へ入れてしまう状態に近いです。パスワードが弱い、管理者がだまされた、という話とは別で、WordPress本体の処理そのものに問題がある場合は、サイト運営者が普通に使っていても影響を受けることがあります。
wp2shellで何が問題なのか
wp2shellは、WordPress本体で修正された2つの問題が組み合わさることで危険になります。1つはREST APIのバッチ処理に関する問題、もう1つはWordPress内部のデータベース問い合わせに関するSQLインジェクションです。
難しい言葉を避けて言うと、外部の人がログインせずにWordPressへ特殊なリクエストを送り、本来通ってはいけない処理へ入力を届かせられる可能性がありました。その結果、条件がそろうと任意のコード実行、つまり攻撃者がサーバー上で悪意ある処理を動かせるおそれがあります。
WordPress.orgのリリース情報では、CVE-2026-63030とCVE-2026-60137が示され、REST API batch-route confusionとSQL injection issue leading to Remote Code Executionが修正対象として説明されています。
攻撃されると何が起きるのか
wp2shellが悪用された場合、単にログイン画面へ大量アクセスされるだけでは済みません。成功すると、サイトの改ざん、悪性ファイルの設置、管理者アカウントの追加、データベース内情報の窃取、別サイトへの攻撃拠点化などにつながる可能性があります。
初心者が特に怖いのは、見た目には普通に表示されていても、裏側に不審なPHPファイルや管理者ユーザーが追加されているケースです。更新して画面が正常に戻ったように見えても、攻撃を受けた後なら「扉を閉めた」だけで、中に入られた形跡の確認は別に必要です。
影響を受けるWordPressバージョン
2026年7月24日時点で確認すべき目安は次の通りです。
| 利用中の系統 | 危険な範囲 | 更新先の目安 | 見るポイント |
|---|---|---|---|
| WordPress 7.0系 | 7.0.0〜7.0.1 | 7.0.2以降 | wp2shellの修正対象。最優先で更新する |
| WordPress 6.9系 | 6.9.0〜6.9.4 | 6.9.5以降 | 2つの脆弱性の影響を受けるため早急に更新する |
| WordPress 6.8系 | 6.8.0〜6.8.5 | 6.8.6以降 | 連携するSQLインジェクション側の修正が必要 |
| 6.8より前 | 今回のWordPress.org案内では対象外 | 可能ならサポートされる最新版へ | 古いままの別リスクが残りやすい |
自動更新が有効なサイトでも、必ず管理画面の「ダッシュボード」または「更新」画面で実際のバージョンを確認してください。サーバー側の制限やファイル権限、古いPHP環境、過去の手動変更によって、自動更新が完了していないことがあります。
自動更新って書いてあるなら、もう安心していいんですか？
私、そこだけ見て閉じちゃいそうです。
自動更新は助かる仕組みだけど、確認は別だね。
ぼくなら管理画面でバージョンを見て、更新日時も合わせて見るよ。
うわ、更新されたつもりが一番こわいです…。
まず数字を見るんですね。
そう。今回は「たぶん大丈夫」より「数字で確認」が安心につながる。
次は、実際にどの順番で対応するか見ていこう。
今すぐ行う対応順
- バックアップの有無を確認する。 更新前に、ファイルとデータベースのバックアップがあるか確認します。自動バックアップがあるサーバーでも、復元できる日付と対象範囲を見ておきます。
- WordPress本体を修正版へ更新する。 管理画面の「更新」からWordPress本体を更新します。7.0系は7.0.2以降、6.9系は6.9.5以降、6.8系は6.8.6以降が目安です。
- 更新後の表示と管理画面を確認する。 トップページ、記事ページ、管理画面、投稿編集画面、問い合わせフォームなど、普段使う場所を確認します。
- 管理者ユーザーを確認する。 見覚えのない管理者アカウントが追加されていないか確認します。不審なユーザーがあれば、削除前にサーバー会社や制作担当へ相談します。
- 不審なファイルや改ざんを確認する。 wp-content配下、plugins、themes、uploadsなどに見慣れないPHPファイルがないか確認します。分からなければサーバー会社のサポートや保守担当へ依頼します。
更新できない場合の暫定対策
本来の対策はWordPress本体の更新です。どうしてもすぐ更新できない場合は、サーバーやWAFでREST APIのバッチエンドポイントへのアクセスを一時的に止める方法があります。国内サーバー事業者の注意喚起でも、攻撃経路となる
/wp-json/batch/v1
への通信遮断が暫定対応として案内されています。
ただし、これは根本解決ではありません。REST APIのbatch機能を使うプラグイン、テーマ、外部連携、独自開発がある場合、機能に影響が出ることがあります。自分でWAFルールを書けない場合は、サーバー会社の案内やサポートに従ってください。
「更新したら終わり」にしない理由
更新は攻撃の入口を閉じる対応です。もし脆弱な状態で数日間インターネットに公開されていたなら、すでに触られた可能性も考えます。特に公開後にログインできなくなった、知らない管理者が増えている、記事に不審なリンクが入っている、サーバー容量が急に増えている場合は、更新だけで完了にしない方が安全です。
この確認は、怖がるためではなく、安心して運営を続けるために行います。異常が見つからなければ、その記録自体が次回の判断材料になります。
更新したあとも確認するんですね。
正直、更新ボタンを押したら終わりだと思ってました。
その感覚は自然だよ。
でも今回は、更新前に入られていなかったかを見るところまでが一区切りかな。
見覚えのない管理者とか、変なファイルとか…。
見つけたら触るのも怖いです。
その時は一人で消そうとしなくていい。
証拠が残っている方が原因を追いやすいこともあるから、サーバー会社や保守担当に相談しよう。
被害が心配なときに見る場所
| 確認場所 | 見る内容 | 不審な例 | 次の行動 |
|---|---|---|---|
| WordPressユーザー | 管理者権限のユーザー一覧 | 知らない管理者、見覚えのないメールアドレス | 削除前に記録し、必要ならサポートへ相談 |
| プラグイン一覧 | 有効化されたプラグイン | 名前が不自然、説明が空、最近勝手に追加されたもの | スクリーンショットを残して停止可否を確認 |
| テーマファイル | functions.phpや見慣れないPHP | 最近更新した覚えがないのに更新日時が新しい | バックアップとの差分を確認 |
| uploadsフォルダ | 画像置き場のファイル | 画像フォルダにPHPファイルがある | サーバー会社や保守担当へ相談 |
| アクセスログ | REST APIへのアクセス | /wp-json/batch/v1 や rest_route=/batch/v1 への不自然なアクセス | ログを保存し、WAFやサポートへ共有 |
やってはいけない対応
- 更新できていないのに「自動更新だから大丈夫」と判断する
- バックアップを確認せずにファイルを削除する
- 不審な管理者やファイルを見つけても記録せず消す
- 脆弱性の検証コードを自分の本番サイトで試す
- 古いWordPressのまま、セキュリティプラグインだけで済ませる
セキュリティプラグインやWAFは補助として役立つことがあります。しかし、WordPress本体の脆弱性が修正されていない状態では、根本対策にはなりません。今回の優先順位は、バージョン確認、更新、被害確認、必要に応じたサポート相談です。
公式情報と参考情報
wp2shellでよくある質問
WordPressの自動更新が有効なら何もしなくていいですか？
いいえ。自動更新が有効でも、実際のバージョン確認は必要です。管理画面の更新画面で、7.0.2、6.9.5、6.8.6以降になっているか確認してください。
プラグインを使っていないサイトも対象ですか？
対象バージョンのWordPress本体を使っている場合は、プラグインやテーマの有無に関係なく注意が必要です。今回の問題はWordPressコア側で修正されています。
更新後に何も異常がなければ安全ですか？
更新後に表示が正常でも、脆弱な期間に攻撃を受けていないかは別に確認します。管理者ユーザー、最近追加されたファイル、uploads内のPHPファイル、アクセスログを見てください。
私なら、まずバージョンを見ます。
それで古かったら、バックアップを確認してから更新します。
いい順番だね。
更新後は、知らない管理者と不審なファイルも見ておくと安心だよ。
怖いニュースだと思ってたけど、やる順番が見えたら少し落ち着きました。
今日のうちに確認します。
それが一番いい。
緊急の脆弱性は、怖がるより先に、確認できる場所から一つずつ片付けよう。
今日中に確認するチェックリスト
- WordPress本体が7.0.2、6.9.5、6.8.6以降になっているか確認する
- 更新前後のバックアップがあるか確認する
- 知らない管理者ユーザーが増えていないか確認する
- wp-content配下に不審なPHPファイルがないか確認する
- 不安が残る場合は、サーバー会社や保守担当へログ確認を依頼する
wp2shellは「名前が怖いニュース」ではなく、対象バージョンなら実際に確認が必要なWordPress本体の問題です。まずはバージョンを見て、更新できているかを数字で確認してください。