WordPressの脆弱性「wp2shell」の影響を受けるバージョン（6.9.0〜6.9.4、7.0.0〜7.0.1）は、修正版への更新が必要です。7.0系は7.0.2、6.9系は6.9.5へ更新してください。
wp2shellは、ログインしていない第三者がWordPressのREST APIを経由し、サーバー上で任意のコードを実行できる可能性がある脆弱性です。WordPress本体の標準機能が対象であるため、特定のプラグインを使っていないサイトでも影響を受けます。
すぐに更新できない場合は、WAFによる対象APIの遮断などで一時的に防御します。ただし、WAFやBasic認証はあくまで更新までの暫定対策であり、修正版への更新自体が不要になるわけではありません。
最初にWordPressのバージョンを確認する
まず、WordPress管理画面の「ダッシュボード」または「更新」画面で現在のバージョンを確認します。今回公表された2件の脆弱性と修正版の対応関係は次のとおりです。
| 使用中のバージョン | 今回公表された脆弱性の影響 | 対応 |
|---|---|---|
| 7.0.0〜7.0.1 | 2件とも対象 | 7.0.2へ更新 |
| 6.9.0〜6.9.4 | 2件とも対象 | 6.9.5へ更新 |
| 6.8.0〜6.8.5 | SQLインジェクションのみ対象 | 6.8.6へ更新 |
| 6.8より前 | 今回公表された2件は対象外 | 別の脆弱性と保守状況を確認 |
WordPress 6.8系は、wp2shellの任意コード実行につながる攻撃チェーンの対象ではありませんが、同時に公表された別のSQLインジェクション脆弱性の対象となるため、6.8.6への更新が必要です。
6.8より前のバージョンは今回の2件の対象外ですが、古いWordPressには別の脆弱性や保守が止まったテーマ・プラグインが残っている可能性があります。wp2shellの対象外であっても、そのまま放置して安全とは限りません。
wp2shellはREST APIを入口とする攻撃
wp2shellは、WordPress REST APIのバッチ処理にある問題と、SQLインジェクションの脆弱性を組み合わせた攻撃です。REST APIは、WordPressの投稿や設定などのデータをHTTP経由で取得・更新する仕組みで、外部サービス連携のほかブロックエディターなどでも標準的に利用されています。
攻撃の流れを簡略化すると、次のようになります。
未認証のHTTPリクエスト
→ WordPress REST APIのバッチ処理
→ 本来とは異なる処理への到達
→ SQLインジェクション
→ 任意コード実行につながる可能性攻撃の入口として使われるのは、次のバッチAPIです。
/wp-json/batch/v1
?rest_route=/batch/v1この攻撃にはWordPressのログイン情報が不要であり、影響を受けるバージョンでは、標準構成のWordPressに匿名のリクエストを送るだけで攻撃が成立する可能性があります。
恒久対策は修正版への更新
恒久的な対策は、該当するWordPressを修正版へ更新することです。更新前には、WordPressファイルとデータベースの両方をバックアップし、復旧時に確実にアクセスできる場所へ保存してください。
現在のバージョンからメジャーバージョンをまたいで更新する場合は、本番サイトを直接更新せず、検証環境で先に以下の項目を確認します。
- 使用中のPHPとデータベースのバージョン
- テーマとプラグインの対応状況
- お問い合わせフォームの送信
- 投稿の作成・編集・保存
- ブロックエディターの動作
- 画像のアップロード
- 外部サービスとの連携
なお、自動更新を有効にしていても、サーバー環境や個別設定によっては実行されていない場合があります。実際のバージョンは管理画面で直接確認してください。
すぐに更新できない場合の暫定対策
発見元のSearchlight Cyberは、すぐに更新できない場合の緊急措置として、次のいずれかの方法でREST APIへのアクセスを遮断する対策を示しています。
- 未認証ユーザーからREST API全体へのアクセスを遮断する
- WAFで
/wp-json/batch/v1と?rest_route=/batch/v1を遮断する
どちらも正規機能へ影響する可能性があるため、設定後は投稿の編集・保存、フォーム送信、外部連携などの動作確認が必要です。
WAF
WAFで対象のバッチAPIを遮断すれば、攻撃リクエストがWordPressへ到達する前にブロックできます。SQLインジェクションを検知するルールも防御に有効です。
ただし、管理画面で「WAFが有効」と表示されているだけでは十分とはいえません。次の条件に当てはまる場合は、攻撃リクエストが通過する可能性があります。
- 検知のみで、遮断モードになっていない
- 対象APIのルールが適用されていない
- JSONのリクエスト本文を検査していない
- WordPressやREST APIが検査対象から除外されている
- CDNやWAFを通さず、サーバーへ直接アクセスできる
WAFは更新までの防御を補う仕組みであり、修正版への更新の代わりにはなりません。
Basic認証
ApacheやNginxなどのWebサーバー側でサイト全体にBasic認証を設定している場合、認証情報を持たないリクエストはWordPressに到達する手前で拒否されます。一般公開が不要な検証サイトや閉鎖中のサイトで有効な方法です。
ただし、WordPressプラグインによるBasic認証は、認証処理より先にWordPressが動作してしまいます。wp2shellへの緊急対策として使う場合は、必ずWebサーバーやホスティングサービスの管理画面で設定するBasic認証を選んでください。
また、認証が一部のURLにしか適用されていないと、REST APIだけが外部から利用できる状態になります。HTTPとHTTPS、wwwの有無、サブドメイン、サーバーへの直接アクセスを含め、すべての経路で認証が掛かっていることを確認してください。
REST APIの遮断
未認証ユーザーからのREST APIアクセスだけを拒否する設定であれば、管理画面からの通信にはログイン情報と認証用の値が付与されるため、ログイン中のブロックエディターは通常どおり動作します。一方、Webサーバー側でREST API全体を無条件に遮断すると、ログイン中の通信も拒否され、投稿の取得や保存などブロックエディターの主要機能が動かなくなります。
テーマの functions.php でREST APIを止める方法もありますが、テーマの変更や読み込み状態に左右されます。緊急対策としては、WAFやWebサーバーなど、WordPressより前の段階で遮断する方が確実に管理できます。
使用していないWordPressはサイト全体を止める
公開する必要がないWordPressであれば、REST APIだけを止めるより、サイト全体のアクセスを遮断する方が確実です。WordPressを残したままREST APIだけを遮断しても、ログイン画面、XML-RPC、テーマやプラグインのPHPファイルなどは公開されたままであり、将来見つかる別の脆弱性の対象にもなります。
今後使用する予定がない場合は、次の手順で整理します。
- WordPressファイルとデータベースをバックアップする
- バックアップを公開ディレクトリの外へ保存する
- Webサーバー側でサイト全体をアクセス遮断する
- 恒久的に不要なら、公開領域からWordPressを撤去する
- 不要なデータベースとデータベースユーザーも整理する
バックアップファイルを公開ディレクトリ内に置いたままにすると、そこから情報漏洩につながるおそれがあるため、必ず公開URLから取得できない場所へ保存してください。
更新しても侵害確認は別に必要
WordPressを修正版へ更新すれば新たなwp2shell攻撃は防げますが、更新前に侵害されていなかったことまでは保証できません。影響を受けるバージョンを公開していた場合や、不審な挙動がある場合は、次の項目を確認します。
- 覚えのない管理者ユーザーが作成されていないか
- WordPress本体、テーマ、プラグインが改ざんされていないか
uploadsやキャッシュディレクトリなどに不審なPHPファイルがないか.htaccessや.user.iniに覚えのない設定がないか- アクセスログに対象のバッチAPIへの不審なリクエストがないか
- サーバー上の定期実行処理に不審な登録がないか
WP-CLIでコアとプラグインの改ざんを確認する
WordPressコアやWordPress.org配布プラグインの改ざん確認には、WP-CLIのチェックサム検証が利用できます。公式チェックサムと照合し、変更または欠落したファイルを検出します。--include-rootを付けると、WordPress本体に含まれないルート直下のファイルについても警告を確認できます。
# WordPressコアを公式チェックサムと照合する
wp core verify-checksums --include-root
# WordPress.org配布プラグインを公式チェックサムと照合する
wp plugin verify-checksums --all --strictただし、チェックサムが一致しても、侵害されていなかったことの証明にはなりません。次の対象はチェックサム検証の対象外となるため、別途確認が必要です。
wp-config.php- 独自・有料テーマ
- 独自・有料プラグイン
uploadsなどに追加された不審なファイル.htaccessや.user.ini- データベース内の管理者ユーザーや改ざん
- サーバー上の定期実行処理
- アクセスログ
WordPress.orgで配布されていないプラグインやテーマは公式チェックサムを取得できないため、配布元の正常なファイルや侵害前のバックアップと照合します。
万が一改ざんが確認された場合、見つかった不審ファイルだけを削除して終わらせるのは危険です。サイトの公開を止め、証拠となるログとファイルを保全したうえで、正常なバックアップや公式配布ファイルとの全体照合を行ってください。あわせて、WordPress管理者、サーバー、データベースなどのすべての認証情報を変更します。
まとめ
- WordPress 6.9.0〜6.9.4、7.0.0〜7.0.1はwp2shellの対象
- 7.0系は7.0.2、6.9系は6.9.5へ更新する
- 6.8.0〜6.8.5は別のSQLインジェクション脆弱性があるため、6.8.6へ更新する
- 更新までの間は、WAFによるバッチAPIの遮断や未認証REST APIの遮断を検討する
- 一般公開が不要なサイトは、Basic認証またはサイト全体のアクセス遮断を行う
- 更新と侵害確認は別の作業として実施する
まずは管理しているすべてのWordPressについて、現在のバージョンと公開状態を確認してください。あわせて、使っていないWordPressがインターネット上に公開されたまま残っていないかも点検しておく必要があります。
