WordPressコアに認証不要の重大な脆弱性「wp2shell」

2026年7月17日、WordPressコアに存在する重大なセキュリティ脆弱性が公表され、修正版となるWordPress 7.0.2、6.9.5、6.8.6が公開されました。

特にWordPress 6.9系および7.0系では、複数の脆弱性を組み合わせることにより、ログインしていない第三者がサーバー上で任意のコードを実行できる可能性があります。

この攻撃手法は、発見したSearchlight Cyberにより「wp2shell」と呼ばれています。

今回の問題はプラグインやテーマではなく、WordPress本体に存在します。そのため、脆弱なバージョンを使用している場合、プラグインをほとんど導入していないサイトや、WordPressを初期状態に近い構成で使用しているサイトも影響を受ける可能性があります。

結論：対象バージョンは直ちに更新してください

見出し

1 結論：対象バージョンは直ちに更新してください
2 wp2shellとは
- 2.1 CVE-2026-60137
- 2.2 CVE-2026-63030
3 なぜ危険なのか
4 PoCは公開されているのか
5 WordPress公式は強制自動更新を有効化
6 現在のWordPressバージョンを確認する方法
7 推奨する対応手順
8 すぐに更新できない場合の一時的な緩和策
9 すでに攻撃されていないか確認する
10 自動更新されたサイトでも確認は必要
11 制作会社・保守会社が取るべき対応
12 よくある質問
13 まとめ

WordPress 6.9.0から6.9.4、または7.0.0から7.0.1を使用している場合は、次の修正版へ更新してください。

現在のバージョン	対応
WordPress 7.0.0～7.0.1	7.0.2へ更新
WordPress 6.9.0～6.9.4	6.9.5へ更新
WordPress 6.8.0～6.8.5	6.8.6へ更新
WordPress 6.7以前	今回公表された2件の対象外

WordPress 6.8系は、後述するSQLインジェクションの影響を受けますが、今回の「wp2shell」と呼ばれるリモートコード実行の連鎖には該当しません。

WordPress公式は、6.9系が2件の脆弱性、6.8系がSQLインジェクションのみの影響を受けると説明しています。WordPress 6.7以前は今回の脆弱性の影響を受けません。

wp2shellとは

wp2shellは、主に次の2件の脆弱性を組み合わせた攻撃です。

CVE-2026-60137

WordPressのWP_Queryに存在するSQLインジェクションの脆弱性です。

影響を受けるバージョンは次のとおりです。

WordPress 6.8.0～6.8.5
WordPress 6.9.0～6.9.4
WordPress 7.0.0～7.0.1

修正版は6.8.6、6.9.5、7.0.2です。

CVE-2026-63030

WordPress REST APIのバッチ処理におけるルート混乱の脆弱性です。

この問題と前述のSQLインジェクションを組み合わせることにより、WordPress 6.9系および7.0系では、認証されていない第三者によるリモートコード実行につながる可能性があります。

影響を受けるバージョンは次のとおりです。

WordPress 6.9.0～6.9.4
WordPress 7.0.0～7.0.1

修正版は6.9.5および7.0.2です。WordPress公式のセキュリティアドバイザリーでは、この脆弱性を「Critical」と評価しています。

なぜ危険なのか

今回の脆弱性が危険視されている理由は、攻撃にログインを必要としないことです。

Searchlight Cyberによると、攻撃には事前条件がなく、プラグインを導入していない標準状態のWordPressでも悪用される可能性があります。

悪用された場合、攻撃者により次のような被害が発生する可能性があります。

不正なPHPファイルやWebシェルの設置
WordPress管理者アカウントの追加
データベース内の情報の閲覧・改ざん
サイトの改ざん
不正なリダイレクトの埋め込み
マルウェア配布サイトへの悪用
同一サーバー上にある他サイトへの侵害拡大
個人情報や顧客情報の漏えい
サーバーを踏み台とした外部への攻撃

単なる情報漏えいではなく、サイトやサーバー自体を攻撃者に操作される可能性があるため、通常のWordPress脆弱性よりも高い緊急度で対応する必要があります。

