WordPress緊急脆弱性「wp2shell」対象バージョンと確認・復旧の手順

まず自分のサイトが該当するかを確認してください。危険度はバージョンによって異なります。

修正版は 7.0.2 / 6.9.5 / 6.8.6 以降です。使用中のバージョンは、管理画面の「ダッシュボード」→「更新」、または「ツール」→「サイトヘルス」→「情報」→「WordPress」で確認できます。

WordPress.org は自動更新システムを通じた強制配信も行っていますが、自動更新を明示的に無効化しているサイトに適用されたかは公表されていません。「自動更新にしてあるから大丈夫」と考えず、実際のバージョン番号を目視で確認してください。

wp2shell は、2つの脆弱性を連鎖させる攻撃です。

① REST APIのバッチ処理の取り違え（CVE-2026-63030）

WordPressには複数のAPIリクエストをまとめて処理する /wp-json/batch/v1 というエンドポイントがあります。ここで検証に失敗したリクエストがあると、配列の添字がずれて別の処理が実行されるという不具合がありました。結果として、本来必要な権限チェックが迂回されます。

② パラメータ経由のSQLインジェクション（CVE-2026-60137）

投稿一覧の絞り込みに使う author__not_in というパラメータが、配列ではない値を渡されたときに検証を素通りし、そのままSQL文に連結される不具合です。

連鎖すると何が起きるか

①で権限チェックを回避し、②でデータベースを操作できるため、ログインしていない第三者が、管理者権限の取得からコード実行まで到達できます。攻撃にはログイン情報もプラグインも必要ありません。URLを知られている＝攻撃対象、という状態です。

公開直後は「悪用の確認なし」とする報告もありましたが、7月21日に米CISAが「悪用が確認された脆弱性カタログ（KEV）」へ両CVEを登録しました。観測されている内容は次のとおりです。

• ハニーポット観測で数万件規模の攻撃試行、100件を超える不正な管理者アカウントの作成
• 侵入後に、悪意あるプラグインのアップロード、管理画面へのログイン、既存ツールを装った Web シェルの設置

国内でも、7月22日にIPAが「重要なセキュリティ情報」に掲載、7月23日にJPCERT/CCがWeekly Reportで取り上げています。

手順1：バージョンを上げる（最優先）

7.0.2 / 6.9.5 / 6.8.6 以降へ更新します。メジャーバージョンをまたぐ更新に不安がある場合でも、自分の系列の修正版（6.9系なら6.9.5）へ上げれば対処できます。大きな移行を待つ必要はありません。

手順2：すぐ更新できない場合の緩和策

検証が必要ですぐ更新できない場合、攻撃の入口を塞ぐ方法があります。

• WAFで /wp-json/batch/v1 と ?rest_route=/batch/v1 へのアクセスを遮断する
• rest_pre_dispatch フィルタで、未認証の batch/v1 へのリクエストを拒否する

ただしこれは時間を稼ぐための措置です。根本対応は更新です。

手順3：すでに侵入されていないか確認する

更新はこれ以降の攻撃を防ぎますが、更新前に侵入されていた場合、その痕跡は残ったままです。次を確認してください。

• アクセスログ：POST /wp-json/batch/v1、POST /?rest_route=/batch/v1 へのリクエスト。特にステータス207の応答
• 管理者ユーザー：身に覚えのないアカウントが増えていないか
• プラグイン一覧：導入した覚えのないプラグイン
• wp-content/uploads 内の .php ファイル：正常な運用では存在しません
• ファイルの更新日時：自分が作業していない日時に本体ファイルが変わっていないか

ログの保存期間はサーバーによって数週間程度です。確認するなら早い方が良い理由がここにあります。

今回のように本体側の脆弱性は、プラグインを厳選していても、更新を欠かさなくても、公表から更新までの間は無防備になります。防ぎきれない前提で、戻せる状態を用意しておくことが最後の砦になります。

最低限そろえておきたい3点

1. ファイルとデータベースの両方を取得していること（片方だけでは戻せません）
2. サーバーとは別の場所に保存していること（サーバーごと侵害されると同時に失います）
3. 実際に復元を試したことがあること

