【実録】WordPressの緊急脆弱性「wp2shell」でクライアントサイトが本当にハッキングされていた話 〜経営者にも読んでほしい教訓〜
はじめに
この脆弱性対応の告知をXで見て、私が全社告知をしたのが、7/22の午前中。それではとっくに手遅れでした。7/20に攻撃は始まっていましたね。結論としては、即座に対応をしても間に合わないという怖さがある事案でした。
2026年7月17日、WordPress本体に「認証不要でサーバーを乗っ取られる」という最悪クラスの脆弱性(通称 wp2shell、CVE-2026-63030 / CVE-2026-60137)が公表されました。
「うちは大手じゃないから狙われない」「プラグインじゃなくてコア本体の話でしょ?」——そう思っていた矢先、私が技術支援しているクライアントサイトの1つで、実際にこの脆弱性を突いた侵入の痕跡を発見しました。
この記事では、実際にデータベースで見つかった「侵入の証拠」を元に、何が起きたのか、どう気づいたのか、どう対処すべきかを、WordPress運用担当者向け・経営層向けの2パートで解説します。
※サイト名・クライアント名・サーバー情報など特定につながる情報はすべて匿名化しています。
そもそも wp2shell とは何か
WordPressコア本体に存在する脆弱性で、プラグインもテーマも関係なく、標準インストールのままで攻撃が成立する
REST APIのバッチ処理機能にあるバグ(CVE-2026-63030)と、SQLインジェクションのバグ(CVE-2026-60137)を組み合わせて悪用される
ログイン不要・ユーザーの操作も不要。攻撃者はただHTTPリクエストを送るだけで、管理者権限のアカウントを勝手に作成できてしまう
影響バージョン: WordPress 6.9系〜7.0.1(RCEフルチェーン)、6.8系はSQLインジェクション部分のみ影響
2026年7月17日にWordPress 7.0.2 / 6.9.5 / 6.8.6として緊急パッチがリリース済み
発見者はSearchlight Cyber社(Assetnote)のリサーチャーで、自社サイトが影響を受けているか確認できる無料チェッカーも公開されている(wp2shell.com)
深刻度の高さから、WordPress運営側が強制自動更新を発動するという異例の対応を取った
要するに、「更新をサボっていたら、誰かがボタンを押すだけで乗っ取られる」レベルの脆弱性です。
発見の経緯:違和感は「ユーザー一覧」から始まった
日常的なクライアントサイトの保守作業中、phpMyAdmin経由で wp_users テーブルを確認したところ、見慣れないユーザーが大量に登録されていることに気づきました。
具体的には、以下のような特徴を持つアカウントが2026年7月20日以降、数日おきに複数件作成されていました。
ユーザー名のパターン:w2s_ + ランダムな16進数文字列(例: w2s_xxxxxxxxxxxx)
メールドメイン:@wp2shell.local / @wp2shell.invalid といった、実在しない/内部用ドメイン
その他の偽装アカウント:site_admin のような、いかにも「元からある管理者」を装った名前
使い捨てメール併用:mailinatorなどの使い捨てメールサービスのドメインを使った登録も混在
登録タイミング:脆弱性公表(7/17)直後〜数日おきに断続的に新規作成
一見バラバラなアカウント名に見えますが、w2s_ というプレフィックスと wp2shell というドメイン名が、脆弱性の通称「wp2shell」と一致していることに気づき、「これはただの怪しい登録ではなく、まさにこの脆弱性を突いた自動化ツール・スキャナーによる侵入の痕跡そのものだ」と確信しました。
パスワードハッシュ自体はWordPress標準の形式($wp$2y$10$...)で特に異常はなく、侵入経路は脆弱性そのものであり、パスワードの強弱の問題ではなかったという点も重要です。
【WordPress運用担当者向け】今すぐやるべきこと
1. まずバージョン確認とアップデート
管理画面またはWP-CLIで現在のコアバージョンを確認
6.9.0〜7.0.1が該当する場合は最優先で 7.0.2 / 6.9.5 に更新
6.8系も6.8.6へのアップデートを推奨(SQLインジェクション単体のリスクが残る)
「自動更新が有効だから大丈夫」と過信せず、実際に更新が適用されたかを目視確認する(強制自動更新の対象外になっているケースがある)
2. 侵入の痕跡チェック
wp_users テーブルで、身に覚えのないユーザー、特に登録日時が脆弱性公表日(7/17)以降のものを確認
wp_usermeta の wp_capabilities を見て、不審なユーザーに administrator 権限が付与されていないか確認
wp-content/uploads/ 配下に .php ファイルが存在しないか確認(本来ここに実行可能なPHPファイルがあること自体が異常)
テーマ・プラグインファイルの改ざん有無を、正規配布元との差分比較などで確認
サーバーアクセスログで /wp-json/batch/v1 や ?rest_route=/batch/v1 宛の不審なリクエストがないか、7月中旬以降を遡って確認
3. 実際の駆除・復旧手順
不審な管理者アカウントを特定し削除(削除前に一覧を必ず記録・保全)
既存の正規管理者アカウントは全てパスワードを強制的にリセット
Webシェルらしきファイルが見つかった場合は隔離・削除し、可能であれば侵入前のクリーンなバックアップから復元
暫定的なWAF/.htaccess設定で /wp-json/batch/v1 への匿名アクセスをブロック(パッチ適用後も一定期間は継続監視)
復旧後も数週間はログイン試行やユーザー作成の監視を継続
4. 恒久対策
コア・プラグイン・テーマの自動更新を有効化し、かつ「有効化したら終わり」にせず定期確認をルーチン化する
セキュリティプラグイン(Wordfence等)によるファイル改ざん検知の導入
管理系エンドポイントへのアクセス制限(IP制限、WAF)
定期バックアップの取得と、実際に復元できるかの検証(バックアップは「取っているだけ」では意味がない)
【経営者・意思決定者向け】この事例から学ぶべきこと
技術的な話が多くなりましたが、経営視点で見るべきポイントは以下の3つです。
① 「うちは小さいから狙われない」は通用しない
今回の脆弱性は、特定の企業や業界を狙い撃ちしたものではなく、世界中のWordPressサイトを無差別にスキャンする自動化された攻撃です。WordPressは世界のWebサイトの相当数を占めるCMSであり、サイトの規模や知名度に関係なく、パッチが未適用というだけで対象になります。
② 放置コストは「見えないだけ」で確実に積み上がっている
セキュリティ対応を後回しにすると、
情報漏洩による顧客・取引先への説明責任
サイト停止による機会損失
復旧作業にかかる工数とコスト
最悪の場合、乗っ取られたサイトが他社への攻撃の踏み台にされることによる二次的な法的リスク
といった形で、対策コストの何倍ものコストとして跳ね返ってきます。「更新作業に工数を割く」ことは、コストではなく保険への投資です。
③ 「更新してあるはず」を疑う仕組みが必要
今回のように緊急パッチが出た際、WordPress側が強制自動更新をかけても、サーバー環境や設定によっては適用されないケースがあることが今回はっきりしました。「更新は自動化されているから安心」という体制のまま放置せず、定期的に外部の目(社内担当者以外、または専門ベンダー)でバージョンとセキュリティ状態を棚卸しする仕組みを持つことを強く推奨します。
まとめ
wp2shell(CVE-2026-63030 / CVE-2026-60137)は、プラグイン不要・認証不要でWordPressコアが乗っ取られる非常に深刻な脆弱性
実際に管理しているサイトでも、脆弱性公表からわずか数日で侵入の痕跡(w2s_プレフィックスの不審アカウント大量作成)が確認された
技術担当者は「バージョン確認→侵入痕跡調査→駆除→恒久対策」の順で対応を
経営層は「他人事ではない」という前提で、セキュリティ対応に必要な工数・予算を平時から確保しておくことが、結果的に最も安いコストになる
もし「うちのサイトは大丈夫か不安になった」という方は、まず wp_users テーブルの最近の登録者一覧を確認するところから始めてみてください。それだけでも、今回のような痕跡には気づける可能性があります。
この記事は実際の運用支援の中で発見した事例を元に、特定の組織・個人が識別されないよう内容を一般化して執筆しています。