PoCは公開されているのか

公表直後、Searchlight Cyberは防御側に更新時間を与えるため、詳細な技術情報や攻撃コードを公開していませんでした。

しかし、2026年7月18日時点では、修正パッチの解析をもとにした技術情報と、動作する概念実証コードの一部が第三者から公開されたと報じられています。

つまり、現在は専門的な解析能力を持つ攻撃者だけでなく、公開された情報を利用して攻撃を自動化する者が現れる可能性が高まっています。

2026年7月18日時点では、大規模な実攻撃が確認されたとは公表されておらず、CISAのKnown Exploited Vulnerabilities Catalogにも掲載されていないと報じられています。

ただし、一部PoCが公開された以上、「実際の攻撃が確認されてから対応する」という判断は適切ではありません。

WordPress公式は強制自動更新を有効化

WordPress公式は、今回の問題の重大性を踏まえ、影響を受けるバージョンに対して自動更新システムを利用した強制更新を有効化したと発表しています。

自動バックグラウンド更新に対応したサイトでは、更新処理が自動的に開始されます。

一般的なWordPress環境では、セキュリティおよびメンテナンス目的のマイナーアップデートは、初期状態で自動更新の対象です。

ただし、次のような環境では自動更新に失敗する可能性があります。

WordPressファイルに書き込み権限がない
ファイル所有者が実行ユーザーと一致していない
WordPress.orgへの外部通信が遮断されている
FTP認証情報の入力が必要な構成
GitやSVN等のバージョン管理下で自動更新が抑制されている
更新制御用のプラグインや独自フィルターが導入されている
ディスク容量が不足している
更新途中でプロセスが停止した
自動更新機能が明示的に無効化されている

WordPress公式ドキュメントでは、AUTOMATIC_UPDATER_DISABLEDをtrueにすると、コアを含むすべての自動更新が無効になると説明されています。

今回の「強制更新」が、この設定を必ず無視して実行されるかについては、公式発表だけでは明確ではありません。したがって、「強制更新があるから確認しなくてよい」とは判断せず、実際のバージョンを確認してください。

現在のWordPressバージョンを確認する方法

管理画面から確認する

WordPress管理画面にログインし、次の画面を開きます。

<span>ダッシュボード
→ 更新</span>

1 2	<span>ダッシュボード → 更新</span>

または、ダッシュボードの「概要」から現在のWordPressバージョンを確認します。

次のいずれかであれば修正済みです。

WordPress 7.0.2
WordPress 6.9.5
WordPress 6.8.6

WP-CLIで確認する

<span>wp core version --path=/path/to/wordpress</span>

1	<span>wp core version --path=/path/to/wordpress</span>

ファイルから確認する

<span>grep "\$wp_version =" /path/to/wordpress/wp-includes/version.php</span>

1	<span>grep "\$wp_version =" /path/to/wordpress/wp-includes/version.php</span>

キャッシュされたHTMLやジェネレーター情報による外部判定は、実際のバージョンと一致しないことがあります。サーバー上のファイル、管理画面またはWP-CLIで確認する方法が確実です。

推奨する対応手順

1. バックアップを確認する

更新前に、少なくとも次のバックアップが取得されていることを確認してください。

WordPressファイル
wp-contentディレクトリ
データベース
.htaccess
Webサーバー設定
wp-config.php

ただし、バックアップ作業に長時間を要する場合でも、脆弱な状態を長期間放置すべきではありません。

2. WordPressコアを更新する

管理画面の「更新」から、WordPress本体を最新の修正版へ更新します。

WP-CLIを使用する場合は、通常次のように実行できます。

<span>wp core update --path=/path/to/wordpress</span>

1	<span>wp core update --path=/path/to/wordpress</span>

更新後にバージョンを確認します。

<span>wp core version --path=/path/to/wordpress</span>

1	<span>wp core version --path=/path/to/wordpress</span>

可能であれば、公式ファイルとの整合性も確認します。

<span>wp core verify-checksums --path=/path/to/wordpress</span>

