WordPressを運用する際、「本体を更新し、プラグインを厳選していればリスクを大きく抑えられる」と考えている方は少なくありません。

実際、WordPress関連の脆弱性では、プラグインやテーマに起因するものが大きな割合を占めます。プラグインを厳選し、不要なものを削除し、更新を続けることは、現在も重要な対策です。

一方、2026年7月17日、WordPressは本体に存在する2件の脆弱性を修正したWordPress 6.9.5、7.0.2などを公開しました。2件を組み合わせた攻撃チェーンは「wp2shell」と呼ばれ、影響を受けるバージョンでは、脆弱なプラグインを必要とせず、認証されていない攻撃者によるリモートコード実行につながる可能性があります。

その後、複数の公開PoC（実証コード）が流通し、実環境での悪用も確認されました。7月21日には米CISA（サイバーセキュリティ・インフラセキュリティ庁）が2件をKEV（悪用確認済み脆弱性）カタログに追加し、翌22日にはIPAも国内向けの注意喚起を公開しています。

今回の事例が示したのは、「WordPress本体は危険である」という単純な結論ではありません。必要なのは、プラグイン対策だけではないということです。本体の迅速な更新、外部公開している機能の把握、ログの確認、権限境界、バックアップと復旧を含めた運用全体が問われます。

wp2shellとは。プラグインではなく本体の脆弱性連鎖

wp2shellは単一のバグではなく、2つの脆弱性の連鎖です。

  • CVE-2026-63030：WordPress REST APIのバッチ処理（複数のAPIリクエストを1回にまとめて送る機能）における「ルート混同」の脆弱性です。検証処理と実行処理を別々のループで行う際に、両者が扱う配列の対応がずれ（非同期化し）、後続リクエストが誤ったハンドラーで処理されます。
  • CVE-2026-60137：WordPressのデータベース検索処理（記事一覧クエリ等）に存在するSQLインジェクションの脆弱性です。単体では認証が壁になりますが、上のルート混同と連鎖すると未認証で到達しえます。

2つを連鎖させると、影響を受けるバージョンでは、認証されていない攻撃者によるリモートコード実行、すなわち管理者作成や悪意あるプラグインの設置につながる可能性があります。

wp2shell攻撃チェーンの流れ。REST APIのルート混同（CVE-2026-63030）からSQLインジェクション（CVE-2026-60137）を経てリモートコード実行に至る3段階

見落とせないのは、この攻撃が脆弱なプラグインを必要としない点です。影響を受けるバージョンの標準構成では、プラグインを厳選・更新していた場合でも成立しえます。ただし「すべての構成で必ず成立する」わけではありません。Rapid7は、完全な攻撃経路について「永続オブジェクトキャッシュを使用していない構成」で到達可能と説明しています。

影響と修正の状況は次のとおりです。SQLインジェクション単体は6.8系にも影響します。

バージョン 影響 修正版
6.8.0〜6.8.5 SQLインジェクション単体（CVE-2026-60137） 6.8.6
6.9.0〜6.9.4 wp2shellの完全なRCEチェーン 6.9.5
7.0.0〜7.0.1 wp2shellの完全なRCEチェーン 7.0.2

WordPressは重大性を理由に、修正版の強制的な自動更新も有効化しています。

今日やること3つ

対応の優先順位は明確です。まず塞ぐ、次に調べる。

  1. 今すぐ更新する。6.9.5または7.0.2以降（6.8系なら6.8.6以降）へ上げます。自動更新が有効でも、実際に適用されたかを管理画面かバージョンで確認してください。「設定してあるはず」と「適用済み」は別物です。
  2. すぐ更新できない事情があるなら、暫定で塞ぐ。REST APIのバッチ処理にはパス形式とクエリ形式の両方の経路があるため、WAF（Webアプリケーションファイアウォール）で /wp-json/batch/v1 と ?rest_route=/batch/v1 の両方を遮断します。REST API全体を未ログインで無効化する方法は影響範囲が広く、サイト機能を壊す可能性があるため、まず特定エンドポイントの遮断を優先し、全体制限は動作確認を伴う別手段として扱ってください。あくまで更新までのつなぎです。
  3. 「もう入られている」前提で一次確認する。脆弱な期間に外部公開していたサイトは、次を確認します。作った覚えのない管理者アカウントがないか。直近に追加されたプラグインや見覚えのないPHPファイルがないか。サーバーログにREST APIバッチ処理への不審なリクエストが残っていないか。

3つ目を省略しないでください。パッチは入口を閉じるだけで、すでに作られた管理者アカウントを消してはくれません。そして、この3項目はあくまで一次確認です。不審なアカウント・ファイル・プラグイン・ログが見つかった場合は、認証情報の変更やサーバー環境の確認を含む追加調査が必要になります。

「プラグインさえ管理すれば」はどこまで信じてよいか

冒頭のとおり、脆弱性の多くがプラグインやテーマ由来という傾向は、いまも変わりません。プラグインの厳選には引き続き意味があります。

wp2shellが突きつけたのは、本体側の脆弱性が現実化したときの重さです。今回はプラグイン衛生をどれだけ徹底していても防げませんでした。影響を受けたのは、WordPressが標準で公開しているREST APIの処理そのものだったからです。

