WordPressの脆弱性というと、プラグインやテーマに見つかるものを思い浮かべる人が多いかもしれません。
実際、日常的に公開されている脆弱性情報の多くは、特定のプラグインやテーマに関するものです。しかし、2026年7月に公開された「WP2Shell」は、WordPress本体に存在する複数の脆弱性を組み合わせた攻撃です。
WordPressを利用している多くのサイトが影響を受ける可能性があり、修正版の公開直後から実際の攻撃が始まった点でも注意が必要です。
この記事では、Wordfenceが公開した情報をもとに、WP2Shellの概要とWordPressを安全に運用するために必要な対策を紹介します。
WP2Shellとは
WP2Shellは、WordPress本体に見つかった2つの脆弱性を組み合わせ、認証されていない攻撃者がサイトの管理者権限を取得できる攻撃です。
利用されるのは、次の2つの脆弱性です。
- SQLインジェクションの脆弱性（CVE-2026-60137）
- REST APIのバッチリクエストに関する脆弱性（CVE-2026-63030）
これらを組み合わせることで、ログインしていない攻撃者がWordPressに管理者アカウントを作成できる可能性があります。
管理者権限を取得されると、攻撃者は通常の管理者と同じようにプラグインやテーマをアップロードできます。悪意のあるプログラムを含むファイルを設置されれば、サイトの改ざんや情報の窃取、バックドアの設置など、サイト全体の侵害につながります。
プラグインやテーマではなくWordPress本体の脆弱性
WordPressでは、プラグインやテーマの脆弱性が日常的に報告されています。
プラグインの脆弱性であれば、そのプラグインを利用しているサイトだけが主な影響を受けます。使用していないプラグインの脆弱性であれば、基本的には自分のサイトへ直接影響するものではありません。
一方、WP2ShellはWordPress本体の脆弱性です。
WordPress本体は、すべてのWordPressサイトで動作しています。そのため、対象バージョンを使用しているサイトであれば、導入しているプラグインやテーマに関係なく影響を受ける可能性があります。
今回影響を受けるとされたバージョンと修正版は、次のとおりです。
- WordPress 6.8～6.8.5：6.8.6で修正
- WordPress 6.9～6.9.4：6.9.5で修正
- WordPress 7.0～7.0.1：7.0.2で修正
対象のバージョンを利用している場合は、修正版以降へ更新する必要があります。
修正版の公開直後から攻撃が始まった
WP2Shellで特に注目したいのは、脆弱性が公開されてから実際の攻撃が始まるまでの期間の短さです。
Wordfenceによると、WordPressセキュリティチームが修正版を公開した2026年7月17日には、すでに攻撃者による調査や攻撃が確認されました。翌日の7月18日からは、大量の攻撃が観測されています。
Wordfenceのファイアウォールが遮断した攻撃は、記事公開時点で1,100万件を超えています。
脆弱性が公表されると、修正内容の解析などから攻撃方法が組み立てられます。現在は情報共有や解析の速度も上がっており、「脆弱性が公開されてから数日後に対応する」という運用では、間に合わない可能性があります。
修正版が公開された時点で、攻撃者との競争はすでに始まっていると考えたほうがよいでしょう。
攻撃の多さがそのまま被害件数を示すわけではない
1,100万件を超える攻撃が確認されたと聞くと、多数のWordPressサイトが侵害されたように感じます。しかし、これはWordfenceが遮断した攻撃の試行回数であり、実際に侵害されたサイト数ではありません。
今回はWordPressセキュリティチームが強制的な自動更新を配信し、ホスティング事業者やセキュリティサービスとも連携して対策を進めました。
その結果、Wordfenceでは重大な脆弱性で通常見られるような、サイト侵害や復旧依頼の急増は確認されていないとしています。
自動更新が広く機能したことで、大規模な被害を抑えられた可能性があります。これは、自動更新の仕組みが実際の攻撃に対して有効に働いた事例ともいえます。
自分のサイトが侵害されていないか確認する
対象バージョンを使用していた場合は、最新版へ更新するだけでなく、不審な変更がないかも確認しておきましょう。
Wordfenceでは、2026年7月17日以降に作成された不明な管理者アカウントがないか確認することを推奨しています。
実際に観測された攻撃では、次のアカウント情報が使用されていました。
- ユーザー名：
wpenginebot - メールアドレス：
wpenginebot@wpengine.com
また、サーバーのアクセスログを確認できる場合は、/wp-json/batch/v1への不審なリクエストがないかを調べます。
ただし、管理者権限を取得した攻撃者は、作成したアカウントや痕跡を削除できます。該当するアカウントやログが見つからないことだけで、安全だと断定することはできません。
手動更新だけでは間に合わない可能性がある
WordPressの管理画面を定期的に開き、更新があれば手動で適用する運用もあります。
しかし、今回のように修正版の公開当日から攻撃が始まる場合、数日や1週間ごとの確認では対応が遅れる可能性があります。
だからといって、何も確認せずにすべてを自動更新すればよいとも限りません。更新によってプラグインやテーマとの互換性に問題が発生することもあります。
重要なのは、更新を止めることではなく、問題が起きてもすぐに確認・復旧できる状態を作ったうえで、素早く更新できるようにすることです。
例えば、次のような仕組みが考えられます。
- WordPress本体のセキュリティ更新を自動適用する
- 更新が行われたことをメールなどで通知する
- 更新後にサイトが正常に表示されるか確認する
- 定期的にバックアップを取得する
- 問題が発生したときに以前の状態へ戻せるようにする
- 複数サイトを管理している場合は更新状況を一元管理する
これらを組み合わせることで、更新の速さと安全性の両方を確保しやすくなります。
素早く安全に更新できる仕組みを作ろう
WP2Shellは、プラグインやテーマではなく、WordPress本体に見つかった重大な脆弱性です。
さらに、修正版の公開から実際の攻撃までの猶予がほとんどありませんでした。脆弱性情報を知ってから手作業で対応方法を考える運用では、今後も同様の問題が発生したときに対応が間に合わない可能性があります。
WordPressを安全に運用するには、定期的に更新するだけでなく、修正版が公開されたときに素早く適用できる仕組みが必要です。
自動更新、更新通知、動作確認、バックアップを組み合わせ、問題が起きたときにも復旧できる状態を整えておきましょう。
脆弱性を完全に避けることは難しくても、修正版を早く適用できれば、攻撃を受ける時間を短くできます。WP2Shellは、WordPressの安全性が更新作業そのものではなく、継続的な運用の仕組みによって支えられていることを示す事例です。
参考：WP2Shell WordPress Exploit Technical Analysis and Real Attack Data（Wordfence）
コメントを残す