1	<span>wp core verify-checksums --path=/path/to/wordpress</span>

3. サイトの基本動作を確認する

更新後は最低限、次を確認してください。

トップページ
下層ページ
WordPress管理画面
お問い合わせフォーム
会員ログイン
ECサイトのカートと決済
予約機能
REST APIを利用する外部連携
定期処理やバッチ処理

今回の更新はセキュリティ修正を目的とするマイナーアップデートですが、業務上重要な機能については確認を推奨します。

すぐに更新できない場合の一時的な緩和策

最善の対策はWordPress本体の更新です。

業務上の事情などにより直ちに更新できない場合、Searchlight Cyberは一時的な緩和策として、WAF等で次の両方を遮断する方法を案内しています。

<span>/wp-json/batch/v1</span>

1	<span>/wp-json/batch/v1</span>

<span>?rest_route=/batch/v1</span>

1	<span>?rest_route=/batch/v1</span>

片方だけを遮断しても不十分です。

WordPress REST APIには、通常のパーマリンク形式と、クエリ文字列を使用する形式があるため、両方を遮断する必要があります。

Nginxの設定例

各serverブロック内に適用する例です。

<span>location ~* ^/wp-json/+batch/+v1/?$ {
    return 403;
}

if ($args ~* "(^|&amp;)rest_route=(/|%2f)+batch(/|%2f)+v1/?(&amp;|$)") {
    return 403;
}</span>

location ~* ^/wp-json/+batch/+v1/?$ {

return 403;

}

if ($args ~* "(^|&)rest_route=(/|%2f)+batch(/|%2f)+v1/?(&|$)") {

return 403;

}

設定変更後は、必ず構文を確認します。

<span>nginx -t</span>

1	<span>nginx -t</span>

問題がなければNginxをreloadします。

<span>systemctl reload nginx</span>

1	<span>systemctl reload nginx</span>

古いOSなどでsystemdを使用していない場合は、環境に応じて次を使用します。

<span>service nginx reload</span></code><code dir="ltr"><span></span>

1	<span>service nginx reload</span></code><code dir="ltr"><span></span>

Apacheの.htaccess設定例

WordPressの.htaccessで対応する場合、# BEGIN WordPressより前に追加します。

<span># Temporary mitigation: block WordPress Batch REST API
&lt;IfModule mod_rewrite.c&gt;
RewriteEngine On

RewriteRule ^wp-json/+batch/+v1/?$ - <span data-placeholder-token="true" class="text-token-text-primary cursor-text rounded-sm">[F,L,NC]</span>

RewriteCond %{QUERY_STRING} (^|&amp;)rest_route=(/|%2F)+batch(/|%2F)+v1/?(&amp;|$) <span data-placeholder-token="true" class="text-token-text-primary cursor-text rounded-sm">[NC]</span>
RewriteRule ^ - <span data-placeholder-token="true" class="text-token-text-primary cursor-text rounded-sm">[F,L]</span>
&lt;/IfModule&gt;</span>

# Temporary mitigation: block WordPress Batch REST API

RewriteEngine On

RewriteRule ^wp-json/+batch/+v1/?$ - [F,L,NC]

RewriteCond %{QUERY_STRING} (^|&)rest_route=(/|%2F)+batch(/|%2F)+v1/?(&|$) [NC]

RewriteRule ^ - [F,L]

</IfModule>

# BEGIN WordPressと# END WordPressの間は、WordPressによって自動的に書き換えられる場合があります。独自ルールはその範囲外に記述してください。

遮断確認

次のリクエストがすべて403になることを確認します。

<span>curl -sS -o /dev/null -w '%{http_code}\n' \
  https://example.jp/wp-json/batch/v1

curl -sS -o /dev/null -w '%{http_code}\n' \
  'https://example.jp/?rest_route=/batch/v1'

curl -sS -o /dev/null -w '%{http_code}\n' \
  'https://example.jp/?rest_route=%2Fbatch%2Fv1'</span>

curl -sS -o /dev/null -w '%{http_code}\n' \

