WordPress 本体で危険度の高い脆弱性 wp2shell-公開エクスプロイトとサイバー攻撃への悪用が発生|セキュリティニュースのセキュリティ対策Lab

投稿日時: 2026年07月19日更新日時: 2026年07月19日

WordPressは2026年7月17日、緊急のセキュリティリリースとしてバージョン7.0.2を公開し、致命的(Critical)な脆弱性1件と高深刻度(High)の脆弱性1件を修正しました。この2つの脆弱性を組み合わせた攻撃手法は「wp2shell」と呼ばれ、未認証の攻撃者がプラグインを一切導入していない標準的なWordPressサイトに対しても、事前条件なしでリモートコード実行を達成できるというものです。翌18日には公開の概念実証(PoC)コードが多数出回り、セキュリティ企業watchTowrは実際の悪用の兆候もすでに確認していると報告しています。

サマリー

WordPressは2026年7月17日、バージョン7.0.2を緊急のセキュリティリリースとして公開した。深刻度の高さから、対象バージョンを稼働させているサイトに対し、自動更新システムを通じた強制アップデートが有効化されている
修正された2件の脆弱性は、WordPress 6.9で導入されたREST APIのバッチルート混同の脆弱性(CVE-2026-63030)と、WP_Queryの「author__not_in」パラメータにおけるSQLインジェクションの脆弱性(CVE-2026-60137、WordPress 6.8以降に影響)。この2つを連鎖させることで、未認証のままリモートコード実行(RCE)を達成できる
この攻撃連鎖は「wp2shell」と呼ばれ、発見者であるSearchlight Cyber(Assetnote)のAdam Kues氏によれば、事前条件は一切なく、プラグインを何も導入していない標準的なWordPressサイトに対しても、匿名の攻撃者が悪用できるとされている
完全なRCE連鎖の影響を受けるのはWordPress 6.9.0〜6.9.4および7.0.0〜7.0.1。SQLインジェクション単体はWordPress 6.8.0〜6.8.5にも影響するが、バッチルート混同の脆弱性が導入されたのは6.9からであるため、6.8系ではRCEへの連鎖は成立しない。6.8より前のバージョンは影響を受けない
修正版は7.0.2および6.9.5で提供されているほか、6.8系にはSQLインジェクション単体の修正を含む6.8.6が、開発中の7.1ベータにも両方の修正を含むbeta2が、それぞれバックポートされている
Searchlight Cyberは管理者にパッチ適用の猶予を与えるため技術的詳細を当初公開せず、代わりに自サイトの脆弱性有無を確認できる「wp2shell.com」を用意していたが、その後GitHub上に複数の公開概念実証(PoC)コードが公開された。一部のPoCはSQLインジェクションでパスワードハッシュを窃取し管理者パスワードを解読してログインする手法だが、別のPoCは管理者権限を必要としない、より深刻な未認証RCEを実演しているとされる
セキュリティ企業watchTowrの最高経営責任者Benjamin Harris氏は、公開エクスプロイトの流通に加え、実際の悪用(in-the-wild exploitation)の初期兆候もすでに確認していると述べている
即時アップデートが困難な場合の暫定的な緩和策として、REST APIへの匿名アクセスを完全にブロックするプラグインの導入、またはWAFレベルで「/wp-json/batch/v1」と「?rest_route=/batch/v1」をブロックする方法が挙げられている。Cloudflareは無料プランを含む全プランのCloudflare経由サイトに対し、この2つの脆弱性を対象にしたWAF保護ルールをすでに展開している

項目	内容
WordPress緊急リリース日	2026年7月17日(バージョン7.0.2)
修正されたCVE	CVE-2026-63030(REST APIバッチルート混同)、CVE-2026-60137(SQLインジェクション)
攻撃連鎖の呼称	wp2shell
発見者	Adam Kues氏(Searchlight Cyber/Assetnote)
悪用条件	未認証・事前条件なし・プラグイン未導入の標準サイトでも悪用可能
影響を受けるバージョン(RCE連鎖)	WordPress 6.9.0〜6.9.4、7.0.0〜7.0.1
影響を受けるバージョン(SQLi単体)	WordPress 6.8.0〜6.8.5(RCEへの連鎖は不成立)
修正版	7.0.2、6.9.5、6.8.6(SQLiのみ)、7.1 beta2
WordPressの推定利用サイト数	5億超(Searchlight Cyber推計)
公開PoCの有無	あり(GitHub上に複数公開)
実際の悪用の有無	watchTowrが初期兆候を確認済み

1 何が起きたか-2つの脆弱性を連鎖させる「wp2shell」
2 公開概念実証コードの流通と実際の悪用
3 暫定的な緩和策とCloudflareの対応
4 情報システム部門への示唆
5 出典

何が起きたか-2つの脆弱性を連鎖させる「wp2shell」

WordPressの公式発表によれば、7.0.2は致命的(Critical)な脆弱性1件と高深刻度(High)の脆弱性1件を修正するセキュリティリリースです。深刻度の高さから、対象バージョンを稼働させているサイトに対しては、自動更新システムを通じた強制アップデートがすでに有効化されています。手動で更新する場合は、WordPressダッシュボードの「更新」から「今すぐ更新」をクリックするか、WordPress.orgから直接ダウンロードすることが案内されています。

