8月12日、WordPressに7.0.4が出ました。7月のwp2shell、8月のXSS2Shellに続く、1か月足らずで三度目のセキュリティリリースです。起点となったwp2shellが通ったのは、管理画面ではなくREST APIのバッチ処理エンドポイントでした。守るべき場所が動いています。
WordPressコアのセキュリティリリースは、2026年7月17日の7.0.2から8月12日の7.0.4まで、1か月足らずで三度に及んだ。起点は認証前のリモートコード実行へ至る脆弱性の連鎖「wp2shell」である。REST APIのバッチルート混同（CVE-2026-63030）とSQLインジェクション（CVE-2026-60137）を組み合わせる手法で、報告したのはSearchlight Cyberのアダム・キューズ。
同社は暫定策として、未認証ユーザーのAPI利用を止めるプラグイン導入、WAFによる該当エンドポイントの遮断、バッチルートのみ認証を要求する自作プラグインの三つを示した。
From: 
wp2shell: Pre Authentication RCE in WordPress Core
【編集部解説】
まず、お使いのWordPressが7.0.4になっているかを確認してください。7月のwp2shellを修正した7.0.2のあと、8月6日にXSS2Shellなどを修正した7.0.3、さらに8月12日には別のセキュリティ問題を修正した7.0.4が公開されています。1か月足らずで、三度です。
そのうえで、7月に起きたことをもう一度見ておきたいと思います。
wp2shellが通ったのは、管理画面ではありませんでした。/wp-json/batch/v1という、REST APIのバッチ処理エンドポイントです。
このエンドポイントには三つの性質があります。WordPressコアの一部であること。初期状態で有効であること。そして、ログインしなくても到達できること。パーマリンクの設定を切っていても?rest_route=/batch/v1の形で届きます。
ログインも、追加のプラグインも、特殊な設定も要りませんでした。責任を分け合える第三者が、今回はいなかったということです。もっとも、どんな環境でも一発で成立するとまでは言えず、成立条件は構成によって変わります。
私が引っかかったのは、緩和策のほうでした。
Searchlight Cyberは、更新までの暫定策を三つ挙げています。未認証ユーザーのAPI利用を止めるプラグインを入れる。WAFで/wp-json/batch/v1とrest_route=/batch/v1の両方を遮断する。あるいは、バッチルートに限って認証を要求する小さなプラグインを自作する——そのコードまで公開されています。
なおWordfenceは、有料版向けには7月17日にwp2shellを狙う攻撃を遮断するWAFルールを提供しており、Free版には30日遅れの8月16日に同じ保護を提供するとしています。コアの更新に代わるものではありませんが、Free版利用者には確認しておきたい日付です。
三つとも、「APIのどこを、誰に開くか」の話しかしていません。管理画面をどうするかという選択肢は、一つもない。
ここが今回の勘所だと思います。
昨年10月、Malwarebytesが自社のデジタルエクスペリエンスプラットフォームにWordPressを選んだ理由を公開しました。提言は明快で、初日からヘッドレスで始め、管理プレーンを隔離せよ、というもの。WordPressをコンテンツ作成ハブに据え、APIがNext.jsやReactで作られたサイト、モバイルアプリ、サポートポータルを駆動する。管理画面はプライベートネットワークの内側に置く。
この設計は、当時も今も妥当です。セキュリティ企業が自社サイトの土台にWordPressを選び、その理由を技術的に開示したこと自体、この分野では貴重な資料でした。同社はプラグインを第三者コードとして扱い、監査と監視とSLAつきのパッチ適用の対象にせよとも書いています。
ただ、今回に限って言えば、管理プレーンの隔離は効きも障りもしませんでした。攻撃は管理画面を通らなかったので、隠しても防げない。効いたのは、エンドポイント単位の制御だけです。
攻撃面の重心が、管理画面からAPIへ移った。7月の出来事の意味は、そこにあると考えています。
とはいえ「APIは隠せない」と一般化するのは、正確ではありません。
配信のたびにWordPressのAPIを叩く構成なら、そのAPIを単純に閉じることはできない。閉じたらサイトが止まります。一方、静的サイト生成のようにビルド時だけCMSに接続し、公開時は生成済みのファイルだけを配る構成なら、APIを公開経路から外せます。Next.jsのstatic exportも、Astroの既定のプリレンダリングも、その形を正面からサポートしています。
つまり「ヘッドレスにしたから安全」でも「ヘッドレスだから危ない」でもない。配信時にAPIを叩くのか、ビルド時だけなのか。そこが分かれ目です。自分のサイトがどちらなのかを、まず知っておく必要があります。
そしてWordPressは今、そのAPIを意図的に広げています。
6.9でAbilities APIのPHP層が入り、7.0でJavaScript層とAI Clientがコアに加わりました。2月には公式のDeveloper Blogが、登録されたAbilitiesをMCPのツールとリソースへ変換するMCP Adapterを発表しています。コア本体ではなく、公式の別パッケージという位置づけです。自己ホスト環境の標準的なHTTP認証にはApplication Passwordsが使われ、OAuthなどを独自に実装することもできます。
これは後退ではなく前進だと思います。CMSがAIから使われる時代に向けて、WordPressプロジェクト自身が先頭を走っている。
同時に、開けた口の数だけ守る対象は増えます。MCPクライアントはログイン済みユーザーとして振る舞うため、最小権限のロール設計と permission_callback の書き方が、そのまま防御線になります。プラグインを第三者コードとして扱えというMalwarebytesの原則は、これからAPIエンドポイントにも適用されるべきものだと思います。
8月12日の7.0.4が塞いだのは、Author以上の権限を持つアカウントを必要とする脆弱性でした。未認証で入られるか、権限を持ったものに踏まれるか。7.0.2と7.0.4は、その両端を1か月のうちに見せたことになります。
ここで、はっきりさせておきたいことがあります。
これはWordPressだけの話ではありません。
4月にCloudflareが公開したEmDashは、各インスタンスがリモートMCPサーバーを備え、CLIからローカルまたはリモートのインスタンスを操作できます。microCMSはMCP経由のAI入稿を無料プランから開放しました。SanityにはSanity StudioというReact製の編集画面がありますが、配信はあくまでAPI経由です。
開かれた口をどう守るかという問いは、CMSを乗り換えても持ち越されます。wp2shellが示したのは、そのAPIが単一障害点になりうるという事実でした。移行は、この問題からの出口ではありません。
守るものが、城から門に変わった。門を全部閉じられる構成もあれば、開けたまま通す構成もある。開けたままなら、誰が通ったかを記録し、通れる範囲をあらかじめ狭めておくしかありません。
APIゲートウェイ、トークンの寿命、権限のスコープ、アクセスログ。CMSを選ぶ会話に出てこなかった語彙が、これからは最初のほうに入ってきます。
面倒が増えた、という話ではないと思っています。
管理画面を守るというのは、突き詰めれば「人間しか触らない」という前提の上に立つ防御でした。その前提が外れ、機械が正面から入ってくる。だから守り方を組み直す。それは、CMSがWebサイトの管理ツールから、コンテンツの流通基盤へと役割を変えつつあることの裏返しでもあります。
更新を済ませたら、次はご自分のサイトが、どのエンドポイントを、誰に向けて開いているかを一度書き出してみてください。その一覧が、これからのセキュリティ設計の出発点になります。
【関連記事】
WordPressコアに認証前RCE「wp2shell」、6.9／7.0系に影響 7.0.2などで修正
7月の公表を伝えた記事。強制自動更新が持つ意味と、更新を止めていたサイトが置かれた状況を扱っている。
WordPressにXSS2Shell、全バージョン影響 公式が緊急更新を呼びかけ
8月6日の7.0.3で修正された脆弱性の記事。wp2shellとの成立条件の違いについても整理している。
WordPress 7.1、AIに読まれるCMSへ ─ シェア41.5%が問う「エージェント時代の生き残り方」
AIエージェントへAPIを開こうとする設計思想と、市場シェアの推移を合わせて読める記事である。
CloudflareがCMS「EmDash」を発表
プラグインを隔離実行する設計の解説記事。WordPressのプラグイン構造との違いが分かりやすくまとめられている。
Malwarebytes、WordPressでエンタープライズDXPを構築
ヘッドレス構成で管理画面を隔離した事例の記事。本稿の出発点となった設計思想を詳しく紹介している。
【編集部後記】
7.0.4のリリースノートに、修正を4.7系までさかのぼって配るのは厚意としてだ、と書かれていました。同じ文のなかに、実際に支援されるのは最新版だけだとも記されています。
10年近く前のバージョンにまで手を伸ばしながら、それは約束ではないと明言する。この距離感が、4割のサイトを支えるということの実像なのだろうと思いました。
ご自分の管理するサイトが、その厚意の側に立っていないか。更新の前に一度確かめてみてください。
【用語解説】
ヘッドレス構成
コンテンツの保管と配信をAPIに任せ、表示側を別のプログラムで組む方式。管理画面と公開サイトを切り離せる。
バッチ処理エンドポイント
複数の操作をまとめて1回の通信で受け付ける接続口。WordPressでは /wp-json/batch/v1 にあたる。
管理プレーン
システムの設定や管理を担う領域。表示や配信を担う領域と分けて考える、設計上の区分である。
静的サイト生成
公開前にあらかじめHTMLを生成しておき、閲覧時にはできあがったファイルだけを配る方式。閲覧のたびにCMSへ接続しない。
Abilities API
WordPressの機能を、外部のプログラムやAIが呼び出せる単位として登録する仕組み。PHP層が6.9、JavaScript層が7.0で導入された。
MCP Adapter
登録されたAbilitiesを、AIエージェント向けの規格であるMCPのツールとリソースへ変換する公式パッケージ。コア本体には含まれない。
Application Passwords
WordPressが備える、外部アプリ向けの専用パスワード発行機能。本来のログインパスワードを渡さずに接続させる。
permission_callback
REST APIの各エンドポイントに対し、誰の呼び出しを許すかを判定する関数を指定する仕組み。
単一障害点
そこが壊れると全体が止まる箇所。
【参考リンク】
WordPress.org（外部）
WordPressの公式サイト。最新版の入手先と、セキュリティリリースの告知を掲載している。更新の要否はここで確認できる。
Searchlight Cyber（外部）
wp2shellを報告した英国のセキュリティ企業。攻撃対象領域の調査部門Assetnoteを持ち、研究成果を公開している。
wp2shell（外部）
Searchlight Cyberが公開した専用サイト。影響を受けるバージョンの一覧と、更新までの緩和策を三つ掲載している。
Malwarebytes（外部）
セキュリティ企業の公式サイト。自社サイトをヘッドレス構成で組んだ理由と設計思想について、技術ブログで詳しく公開している。
Wordfence（外部）
WordPress向けセキュリティプラグインの提供元。有料版と無料版でWAFルールの配信時期が異なることを公表している。
microCMS（外部）
日本製のAPIベースのヘッドレスCMS。料金体系と、プランごとに使える機能の対応表を公式サイト上で公開しているサービス。
【参考記事】
wp2shell: A pre-authentication RCE in WordPress core’s REST batch API（外部）
公開された修正差分からwp2shellの機序を再構成した技術解説。バッチAPIへの到達経路と検知方法を詳しく扱っている。
wp2shell WordPress Exploit: Technical Analysis and Real Attack Data（外部）
実際に観測された攻撃のデータを含む技術分析の記事。有料版と無料版とでWAFルールの配信時期が異なることも明記されている。
Exploitation in the Wild of wp2shell（外部）
wp2shellの実際の悪用を確認した調査報告。攻撃者による永続的なWebシェルの設置と、その検知の手法を記録している。
WordPress 7.0.4 Release（外部）
8月12日のセキュリティリリースの告知。Author以上の権限を要するRCEの修正内容と、即時の更新の推奨を伝えている。
Introducing EmDash（外部）
EmDashの発表記事。プラグインを隔離して実行する設計と、各インスタンスが備えるMCPサーバーについて説明している記事。
From Abilities to AI Agents: Introducing the WordPress MCP Adapter（外部）
WordPress公式の開発者向けブログ。MCP Adapterの位置づけと、対応する認証方式について解説している記事。