https://example.jp/wp-json/batch/v1

curl -sS -o /dev/null -w '%{http_code}\n' \

'https://example.jp/?rest_route=/batch/v1'

curl -sS -o /dev/null -w '%{http_code}\n' \

'https://example.jp/?rest_route=%2Fbatch%2Fv1'

通常のREST API全体が停止していないことも確認します。

<span>curl -sS -o /dev/null -w '%{http_code}\n' \
  https://example.jp/wp-json/</span>

1 2	<span>curl -sS -o /dev/null -w '%{http_code}\n' \ https://example.jp/wp-json/</span>

対象エンドポイントだけが403となり、通常のREST APIは従来どおりの応答であれば、限定的な遮断ができています。

なお、この遮断は緊急時の一時対策です。正規のREST APIバッチ機能を使用しているシステムでは影響が発生する可能性があるため、WordPress本体の更新完了後は、必要性を確認したうえで解除してください。

すでに攻撃されていないか確認する

更新や遮断だけでなく、公表前後に侵害されていないかも確認する必要があります。

アクセスログの確認

次の文字列を検索します。

<span>grep -Ei \
  '/wp-json/+batch/+v1|rest_route=(%2F|/)+batch(%2F|/)+v1' \
  /var/log/nginx/access.log</span>

grep -Ei \

'/wp-json/+batch/+v1|rest_route=(%2F|/)+batch(%2F|/)+v1' \

/var/log/nginx/access.log

Apacheの場合は、環境に応じて次のようなログを確認します。

<span>grep -Ei \
  '/wp-json/+batch/+v1|rest_route=(%2F|/)+batch(%2F|/)+v1' \
  /var/log/httpd/access_log</span>

grep -Ei \

'/wp-json/+batch/+v1|rest_route=(%2F|/)+batch(%2F|/)+v1' \

/var/log/httpd/access_log

複数サイトを管理している場合は、VirtualHostごとのログも確認します。

ただし、このURLへのアクセスが記録されているだけで、侵害されたとは限りません。単純な脆弱性調査、セキュリティ製品の診断、検索エンジン、攻撃者による探索なども含まれます。

ファイル改ざんの確認

最近変更されたPHPファイルを確認します。

<span>find /path/to/wordpress \
  -type f \
  -name '*.php' \
  -mtime -3 \
  -ls</span>

find /path/to/wordpress \

-type f \

-name '*.php' \

-mtime -3 \

-ls

WordPressコアはチェックサム検証を行います。

<span>wp core verify-checksums --path=/path/to/wordpress</span>

1	<span>wp core verify-checksums --path=/path/to/wordpress</span>

プラグインについても、WordPress.orgで配布されているものは確認できる場合があります。

<span>wp plugin verify-checksums --all --path=/path/to/wordpress</span>

1	<span>wp plugin verify-checksums --all --path=/path/to/wordpress</span>

不審な管理者の確認

<span>wp user list \
  --role=administrator \
  --fields=ID,user_login,user_email,user_registered \
  --path=/path/to/wordpress</span>

wp user list \

--role=administrator \

--fields=ID,user_login,user_email,user_registered \

--path=/path/to/wordpress

見覚えのない管理者、最近追加された管理者、通常と異なるメールアドレスがないか確認します。

その他の確認項目

wp-content/uploads内のPHPファイル
wp-content/mu-plugins内の不審なファイル
wp-content/plugins直下の見覚えのないディレクトリ
wp-config.phpの不審な追記
.htaccessの不審なリダイレクト
WordPressのcronイベント
データベース内の不審なJavaScript
見覚えのない管理者・投稿・固定ページ
外部サイトへの不正転送
不審なPHPプロセスや外部通信

脆弱な期間中に不審なアクセスがあり、ファイル改ざんなども確認された場合、単に不審ファイルを削除するだけでは不十分です。

バックドアが複数設置されている可能性を考慮し、侵入経路の調査、認証情報の変更、正規ファイルからの復旧、ログ調査などを実施する必要があります。

自動更新されたサイトでも確認は必要