3番目が抜けている現場は多いです。バックアップは取得できていても、いざ戻そうとするとファイル欠損や容量制限で失敗する、という事態は珍しくありません。検証環境で一度復元してみるだけで、この不確実性はなくなります。

世代管理も重要です

改ざんは気づくまでに時間がかかります。1世代だけしか保持していないと、侵害後の状態で上書きされたバックアップしか残らないことがあります。最低でも数世代、可能なら1か月分は保持してください。

当社で保守している数十サイトに対して実際に行った対応を、順を追って記載します。制作会社の方が自社の管理サイトに対応する際の参考になれば幸いです。

1. 全サイトのバージョンを一覧で抽出する

最初にやるべきは、どのサイトが対象バージョンなのかの一覧化です。管理サイトが数十件あると、1件ずつ管理画面を開くだけで半日が消えます。当社は保守対象サイトのWordPressバージョンを台帳で一元管理しており、対象バージョンのサイトを即座に抽出できる状態にしていました。この一覧化の速さが、初動の速さをそのまま決めます。

2. 更新を待たずに侵入口を塞ぐ

更新は検証を挟むため、全サイトに行き渡るまで時間がかかります。その間を無防備にしないため、未ログイン状態からのバッチエンドポイントへのアクセスを拒否する mu-plugin を作成し、73サイトへ一斉配布しました。rest_pre_dispatch フィルタで、未ログインの /batch/v1 宛リクエストを403で返す実装です。

実装で意識した点が2つあります。

• ログイン済みの操作は妨げない：バッチエンドポイントはブロックエディタが正規に使用します。一律に塞ぐと編集画面が壊れるため、未ログインのときだけ拒否します
• フィルタの優先度を最大にする：他のプラグインが後から処理を上書きして、防御が無効化されることを防ぎます

3. 配布した緩和策の取りこぼしを修正する

ここで実際に問題が見つかりました。初版は対象ルートの判定に単純な文字列一致を使っていましたが、WordPressのルート照合は大文字小文字を区別しません。つまり /wp-json/Batch/v1 のような表記でリクエストされると、判定を素通りして本来のハンドラに到達してしまいます。

大文字小文字を無視する正規表現による判定に修正し、再配布しました。緩和策は「入れた」だけでは不十分で、回避経路がないかまで確認する必要があるという実例です。

4. 自作の防御ファイルがマルウェア検知に引っかかる

副次的に起きた問題として、配布した防御用ファイル自体が、日次のマルウェアスキャンで「不審なファイル」として検出されました。mu-plugins に見慣れないPHPファイルが突然増えるため、検知側から見れば改ざんと区別がつきません。

自作の防御ファイルを検査対象から除外する設定を入れて解消しましたが、緊急対応でファイルを配布するときは、監視側の設定も同時に見直す必要があるということです。除外を入れないまま放置すると、本物の検出が埋もれます。

5. 侵入を受けたサイトはバックアップから復旧する

調査の結果、侵入を受けていたサイトについては、3件をバックアップファイルから復旧しました。不正なファイルを個別に削除する方法は、バックドアの取りこぼしが起きます。侵入経路を特定したうえで、侵害前の状態に戻し、修正版へ更新してから公開に戻す手順を取りました。

復旧できたのは、バックアップが世代で残っていたからです。1世代しか保持していなければ、侵害後の状態で上書きされたものしか残らず、戻す先がありませんでした。

6. 復元手段そのものを点検する

あわせて、全サイトのバックアップが最新かを点検しました。この点検で、一部のサイトでバックアップの取得が止まっていることが判明しました。平時は誰も気づきませんが、復旧が必要になった瞬間に致命的になります。脆弱性対応のたびに復元手段を点検する運用にしています。

• 対象は 6.9.0〜6.9.4 / 7.0.0〜7.0.1（RCE）、6.8.0〜6.8.5（SQLiのみ）
• 修正版は 7.0.2 / 6.9.5 / 6.8.6 以降
• プラグイン不要・未認証で成立し、実際の攻撃が確認済み
• 更新後も、更新前に侵入されていないかの確認が必要
• 本体の脆弱性は防ぎきれない。復元できる状態が最後の砦