見出し画像

ログイン不要でWordPressが乗っ取られる脆弱性「wp2shell」7.0.2が修正したRCEの仕組みと、今週確認しておきたいこと


7月17日、WordPressがバージョン7.0.2をリリースしました。

更新情報のリストを見ると「セキュリティパッチ2件」という一行で終わりそうな話です。

でも修正された脆弱性の内容を読むと、少し背筋が伸びます。

「wp2shell」と名付けられたこの欠陥、プラグインなし・ログインなし・デフォルト構成のWordPressでも、外部から任意コードを実行できてしまいます。

私はこのニュースを月曜の朝に確認して、そのまま管理中の全クライアントサイトのバージョンチェックを始めました。


「wp2shell」とは何か 問題の構造を整理する

「wp2shell」はセキュリティ研究者がこの脆弱性チェーンに付けたニックネームです。

CVE番号は2つ発行されており、CVE-2026-63030(REST APIバッチルート混乱)と CVE-2026-60137(SQLインジェクション)の組み合わせで成立します。

この脆弱性で特に厄介なのは「pre-authentication(認証前)」という性質です。

攻撃者はWordPressのアカウントを持っている必要がありません。匿名のHTTPリクエスト1本で、サーバー上でコードを動かせてしまいます。

影響を受けるバージョンはWordPress 6.8〜6.9系、および7.0・7.0.1です。

しかもPoC(概念実証、実際に動く攻撃コード)がすでに一般公開されており、研究者たちは現時点で実際の悪用事例も確認し始めています。


脆弱性の仕組み REST APIとSQLインジェクションの連鎖

少し技術的になりますが、仕組みを把握しておくと対応の優先度を判断しやすくなります。

WordPressのREST APIには「バッチリクエスト」機能があります。

複数のAPIコールを1回のHTTP通信にまとめて送れる仕組みです。

wp2shellの攻撃は、このバッチ機能でリクエスト先のルートを意図的に混乱させることから始まります(CVE-2026-63030)。

この状態を踏み台にして、コア内部のSQLクエリ処理に細工したデータを流し込みます(CVE-2026-60137)。

そこからデータベースを操作し、最終的にサーバーサイドのコード実行につなげる——それがwp2shellの攻撃チェーンです。

「プラグインの問題ではなく、WordPressコア自体に潜んでいた欠陥」であることが、今回の深刻さの核心です。

「うちはセキュリティプラグインを入れているから大丈夫」という判断が通用しない種類の問題でした。


対処方法 確認しておきたい3つのポイント

対応内容はシンプルです。

管理しているサイトが複数ある場合は抜け漏れが出やすいので、整理しておきます。

バージョンアップを確認する

WordPress管理画面の「更新」ページで現在のバージョンを確認してください。

6.8系は6.8.6、6.9系は6.9.5、7.0〜7.0.1は7.0.2が修正済みバージョンです。

WordPressはこの脆弱性の深刻度を受けて、強制自動更新も発動しています。

ただし、自動更新を無効にしているサイトや、更新タイミングを手動管理しているサイトは見落としがちなので注意が必要です。

ホスティング側のWAFを確認する

利用しているホスティングがWAF(Webアプリケーションファイアウォール)を提供している場合、今回の脆弱性に対応したルールが追加されているか確認しておくと安心です。

SiteGroundやKinstaなど主要サービスでは、パッチ公開前後にWAFルールが追加されたと報告されています。

アクセスログをひと目見ておく

更新前に少し時間が空いていた場合は、`/wp-json/wp/v2/batch` へのアクセスを軽く確認しておくことをお勧めします。

不審なバッチリクエストが残っていれば、状況を早期に把握する手がかりになります。


自動更新に任せっきりにする落とし穴

今回WordPressが強制自動更新を動かしたことで、「気づかないうちに更新されていた」というサイトも出てくるはずです。

セキュリティ的にはありがたい措置ですが、カスタマイズが深いサイトや古いプラグインを多く使っているサイトでは、更新後に何かが壊れているリスクがあります。

私は今回、管理しているサイトのうち2件についてステージング環境で7.0.2を先に当てて動作確認してから本番に反映しました。

自動更新の恩恵を受けながらも、最終的なコントロールは自分で持っておく習慣を改めて意識するきっかけになりました。

クライアントにとっては「サイトが壊れた」と「ハッキングされた」はどちらも大ごとです。

前者は自分でコントロールできるリスクで、後者は今回のような対応で防げるリスク——そう整理して動いています。


まとめ

wp2shellは、WordPressコアに潜んでいた認証不要のリモートコード実行脆弱性です。

PoCが公開され、実際の攻撃事例も出始めている今、管理しているWordPressサイトの更新状況を確認しておく価値はあります。

セキュリティの話は「怖がらせる」ために書くのではなく、「具体的に何をすればいいか」が伝わることが大事だと思っています。

この記事がその一助になれば幸いです。


いいなと思ったら応援しよう!