WordPress公式による強制自動更新は、多くのサイトを短時間で保護するうえで非常に有効です。

ただし、自動更新されたという事実は、更新前に攻撃されていなかったことを証明するものではありません。

更新後も、少なくとも次を確認してください。

現在のWordPressバージョン
更新が完了した日時
更新前後のアクセスログ
WordPressコアのチェックサム
最近変更されたPHPファイル
管理者アカウント
サイトの表示と外部転送
バックアップの取得状況

制作会社・保守会社が取るべき対応

複数のWordPressサイトを管理している事業者は、個別の連絡を待つのではなく、管理対象を一覧化して対応状況を記録することを推奨します。

最低限、次の項目を管理します。

項目	内容
ドメイン	対象サイト
更新前バージョン	6.9.4、7.0.1など
更新後バージョン	6.9.5、7.0.2など
更新日時	実施日時
自動・手動	更新方法
一時遮断	実施の有無
動作確認	フォーム、EC、会員機能等
改ざん確認	チェックサム、管理者、ログ
備考	更新失敗、権限問題等

また、営業時間外や休日に重大な脆弱性が公表される可能性を考慮し、あらかじめ次を決めておくことが重要です。

緊急対応の判断基準
顧客への連絡方法
コアのセキュリティ更新を自動化するか
WAFで共通遮断できる体制
サーバーごとの設定変更手順
ロールバック方法
バックアップの保存先
改ざん検知と通知方法
営業時間外対応の契約範囲

よくある質問

プラグインを更新すれば直りますか

いいえ。今回の問題はWordPress本体に存在するため、プラグインだけを更新しても修正されません。

WordPressコアを6.9.5、7.0.2または6.8.6へ更新してください。

セキュリティプラグインを入れていれば安全ですか

製品によっては攻撃通信を遮断できる可能性がありますが、すべてのセキュリティプラグインが今回の攻撃を防げるとは限りません。

修正版への更新が必要です。

REST API全体を無効化すべきですか

緊急対応としては有効な場合がありますが、ブロックエディタ、フォーム、外部連携、会員機能、EC機能などに影響する可能性があります。

可能であれば、問題となるバッチAPIの2経路だけを限定的に遮断し、早急にWordPress本体を更新してください。

6.8系もRCEの対象ですか

今回公表されたwp2shellのRCE連鎖は、WordPress 6.9系以降が対象です。

WordPress 6.8.0～6.8.5はSQLインジェクションの影響を受けますが、同じ経路によるRCEの対象とはされていません。それでも6.8.6への更新が必要です。

強制自動更新を待ってもよいですか

多くの標準的なWordPressサイトでは自動更新が実行される可能性が高いものの、更新失敗や設定上の理由で適用されないサイトもあります。

待つのではなく、現在のバージョンを確認し、未更新なら手動で対応してください。

一時遮断後も更新は必要ですか

必要です。

エンドポイントの遮断は緊急時の一時的な対策であり、WordPress本体の脆弱性を修正するものではありません。

まとめ

今回公表されたwp2shellは、WordPress本体に存在する認証不要の重大な脆弱性です。

特にWordPress 6.9.0～6.9.4および7.0.0～7.0.1では、SQLインジェクションとREST APIの問題を組み合わせることにより、第三者に任意のコードを実行される可能性があります。

対応の要点は次のとおりです。

WordPress 7.0.0～7.0.1は7.0.2へ更新する
WordPress 6.9.0～6.9.4は6.9.5へ更新する
WordPress 6.8.0～6.8.5は6.8.6へ更新する
自動更新済みと思い込まず、実際のバージョンを確認する
更新できない場合は、バッチAPIの2経路を一時遮断する
/wp-json/batch/v1と?rest_route=/batch/v1の両方を遮断する
更新後もログ、ファイル、管理者アカウントを確認する
不審な変更がある場合は、単純なファイル削除ではなく侵害調査を行う

公開されたPoCを利用した自動攻撃が始まる可能性を考慮し、対象バージョンを使用している場合は、可能な限り早急に対応してください。