WordPressが悪いソフトウェアだ、と言いたいのではありません。Web全体の大きな割合を支えるソフトウェアであり、今回の修正版の提供も迅速でした。ただ、今回のように、検証処理が存在していても複数機能の間で前提やデータの対応が崩れると、別の脆弱性と連鎖して重大な影響につながることがあります。20年以上をかけて積み重なった大規模なPHPアプリケーションでは、こうした「機能どうしの噛み合わせ」の問題が起きる余地が構造的に残ります。

インターネットから到達できるコードや機能を減らし、権限境界を明確にすることは、攻撃対象領域と運用負荷を抑える重要な要素です。これが今回の事例から引き出せる、設計面での学びだと考えています。

KOIYALの見解。実際に「別の構え」でメディアを1つ作ってみた

ここからは自社の実験の話です。KOIYALは今週、オープンソース（MITライセンス）のCMS「EmDash」を使って、英語圏向けメディア accountabilitycareers.com を構築・公開しました。WordPressからの移行ではなく新規構築です。

EmDashは、公開画面をAstroで構築し、管理画面・API・認証・メディアライブラリといった動的処理をCloudflare Workers上で実行できます。コンテンツはD1（データベース）、画像はR2（ストレージ）に置かれる構成です。WordPressのようにPHPアプリケーション全体を各リクエストで動かす構成とは異なります。wp2shellの文脈で意味を持つ違いは、3つありました。

第一に、公開画面と動的処理が分かれている。公開ページはAstroが担い、管理画面やAPIはWorker上で動きます。全リクエストにデータベース接続付きで応答する巨大なPHPアプリケーションが常時前面に立つ、という構成ではありません。攻撃面の持ち方が異なります。

第二に、プラグインを信用しない前提の設計。ここは少しかみ砕いて説明します。WordPressのプラグインは「サイトの全権限」で動きます。1つのプラグインが乗っ取られると、他人の記事もデータベースも触れてしまう。今回のwp2shellで被害が全損になりやすかったのも、最終段が「何でもできるプラグインのアップロード」だったからです。

EmDashは逆で、プラグインを「檻（サンドボックス）」の中で動かします。プラグインは事前に「私は記事の読み取りとメール送信だけします」と申告し、EmDashはそれ以外の操作を物理的に禁止します。檻の外にあるファイルや他のデータ、管理者権限には手が届きません。だから1つのプラグインがやられても、被害がその檻の中で止まりやすい。これがサンドボックス実行です。プラグインが使える権限を限定するこの設計は、侵害時の影響範囲を抑えやすくします。

第三に、パスキーを優先した認証設計。管理画面はパスキーを優先し、OAuthやマジックリンクもフォールバックとして用意されています。パスワードの使い回しやリスト型攻撃に由来するリスクを抑えられます。

このサンドボックス実行にはCloudflareの有料プラン（月5ドル程度）が要ります。ただし、これはあくまでプラグインを檻の中で動かす場合の費用です。プラグインを使わない構成（記事を書いて公開するだけのブログやコーポレートサイト）なら、サンドボックスは不要で、Cloudflareの無料プランでも運用できます。「必要な人だけが払う」設計です。

公平のために、その他の不利な点も書いておきます。EmDashはまだベータプレビューで、プラグインのエコシステムは小さいです。実際、構築中にドキュメントと実挙動の食い違いも踏みました。ECサイトのように機能の深いプラグインへ依存するサイトには、現時点では勧めません。一方で、ブログ・オウンドメディア・コーポレートサイトのように「記事を書いて公開する」ことが中心のサイトなら、検討候補になり得ます。

URLだけで一次診断できる無料ツールを公開しました

「自社サイトが今どうなのか、まず知りたい」という方向けに、無料のWordPress移行診断ツールを公開しました。サイトのURLを入力すると、外部から見える情報だけで3点を返します。①今wp2shellは大丈夫か、②別のWeb基盤へ置き換えるべきか、③置き換えた場合の初期費用と月額の目安、の3つです。登録は不要です。

一次診断なので限界もあります。多くのサイトはWordPressのバージョンを外部に公開しておらず、その場合は「要確認（管理画面で確認してください）」という表示です。それでも、WordPressかどうか、EC等で対象外か、記事の規模感といった当たりはつくはずです。

次の行動

今週やるべきことは冒頭の3つに尽きます。更新、暫定遮断、一次確認。ここまでは待ったなしです。

そのうえで、少し先を見た問いを1つ持ち帰ってください。「自社サイトを支えているソフトウェアのうち、インターネットに公開している機能はどれだけ必要か」。WordPressを使い続ける判断も、構えを変える判断も、この問いに答えてからのほうが精度が上がります。

KOIYALでは、WordPressサイトの脆弱性対応状況の確認から、継続と移行の比較（1枚のアーキテクチャ評価から着手）、移行後の計測基盤の再構築までを支援しています。この機会にWeb基盤を見直したい方は、お気軽にご相談ください。

出典・参考

一次情報:

参考記事: