はじめに
2026年7月17日、WordPress本体に緊急のセキュリティリリース（6.9.5 / 7.0.2）が公開されました。通称「wp2shell」と呼ばれる攻撃手法に対する修正で、プラグインを一切入れていない標準構成でも、未認証の第三者によるサイト乗っ取り（RCE）に至りうるという点で深刻です。
本記事では、情報システム担当・サイト運用者が実務でそのまま使える形で、バージョン確認 → 更新 → 侵害痕跡の点検 → 暫定緩和策 → 恒久対策の手順を整理します。
本記事は2026年7月20日時点の公開情報に基づきます。悪用状況の評価は情報源により異なります。実施前に必ず公式リリースノートと最新の注意喚起を確認してください。
脆弱性の概要
wp2shellは、単独では致命的でない2つの不具合を連鎖させる攻撃です。
| CVE | 内容 |
|---|---|
| CVE-2026-63030 | REST APIのバッチ処理で、リクエストと権限チェックの対応がずれ、本来権限が必要な処理を認証なしで呼び出せる |
| CVE-2026-60137 | 投稿検索の内部処理におけるSQLインジェクション |
この2つを組み合わせると、未認証の第三者が「DBから管理者情報を取得 → 管理者アカウント作成 → コード実行」という経路を通れます。認証不要・プラグイン不要・ユーザー操作不要です。
影響バージョンと修正版：
- 攻撃が成立するバージョン：6.9.0〜6.9.4 / 7.0.0〜7.0.1
- 修正版：6.9.5 / 7.0.2（SQLインジェクション単体は 6.8.6 でも修正）
WordPressはオープンソースのため、パッチの差分自体が攻撃者にとっての「設計図」になります。修正公開直後からスキャンボットが未適用サイトを無差別に探し始めるのが通例で、今回もパッチ公開当日に悪用の試みを観測したとする報告があります（評価が分かれる報告もあり、大規模被害が確認されたと断定できる段階ではありません）。「小さいサイトだから狙われない」は成り立ちません。
手順1：バージョンを確認する
WP-CLIが使える環境なら：
wp core version
WP-CLIがない場合は、ドキュメントルートで直接確認できます：
grep "wp_version =" wp-includes/version.php
管理画面なら「ダッシュボード → 更新」でも確認できます。6.9.0〜6.9.4 / 7.0.0〜7.0.1 なら該当です。
手順2：修正版へ更新する
更新前にバックアップを取得します：
# DBバックアップ
wp db export backup-$(date +%Y%m%d).sql
# ファイル一式（例）
tar czf ../wp-backup-$(date +%Y%m%d).tar.gz .
コアを更新し、適用結果を確認します：
wp core update
wp core update-db
wp core version # 6.9.5 / 7.0.2 以降になっていることを目視確認
メジャーバージョンを上げたくない場合はバージョン指定も可能です：
wp core update --version=6.9.5
つまずきどころ：自動更新の「つもり」
- 自動更新を明示的に無効化しているサイトは強制更新の対象外です。
wp-config.phpに以下の記述がないか確認してください：
define( 'AUTOMATIC_UPDATER_DISABLED', true ); // ←これがあると自動更新されない
define( 'WP_AUTO_UPDATE_CORE', false ); // ←同上
- 自動更新が有効でも、テーマ・プラグインとの相性やファイル権限の問題で止まっていることがあります。「有効にしてあるから大丈夫」ではなく、実際に修正版が当たったかを必ず確認してください。
手順3：侵害の痕跡を点検する
更新しただけで安心せず、更新前に既に侵入されていないかを点検します。
身に覚えのない管理者アカウント：
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
作成日時が最近の見覚えのないアカウントがないか確認します。
コアファイルの改ざん：
wp core verify-checksums
最近変更・追加されたPHPファイル：
# 直近7日で変更されたPHP（キャッシュ除外）
find . -name "*.php" -mtime -7 -not -path "./wp-content/cache/*"
# uploads配下のPHP（本来存在しないはず）
find wp-content/uploads -name "*.php"
あわせて、Webサーバのアクセスログで /wp-json/ 宛の不審なPOSTリクエストや、見慣れないリダイレクトの有無も確認します。
侵害が疑われる場合、更新だけでは元に戻りません。攻撃者はバックドア（裏口）を仕込むため、最新化しても裏口は残ります。公開を一時停止し、クリーンなバックアップからの復旧・漏えい範囲の調査・パスワードと認証キーの全面変更を優先してください。個人データの漏えいが確認されれば、個人情報保護法上の報告・本人通知義務が生じえます。
認証キー（ソルト）の再生成はWP-CLIで一発です（全ユーザーのログインセッションが無効化されます）：
wp config shuffle-salts
手順4：すぐ更新できない場合の暫定緩和策
検証環境の都合等で即時更新が難しい場合は、多層で時間を稼ぎます。いずれも更新の代替にはなりません。
- WAF（Cloudflare WAF、Wordfence等）のマネージドルールを有効化し、該当攻撃のシグネチャ遮断を確認する
- 管理画面へのアクセス元を制限する（nginxの例。IPはドキュメント用の例示）：
location = /wp-login.php {
allow 203.0.113.0/24; # 自社の固定IP等に置き換え
deny all;
include fastcgi_params;
fastcgi_pass php-fpm;
}
REST API（/wp-json/）の全面遮断は、テーマ・プラグイン・ブロックエディタの動作を壊すことがあるため、遮断範囲は検証のうえ判断してください。
恒久対策：「放置」が起きない運用へ
今回のようにプラグインゼロの標準構成でも本体だけで攻撃が成立する以上、「余計なものを入れていないから安全」とは言えません。個別の脆弱性を追いかけ続けるより、放置が起きにくい形に運用を寄せるのが本質的な対策です。
- 自動更新＋適用確認：自動更新を有効にしたうえで、適用結果を定期確認する
- WAFで入口を遮断：既知攻撃をパッチ適用前でも止められる層を持つ
- 管理画面の到達範囲を限定：IP制限・Basic認証・ゼロトラストアクセス等
- 攻撃面を減らす：未使用のテーマ・プラグインは無効化でなく削除
- バックアップ＋復旧テスト：「戻せること」を定期的に実際に確認する
適用確認の自動化の一例として、cronで更新有無を通知させておくと「気づかない放置」を防げます：
# 毎朝9時にコア更新の有無をチェック（例）
0 9 * * * cd /var/www/html && /usr/local/bin/wp core check-update 2>&1 | mail -s "WP update check" admin@example.com
まとめ
- wp2shellは未認証・プラグイン不要・標準構成で成立する連鎖攻撃。6.9.0〜6.9.4 / 7.0.0〜7.0.1 が対象、修正版は 6.9.5 / 7.0.2
- パッチ公開＝攻撃側への設計図公開。「まだ被害報告が少ないから」は先延ばしの理由にならない
- 更新は数分、侵害後の復旧は数週間。バージョン確認 → 更新 → 侵害点検までをワンセットで
- 自動更新は有効化＋適用の目視確認まで。無効化サイトは強制更新の対象外
WordPressに限らず、公開されているサービスは「作って終わり」ではなく「守り続ける」対象です。
株式会社ブレインディレクションは、ITソリューション・生成AI・クラウド・セキュリティ分野でお客様を支援するISMS取得企業です → https://www.brain-d.jp