TITLE

WordPressの緊急脆弱性「wp2shell」で強制自動更新——対象と今すぐの対応

投稿日：2026.07.19

WordPressの緊急脆弱性「wp2shell」で強制自動更新——対象と今すぐの対応

2026年7月17日、WordPress.orgは緊急のセキュリティリリース「WordPress 7.0.2」を公開しました。合わせて6.9.5・6.8.6・7.1 beta2も同日リリースされています。対象は「wp2shell」と呼ばれる攻撃チェーンで、ログインも特別な設定もプラグインも不要な未認証のリモートコード実行(RCE)に至ります。WordPress.org側は対象バージョンのサイトへ自動更新システム経由での強制的なアップデートを既に有効化しました。それでも、自分のサイトのバージョンを確認し、更新が適用されているかを自分の目で確かめる必要があります。

wp2shellとは何か — 2つのCVEが連鎖して未認証RCEに至る

「wp2shell」は、セキュリティ研究者による技術解説(GMO Flatt Security Blog)が付けた通称です。実体は2つの脆弱性の組み合わせです。

1つ目はCVE-2026-63030、REST APIのバッチルート処理に起因する検証バイパスです。2つ目はCVE-2026-60137、SQLインジェクションの脆弱性です。この2つを連鎖させることで、未認証のリモートコード実行が成立します。発見者はSearchlight Cyber(Assetnote)のAdam Kues氏で、HackerOneを通じて責任ある開示が行われました。別の角度からのSQLインジェクション報告はTF1T、dtro、haongoの各氏によるものです。

WordPress.org公式のリリースノートでも、この2件は「critical(緊急)1件・high(高)1件」のセキュリティ課題として明記されています。CVE単体でも深刻ですが、両者が連鎖した時に到達する結果がRCEであるという点が、今回の対応の緊急度を決めています。

攻撃はどう成立するのか — ログインもプラグインも不要な突破口

wp2shellの攻撃チェーン図: 未認証HTTPリクエスト→認証検証バイパス→SQLインジェクション→未認証RCE成立

攻撃の起点は、REST APIのバッチエンドポイント(/wp-json/batch/v1 または ?rest_route=/batch/v1)への通常のHTTPリクエストです。この処理の中でリクエストのインデックスがずれ、本来到達できないはずのエンドポイントに到達してしまいます。この結果、認証・検証がバイパスされます。

バイパスした先でSQLインジェクションの脆弱性を突くことで、最終的に未認証のリモートコード実行に至ります。ログインも、特別な設定も、プラグインの導入も要りません。デフォルトインストールのままのWordPressが、匿名のHTTPリクエストだけで攻撃対象になり得るという点は、複数の海外セキュリティメディアでも共通して強調されている特徴です。

「REST APIは自分のサイトでは使っていないから関係ない」と考えるのは早計です。REST APIはWordPress Coreに組み込まれた機能であり、意図的に無効化する設定を行っていなければ有効なままです。

影響バージョンの見分け方 — 6.8系と6.9/7.0系で結果が変わる

自分のサイトが今回の対象かどうかは、稼働中のWordPressのバージョンで判断できます。

SQLインジェクション(CVE-2026-60137)の影響を受けるのは6.8.0〜6.8.5、6.9.0〜6.9.4、7.0.0〜7.0.1です。バッチルート混同(CVE-2026-63030)の影響を受けるのは6.9.0〜6.9.4、7.0.0〜7.0.1です。この2つが両方成立し、wp2shellとしてのRCEにまで到達するのは6.9.0〜6.9.4と7.0.0〜7.0.1に限られます。つまり6.8系はSQLインジェクションの影響は受けるものの、RCEには至りません。開発中の7.1 beta版も両方の影響を受けます。6.8より前のバージョンは今回の対象外です。

管理画面のダッシュボードからバージョンを確認し、修正版(7.0.2 / 6.9.5 / 6.8.6 / 7.1 beta2)未満であれば対象と判断してください。

すでに悪用の兆候が報告されている

海外セキュリティメディアのCyberInsiderは、watchTowr CEOのBenjamin Harris氏の発言として、この脆弱性の実際の悪用(in-the-wild exploitation)の兆候に言及しています。概念実証(PoC)のエクスプロイトコードも出回っていると報じられています。ただし、具体的な悪用件数や被害範囲がどの程度に及んでいるかは、この記事の執筆時点では確認できていません。

WordPress.orgが「critical(緊急)」に分類したうえで対象バージョンへ強制自動更新を有効化している以上、対応を後回しにできる状況ではありません。

今すぐやるべき対応

まず、管理画面でWordPressのバージョンを確認してください。7.0.2 / 6.9.5 / 6.8.6 / 7.1 beta2、またはそれ以降であれば対応済みです。未満であれば、ダッシュボードから手動で更新するか、WordPress.orgから最新版をダウンロードして適用してください。

強制自動更新が既に有効化されているとはいえ、実際に更新が適用されるタイミングはサイトごとの環境によって変わり得ます。「そのうち自動で当たるはず」と待つのではなく、今この場で確認する方が確実です。

更新をすぐに適用できない事情がある場合の暫定策として、GMO Flatt Security Blogは、WAF(Web Application Firewall)で /wp-json/batch/v1 と ?rest_route=/batch/v1 へのアクセスを遮断する、またはプラグインで未認証ユーザーによるバッチエンドポイントの利用を禁止する方法を挙げています。ただしこれはあくまで一時的な緩和策です。根本的な対策はWordPress Coreを修正版へ更新することであり、遮断だけで済ませる運用を私たちは推奨しません。

私たちLeadeasはWeb制作・システム開発を手がける会社として、複数のクライアントのWebサイト・システムを開発・運用の両面で預かっています。こうした緊急パッチへの対応で重視しているのは、稼働中のバージョンを普段から可視化しておくこと、そして「深刻度の高い脆弱性が出た時にどこまで自動更新に任せ、どこから手動確認に切り替えるか」をあらかじめ決めておくことです。今回のように強制自動更新がかかる場面でも、確認作業そのものを省略しない運用を基本に据えています。

Web制作・開発を外部に委託している場合は、委託先が今回のリリースに対応済みかどうかを確認することも忘れないでください。

まとめ

wp2shellは、ログインもプラグインも不要な未認証のリモートコード実行に至る、WordPress.orgがcritical(緊急)に分類した脆弱性です。CVE-2026-63030とCVE-2026-60137という2つの脆弱性が連鎖することで成立し、影響を受けるのは6.8.0〜7.0.1(および7.1 beta)です。WordPress.org側は既に強制自動更新を有効化していますが、それに任せきりにせず、自分の目でバージョンを確認し、必要なら手動で更新することが最も確実な対応です。すでに悪用の兆候が報告されている以上、確認を後回しにする理由はありません。