この問題は単一の脆弱性ではなく、2つの独立した欠陥を組み合わせることで、未認証のリモートコード実行連鎖を構成するというものです。1つ目のCVE-2026-63030は、WordPress 6.9で導入されたREST APIのバッチルート機能における混同の脆弱性です。GitHubのセキュリティアドバイザリによれば、この欠陥はSQLインジェクションの問題と組み合わせることでリモートコード実行を達成できるとされています。2つ目のCVE-2026-60137は、WP_Queryの「author__not_in」パラメータにおけるSQLインジェクションの脆弱性で、WordPressはこれをWordPress 6.8以降に影響する高深刻度の脆弱性だと説明しています。

セキュリティ企業Searchlight Cyberの研究チームは、この攻撃を「WordPressコアにおける未認証前のRCE」と表現し、「この攻撃には事前条件が一切なく、プラグインを何も導入していない標準的なWordPressサイトに対しても、匿名の利用者によって悪用されうる」と説明しています。Searchlight Cyberは、WordPressが世界で5億を超えるウェブサイトに利用されていると推計しており、今回の脆弱性の潜在的な影響範囲は極めて大きいとしています。

完全なRCE連鎖の影響を受けるのはWordPress 6.9.0から6.9.4まで、および7.0.0から7.0.1までです。

SQLインジェクションの脆弱性単体はWordPress 6.8.0から6.8.5までにも影響しますが、REST APIのバッチルート混同の脆弱性が導入されたのはバージョン6.9からであるため、6.8系ではRCEへの連鎖は成立しません。6.8より前のバージョンは影響を受けないとされています。完全なwp2shell攻撃連鎖は、WordPress 6.9.5および7.0.2で修正されています。

公開概念実証コードの流通と実際の悪用

Searchlight Cyberは当初、管理者にパッチ適用の猶予を与えるため技術的な詳細の公開を控え、代わりに自サイトが脆弱かどうかを確認できるウェブサイト「wp2shell.com」を公開していました。しかしその後、GitHub上に複数の公開概念実証(PoC)エクスプロイトが公開されています。一部の公開PoCは、SQLインジェクションを通じてWordPressのパスワードハッシュを抽出し、管理者パスワードを解読してログインしたうえで、悪意あるプラグインをアップロードしコマンドを実行するという手順を組み合わせたものです。一方で、別の公開PoCは、管理者の認証情報を必要としない未認証でのリモートコード実行を達成すると主張しており、これはSearchlight Cyberが当初説明していた脆弱性の性質とより一致しています。

セキュリティ企業watchTowrの最高経営責任者Benjamin Harris氏はBleepingComputerに対し、「WordPressはセキュリティ面で悪評を買いがちだが、実際にはWordPressコアにおいて影響の大きい未認証のSQLインジェクションやリモートコード実行の脆弱性はかなり稀だ。だからこそ今回は事情が異なり、広範囲な悪用が本格化する前にパッチを適用しようと誰もが慌てているのだ」とコメントしています。同氏は、watchTowrのチームがすでに流通しているPoCエクスプロイトを確認しており、実際の悪用(in-the-wild exploitation)の初期兆候も見え始めていると述べています。

暫定的な緩和策とCloudflareの対応

即時のアップデートが困難な組織に向けて、Searchlight Cyberは、REST APIへの匿名アクセスを完全にブロックするプラグインを導入すること、またはWAFレベルで「/wp-json/batch/v1」および「?rest_route=/batch/v1」へのアクセスをブロックすることを、暫定的な緩和策として推奨しています。ただし同社は、これらの緩和策はあくまでシステムを更新できるまでの一時的な措置として利用すべきだと注意を促しています。

Cloudflareは、無料プランを含むCloudflare経由の全プランのサイトに対し、この2つの脆弱性を対象にしたWebアプリケーションファイアウォール(WAF)保護ルールをすでに展開したと発表しています。Cloudflareによれば、このルールはSQLインジェクションの脆弱性(CVE-2026-60137)とREST APIバッチルート混同の脆弱性(CVE-2026-63030)の両方を悪用しようとする試みをブロックするとしています。同社は「WAF保護は、顧客が更新を行う間の露出を減らすものであり、パッチ適用の代替にはならない」と述べています。

情報システム部門への示唆

当サイトでもこれまで、GravityForms・Sneeit Framework・Kali Forms・WP Ghost・GutenKit/Hunk Companionなど、WordPressの「プラグイン」に起因する脆弱性を数多く報じてきましたが、今回のwp2shellはWordPress「本体(コア)」に存在する脆弱性である点で、より広範かつ根本的な影響を持ちます。プラグインを一切使わないサイトであっても影響を受けるため、「プラグインの脆弱性対策だけをしていれば安全」という考え方は通用しません。

自組織でWordPressサイトを運用している場合は、まずバージョンが7.0.2または6.9.5(6.8系の場合は6.8.6)以降になっているかを直ちに確認してください。自動更新が有効な環境でも、更新が実際に適用されたかどうかをダッシュボード上で再確認することをお勧めします。多数のWordPressサイトを組織内・クライアント向けに運用している制作会社・ホスティング事業者は、管理下の全サイトのバージョン状況を一括で把握できる仕組み(WP-CLIを用いたスクリプトや管理ツール等)を整備し、優先度の高いサイトから速やかにアップデートを適用する体制が重要です。アップデートが即座に行えない事情がある場合は、Cloudflare等のWAFを経由している場合はその保護ルールの有効化状況を確認し、経由していない場合は自前のWAFで該当エンドポイントへのアクセスを一時的に遮断する等、暫定的な緩和策を直ちに講じることをお勧めします。公開PoCと実際の悪用の兆候がすでに確認されている以上、対応の先送りは避けるべきです。