WordPressの重大な脆弱性「wp2shell」について、エックスサーバーをはじめとするレンタルサーバー各社がサーバー側での遮断対応を実施しています。ただし、これらはあくまで被害を抑えるための暫定措置であり、根本的な解決にはなりません。サーバー会社が対応したからといって、サイト側で何もしなくてよいわけではありません。この記事では、サーバー側の対策で何が防げて何が防げないのかを整理し、サイト運営者が今すぐやるべきことを解説します。
結論｜サーバー側の遮断は時間稼ぎ、更新は必須
先に結論をお伝えします。サーバー側の遮断措置は、攻撃が届くまでの時間を稼ぐためのものです。エックスサーバーの告知にも「本対応はあくまで被害の発生を抑えるための暫定的な措置であり、根本的な解決には至りません」と明記されています。
脆弱性そのものはWordPress本体のコードに存在します。したがって、直すにはWordPress本体を修正済みバージョンへ更新するしかありません。以下のバージョンを使っている場合は、今すぐ更新してください。
| 使用中のバージョン | 更新先 |
|---|---|
| 6.9.0 〜 6.9.4 | 6.9.5 以降 |
| 7.0.0 〜 7.0.1 | 7.0.2 以降 |
| 6.8.0 〜 6.8.5 | 6.8.6 以降 |
エックスサーバーが実施した対策の内容
エックスサーバーは、2026年7月19日午前6時30分頃にREST APIのバッチエンドポイント（/wp-json/batch/v1）への通信を遮断する対応を実施しました。wp2shellの攻撃がこのエンドポイントを入口にするため、そこを塞いだ形です。
- 2026年7月19日：
/wp-json/batch/v1への通信を遮断 - 2026年7月22日：バッチエンドポイントを正規に利用していた利用者への個別案内を追記
- 2026年8月6日：影響対象外のドメインについて遮断を解除
注目すべきは、8月6日に影響対象外のドメインでは遮断が解除されている点です。つまりこの遮断は恒久的なものではなく、状況に応じて解除されます。サーバー側の措置に依存し続けるのは現実的ではありません。
なぜ遮断だけでは不十分なのか｜3つの理由
理由1｜塞いだのは入口のひとつだけ
wp2shellは、2つの脆弱性を組み合わせた攻撃です。CVE-2026-63030（解釈の競合／CVSS 7.5）がREST APIのバッチエンドポイントを入口とし、そこからCVE-2026-60137（SQLインジェクション／CVSS 9.1）につなげることでリモートコード実行に至ります。
サーバー側が遮断したのは前者の入口です。しかしSQLインジェクションの脆弱性そのもの（CVE-2026-60137）は、WordPress本体に残ったままです。こちらはCVSS 9.1と、2つのうちより深刻な評価が付いています。
理由2｜プラグイン経由という別の経路がある
CVE-2026-60137は、WP_Queryクラスのauthor__not_inパラメータがサニタイズされていないことに起因します。JVNの記載によれば、プラグインやテーマがこのパラメータに値を渡している場合にSQLインジェクションが成立し得ます。
つまり、バッチエンドポイントを塞いでも、該当するパラメータを扱うプラグインやテーマを使っていれば別の経路が残る可能性があります。自分のサイトがどのプラグインでこのパラメータを使っているかを個別に洗い出すのは現実的ではないため、本体を更新して根本から塞ぐのが唯一の確実な対策です。
理由3｜サーバー会社によって対応が異なる
今回のような遮断対応は、各レンタルサーバー会社が個別に判断して実施しているものです。使っているサーバーによっては、同様の措置が取られていない場合があります。自社サーバーやVPSで運用している場合は、当然ながら自分で対処する必要があります。「どこかが守ってくれているはず」という前提は成り立ちません。
この脆弱性が特に危険な理由
wp2shellは、次の3点が揃っている点で特に警戒が必要です。
- 認証が不要：ログインしていない外部の攻撃者が実行できます
- プラグインやテーマの有無を問わない：該当バージョンのWordPressであれば、標準構成でも影響を受けます
- 実証コード（PoC）が公開済み：攻撃のハードルがすでに下がっています
「特別なプラグインを入れていないから大丈夫」という判断は通用しません。バージョン番号だけが判断基準になります。
複数サイトを管理している場合のチェック手順
クライアントサイトを複数抱えている制作会社や、社内で複数サイトを運用している場合は、次の順序で進めると漏れがありません。
- 全サイトのバージョンを一覧化する：管理画面の「ダッシュボード」→「更新」で確認し、サイト名とバージョンを表にまとめます
- 該当バージョンを優先度順に並べる：6.9系・7.0系を最優先、次に6.8系という順で対応します
- バックアップを取得してから更新する：マイナー更新は比較的安全ですが、必ず戻せる状態を作ってから実行します
- 更新後に表示と管理画面を確認する：トップページ、問い合わせフォーム、管理画面のログインを最低限チェックします
- 自動更新の設定を確認する：今回のような事態に備え、マイナーバージョンの自動更新が有効になっているかを確認しておきます
特に注意したいのが、「自動更新に任せているから大丈夫」という思い込みです。設定や環境によっては自動更新が動作していないケースがあります。必ずバージョン番号を目視で確認してください。
よくある質問
Q. エックスサーバーを使っています。何もしなくて大丈夫ですか？
A. いいえ、更新が必要です。サーバー側の遮断は暫定措置であると公式に明記されており、影響対象外と判定されたドメインでは遮断がすでに解除されています。WordPress本体を修正済みバージョンへ更新してください。
Q. REST APIを使っていないので関係ないのでは？
A. 関係あります。REST APIはWordPressに標準で組み込まれており、意識して使っていなくても有効になっています。無効化していない限り、対象となります。
Q. 2つのCVEのうち、どちらがより危険ですか？
A. CVSSスコアで見ると、SQLインジェクションのCVE-2026-60137が9.1、解釈の競合のCVE-2026-63030が7.5です。ただしwp2shellはこの2つを組み合わせてリモートコード実行に至る攻撃であり、片方だけを気にすればよいものではありません。どちらも同じ更新で対策されます。
Q. 更新したかどうか、あとから確認できますか？
A. 管理画面の「ダッシュボード」→「更新」でバージョン番号を確認してください。6.9.5以降、7.0.2以降、6.8.6以降であれば対策済みです。
Q. すでに攻撃を受けていないか調べる方法はありますか？
A. サーバーのアクセスログで /wp-json/batch/v1 への不審なリクエストを確認する方法があります。管理者ユーザーが勝手に増えていないか、身に覚えのないファイルが設置されていないかもあわせて確認してください。不安な場合は専門家への相談をおすすめします。
まとめ
レンタルサーバー各社の遮断対応はありがたい措置ですが、それは根本対策ではなく時間稼ぎです。脆弱性はWordPress本体にあるため、本体を更新するまでリスクは残ります。wp2shellそのものの詳しい内容は WordPressの重大な脆弱性「wp2shell」とは｜今すぐ確認すべき更新と対処法 で解説していますので、あわせてご確認ください。THREE D PLUSでは、WordPressサイトの脆弱性対応や更新作業の代行、保守運用のご相談を承っております。複数サイトの管理にお困りの際は、お気軽にお問い合わせください。
※本記事は2026年8月11日時点の公開情報にもとづいています。対応状況は各サーバー会社の告知により変わる可能性があるため、実際の対応時はご利用のサーバー会社およびWordPress公式の最新情報をご確認ください。
