WordPress の脆弱性情報が出たとき、サイトを運営している方からすると「更新した方がいいのは分かった。でも、自分のサイトに攻撃らしきアクセスが来ていたのかどうかは、どう確認すればいいのか」が気になるところだと思います。
今回の wp2shell についても、国内の一般的なレンタルサーバーで WordPress を運用している場合、まず確認したいのは Web サーバーのアクセスログです。
ただし、最初に大事な前提があります。
アクセスログを見ただけで「攻撃が成功した」「侵害されていない」と完全に判断することはできません。多くのレンタルサーバーのアクセスログには、アクセス元 IP アドレス、日時、HTTP メソッド、URL、ステータスコード、ユーザーエージェントなどは残りますが、攻撃内容が入ったリクエスト本文までは通常残りません。
なので、この記事では「侵害を断定する方法」ではなく、まずは「wp2shell に関連して使われた可能性がある入口へのアクセス試行が、保存されているログの範囲に残っているかを確認する方法」として整理します。
また、この記事では「CVE-2026-63030（wp2shell と呼ばれている REST API batch-route confusion）」と、WordPress 公式リリースであわせて修正された「CVE-2026-60137」を混同しないように扱います。公式情報では、CVE-2026-63030 は WordPress 6.9.x の 6.9.5 未満、7.0.x の 7.0.2 未満が影響対象です。一方で WordPress 6.8 は、CVE-2026-60137 の影響対象として 6.8.6 がリリースされています。
まず確認する文字列
wp2shell では WordPress REST API のバッチエンドポイントが攻撃経路として言及されています。エックスサーバーの注意喚起でも、REST API のバッチエンドポイントである /wp-json/batch/v1 への通信を遮断したと案内されています。
そのため、アクセスログではまず次の文字列を探します。
/wp-json/batch/v1
rest_route=/batch/v1典型的には、次のようなリクエストです。
POST /wp-json/batch/v1
POST /?rest_route=/batch/v1
POST /wordpress/wp-json/batch/v1WordPress をサブディレクトリに設置している場合は、次のような形もあり得ます。
POST /wp/wp-json/batch/v1
POST /blog/wp-json/batch/v1HTTP メソッドは POST が中心になりますが、ログ検索の最初の段階では POST だけに絞らず、URL 文字列で広めに探す方が良いと思います。リクエストの形やログの出方は環境によって違うことがあるためです。
調査期間としては、まず修正版が公開された 2026年7月17日以降のログを確認します。余裕があれば、運用上の確認として 2026年7月1日以降まで広げても良いと思います。ただし、この「7月1日」は公式に示された攻撃開始日という意味ではなく、ログが残っている範囲で広めに見るための目安です。
WordPress 公式ニュースでは、WordPress 7.0.2 が 2026年7月17日に公開され、1件の critical、1件の high severity のセキュリティ issue に対応したと案内されています。あわせて、WordPress 6.9.5 と 6.8.6 もバックポートとしてリリースされています。また、NVD の CVE-2026-63030 情報では、WordPress 6.9.x の 6.9.5 未満、7.0.x の 7.0.2 未満が REST API batch endpoint route confusion の影響を受けると説明されています。
参考: WordPress 7.0.2 Release / WordPress 6.8.6 公式ドキュメント / NVD: CVE-2026-63030
Mac でログを検索する基本形
ダウンロードしたログがテキストファイルであれば、ターミナルで次のように検索できます。
grep -iE 'wp-json/batch/v1|rest_route=.*batch/v1' access.log複数ファイルをまとめて確認する場合は、たとえば次のようにします。
grep -iE 'wp-json/batch/v1|rest_route=.*batch/v1' *.logログが gzip 形式、つまり .gz で圧縮されている場合は、展開せずに zgrep で検索できます。
zgrep -iE 'wp-json/batch/v1|rest_route=.*batch/v1' *.gzフォルダ内の gzip ファイルをまとめて探す場合は、次のような形です。
find . -type f -name '*.gz' -exec zgrep -HiE 'wp-json/batch/v1|rest_route=.*batch/v1' {} +Windows の場合は、ログファイルをテキストエディタで開いて wp-json/batch/v1 や batch/v1 を検索する方法でも構いません。大きなログファイルだとエディタが重くなる場合があるので、その場合は WSL や PowerShell、または制作会社・保守担当者に確認を依頼する方が現実的です。
エックスサーバーでアクセスログを確認する
エックスサーバーでは、サーバーパネルの「アクセスログ」から対象日のログを表示またはダウンロードできます。公式マニュアルでは、サーバーパネルにログインして「アクセスログ」をクリックし、対象日を指定して表示・ダウンロードする流れが案内されています。
確認の流れは、次のようになります。
- サーバーパネルにログインする
- 「アクセスログ」を開く
- 対象ドメインを選ぶ
- 日付を指定する
- 表示またはダウンロードする
- ダウンロードしたログで
wp-json/batch/v1とrest_route=/batch/v1を検索する
エックスサーバーの公式マニュアルでは、ログはドメイン単位・テキスト形式で、日別に生成されると説明されています。ログには、IP アドレス、タイムスタンプ、メソッドと URI、ステータス、リファラ、ユーザーエージェントなどが含まれます。
なお、エックスサーバーは wp2shell に関する注意喚起の中で、対象サービスにおいて /wp-json/batch/v1 への通信を 2026年7月19日 AM6:30 頃に遮断したと案内しています。対象サービスは、エックスサーバー、XServerビジネス、XServer for WordPress です。
参考: WordPress の脆弱性（wp2shell / CVE-2026-63030）に関する注意喚起とサーバー側対策のお知らせ
そのため、エックスサーバー利用者の場合は、特に 2026年7月19日 AM6:30 より前のログを優先して確認したいところです。遮断後も、403 などで拒否されたアクセス試行が残っていないか確認しておく意味はあります。
ただし、サーバー側の遮断はあくまで暫定的な対策です。WordPress 本体の更新確認は別途必要です。
さくらのレンタルサーバでアクセスログを確認する
さくらのレンタルサーバでは、アクセスログの保存設定を有効にしている場合、サーバー上のログファイルや Webalizer によるアクセス解析を確認できます。
公式サポートでは、アクセスログの保存場所は次のように案内されています。
/home/アカウント名/log/access_log_[日付]前日のログは gzip で圧縮されると説明されています。
確認の流れは、次のようになります。
- サーバーコントロールパネルにログインする
- 「サーバーステータス」から「アクセスログ」を開く
- アクセスログの保存設定を確認する
- 必要なログファイルを取得する
wp-json/batch/v1とrest_route=/batch/v1を検索する
SSH が使える場合は、サーバー上で次のように確認できます。
cd ~/log
zgrep -iE 'wp-json/batch/v1|rest_route=.*batch/v1' *.gz圧縮されていないログがある場合は、次のように検索します。
grep -iE 'wp-json/batch/v1|rest_route=.*batch/v1' access_log_*さくらの公式サポートでは、ディスク使用量が 80% を超えるとログ保存機能が停止することがあるとも案内されています。ログが見当たらない場合は、設定が有効だったか、保存期間内か、容量制限にかかっていないかも確認してください。
また、Webalizer の集計画面だけでは細かなリクエストを見落とす可能性があります。今回のような調査では、できるだけ生のアクセスログを確認する方が良いでしょう。
ロリポップ！でアクセスログを確認する
ロリポップ！では、ユーザー専用ページからアクセスログ解析を利用できます。公式マニュアルでは、生ログファイルをダウンロードできること、ログは gz 形式であること、アクセスログの保存期間は 90日間であることが案内されています。
確認の流れは、次のようになります。
- ユーザー専用ページにログインする
- アクセスログ解析の画面を開く
- 対象ドメインや期間を確認する
- 「生ログファイル」をダウンロードする
- ダウンロードした
.gzファイルをzgrepなどで検索する
検索例は次の通りです。
zgrep -iE 'wp-json/batch/v1|rest_route=.*batch/v1' *.gzロリポップ！のアクセスログ解析では、レポートとしてリクエスト数などを見ることもできます。ただ、今回探したいのは特定 URL へのアクセスなので、集計画面だけで判断するより、生ログファイルをダウンロードして検索する方が確実です。
ConoHa WING でアクセスログを確認する
ConoHa WING では、コントロールパネルからエラーログ・アクセスログを確認、ダウンロードできます。公式ガイドでは、「WING」から「サイト管理」へ進み、「アクセス解析」内の「ログ」タブを開く流れが案内されています。
確認の流れは、次のようになります。
- ConoHa コントロールパネルにログインする
- 上部メニューで「WING」を選ぶ
- 左メニューの「サイト管理」を開く
- 「アクセス解析」を開く
- 上部タブの「ログ」を開く
- ログ保存設定や保存先を確認する
- アクセスログをダウンロードし、
batch/v1を検索する
ConoHa WING の公式ガイドでは、コントロールパネル上で確認できるアクセスログは直近 100行、エラーログは直近 300行とされています。今回のように一定期間を調べたい場合は、画面表示だけでなく、保存先からログをダウンロードして確認する方が良いでしょう。
検索例です。
grep -iE 'wp-json/batch/v1|rest_route=.*batch/v1' access_log*gzip 形式で取得した場合は、次のようにします。
zgrep -iE 'wp-json/batch/v1|rest_route=.*batch/v1' *.gzmixhost でアクセスログを確認する
mixhost は cPanel を採用しています。公式ヘルプでは、cPanel にログインし、「メトリック」の「生アクセス」から対象ドメインのログを選択する流れが案内されています。
確認の流れは、次のようになります。
- cPanel にログインする
- 「メトリック」の「生アクセス」を開く
- 対象ドメインのログを選ぶ
- 必要に応じてアーカイブをダウンロードする
- ダウンロードしたログで
batch/v1を検索する
mixhost の公式ヘルプでは、ログファイルの見分け方として、HTTPS のアクセスログにはファイル名の途中に SSL や ssl_log が含まれると説明されています。現在の WordPress サイトは HTTPS で運用されていることが多いので、HTTP 側だけでなく HTTPS 側のログも確認してください。
検索例です。
zgrep -iE 'wp-json/batch/v1|rest_route=.*batch/v1' *.gzSSL 側を優先して見る場合は、次のような探し方もできます。
zgrep -iE 'wp-json/batch/v1|rest_route=.*batch/v1' *ssl*.gzColorfulBox でアクセスログを確認する
ColorfulBox も cPanel を採用しています。ColorfulBox の公式サポートでは、マイページから対象サーバープランを選び、左側メニューの「cPanelにログイン」から cPanel に入る手順が案内されています。
ログの取得そのものは、cPanel の「Raw Access（生アクセス）」を使う形になります。cPanel 公式ドキュメントでは、Raw Access からドメインごとの .gz 形式のアクセスログをダウンロードできると説明されています。
参考: Raw Access | cPanel & WHM Documentation
確認の流れは、次のようになります。
- ColorfulBox のマイページにログインする
- 対象サーバープランを開く
- 「cPanelにログイン」をクリックする
- cPanel の「メトリック」から「Raw Access」または「生アクセス」を開く
- 対象ドメインのログをダウンロードする
- ダウンロードした
.gzファイルでbatch/v1を検索する
検索例です。
zgrep -iE 'wp-json/batch/v1|rest_route=.*batch/v1' *.gzcPanel 環境では、ドメインごと、SSL 有無ごとにログが分かれている場合があります。どのファイルが対象か迷う場合は、対象ドメイン名や ssl を含むファイル名を優先して確認すると良いです。
ログで見つかった場合の見方
たとえば、次のような行が見つかったとします。
203.0.113.10 - - [18/Jul/2026:12:00:00 +0900] "POST /wp-json/batch/v1 HTTP/1.1" 207 684 "-" "Mozilla/5.0"この場合、控えておきたいのは次の情報です。
- アクセス元 IP アドレス
- 日時
- リクエストされた URL
- HTTP メソッド
- ステータスコード
- ユーザーエージェント
- 同じ IP から前後にどんなアクセスがあったか
ステータスコードは、あくまで目安として見ます。
| ステータス | 見方の目安 |
|---|---|
| 200 | リクエストが処理された可能性があります。要確認です。 |
| 207 | REST API のバッチ処理として返っている可能性があります。特に注意して確認します。 |
| 400 | 不正なリクエストとして扱われた可能性があります。ただし失敗断定はできません。 |
| 401 | 認証が必要だった可能性があります。 |
| 403 | WAF やサーバー側対策で拒否された可能性があります。 |
| 404 | そのルートが存在しなかった、または URL が違った可能性があります。 |
| 500 | サーバー側でエラーになった可能性があります。前後のログも確認します。 |
ここで注意したいのは、200 や 207 があるからといって、すぐに「侵害された」とは言えないことです。アクセスログだけでは、リクエスト本文や WordPress 側で実際に何が処理されたかまでは分からないためです。
一方で、2026年7月17日前後から急に batch/v1 へのアクセスが増えている、同じ IP から短時間に何度もアクセスされている、その直後に見慣れない PHP ファイルへアクセスされている、といった場合は、優先して追加調査した方が良いです。
同じ IP の前後の動きを見る
該当する IP アドレスが分かったら、同じ IP のアクセスを前後で確認します。
grep '203.0.113.10' access.loggzip の場合は、次のようにします。
zgrep '203.0.113.10' *.gz見るポイントは、次のようなものです。
/wp-json/batch/v1への複数アクセス/wp-admin/や/wp-login.phpへのアクセスwp-content/uploads/内の PHP ファイルへのアクセス- 見覚えのない
.phpファイルへの 200 応答 - 数秒以内の大量リクエスト
- 同じ IP からの POST リクエストの連続
- 直後に 500 エラーや 404 エラーが増えていないか
ただし、攻撃者が複数の IP アドレスを使うこともあります。同じ IP だけを見て「これで全部」と考えず、時刻の前後でもう少し広く確認するのが良いです。
ログに何も見つからなかった場合
wp-json/batch/v1 や rest_route=/batch/v1 が見つからなかった場合、少なくとも保存されているアクセスログの範囲では、今回探した入口へのアクセスは確認できなかった、と言えます。
ただし、それは「絶対に侵害されていない」という意味ではありません。
理由はいくつかあります。
- ログの保存期間より前にアクセスされていた
- ログ保存設定が有効ではなかった
- CDN や WAF 側で止まっていて、サーバーには別の形で記録されている
- Cloudflare などを経由していて、サーバー側では実アクセス元が分かりにくい
- URL エンコードや別表記で記録されている
- アクセスログにはリクエスト本文が残っていない
- 侵害後にファイルやログが変更されている
なので、何も見つからなかった場合でも、WordPress 本体のバージョン確認、コアファイルのチェック、管理者ユーザーの確認などは行っておきたいところです。
アクセスログ以外に確認したいこと
アクセスログの確認とあわせて、WordPress 側でも最低限の確認をしておきます。
まずは WordPress 本体を、公式が案内している修正版へ更新します。WordPress 公式ニュースでは、7.0.2 がセキュリティリリースとして案内され、バックポートとして 6.9.5 と 6.8.6 もリリースされています。NVD では、6.9.x は 6.9.5 未満、7.0.x は 7.0.2 未満が CVE-2026-63030 の影響対象として記載されています。
WP-CLI が使える場合は、次のように確認できます。
wp core version
wp core verify-checksumsコアファイルのチェックサムが正常であれば、次のような結果になります。
Success: WordPress installation verifies against checksums.ただし、この確認で分かるのは主に WordPress コアです。テーマ、プラグイン、アップロードディレクトリに置かれた不審なファイルまでは、これだけでは確認しきれません。
uploads 内に PHP ファイルがないかを見る場合は、次のように確認します。
find wp-content/uploads -type f \( -iname '*.php' -o -iname '*.phtml' -o -iname '*.phar' \)最近変更された PHP ファイルを見る場合は、たとえば次のようにします。
find . -type f -name '*.php' -mtime -14 -printただし、WordPress 本体やプラグインを更新した直後は、多くの PHP ファイルが変更されます。更新作業の日時と照らし合わせて判断してください。
管理画面に入れる場合は、次の点も確認します。
- 見覚えのない管理者ユーザーがいないか
- 見覚えのないプラグインが有効化されていないか
- 最近変更されたテーマファイルがないか
- 不審な固定ページや投稿が増えていないか
- サイト URL や管理者メールアドレスが変わっていないか
- FTP、SSH、サーバーパネルのログイン情報が古いまま共有されていないか
現実的な確認フロー
一般的なレンタルサーバーで WordPress を運用している方は、次の順番で進めるのが良いと思います。
- サーバーのアクセスログをダウンロードして保全する
- 未更新の場合は、WordPress 本体を公式が案内している修正版へ更新する
wp-json/batch/v1とrest_route=/batch/v1を検索する- 見つかった場合は、IP、日時、URL、ステータスコードを控える
- 同じ IP と同じ時刻前後のアクセスを確認する
- WordPress コアのチェックサムを確認する
- uploads 内の PHP ファイルを確認する
- 管理者ユーザー、プラグイン、テーマの状態を確認する
- 不審点があれば、パスワード変更、認証情報の再発行、専門家への相談を検討する
個人的には、ログの確認よりも先に「ログの保全」をしておくことが大事だと思っています。レンタルサーバーによってログの保存期間や保存設定が異なりますし、時間が経つほど調査できる材料は減っていきます。
自分で確認できることと、相談した方がよい状態
自分で確認できる範囲としては、次のあたりです。
- WordPress のバージョンを確認する
- WordPress を公式が案内している修正版へ更新する
- サーバー管理画面からアクセスログをダウンロードする
batch/v1の文字列を検索する- 見覚えのない管理者ユーザーやプラグインがないか見る
一方で、次のような場合は、制作会社や保守担当者、セキュリティ対応に慣れた専門家へ相談した方が良いです。
wp-json/batch/v1へのアクセスが見つかり、ステータスが 200 や 207 になっている- 直後に見覚えのない PHP ファイルへのアクセスがある
- uploads 内に PHP ファイルが見つかった
- 見覚えのない管理者ユーザーが追加されている
- サイトが勝手にリダイレクトする
- 管理画面に入れない、または管理者権限が変わっている
- サーバー内のファイル変更が多く、自分では判断できない
相談するときは、次の情報をまとめておくと話が早くなります。
- 利用しているレンタルサーバー名
- 対象ドメイン
- WordPress のバージョン
- ログで見つかった該当行
- 不審なアクセスの日時
- 最近行った更新作業
- 管理画面やサイト表示で起きている症状
まとめ
wp2shell のような脆弱性情報が出ると、どうしても不安になります。ただ、まずやることは大きく変わりません。
- アクセスログを保全する
- WordPress を公式が案内している修正版へ更新する
wp-json/batch/v1とrest_route=/batch/v1を検索する- 見つかった場合は、前後のアクセスと WordPress 側の状態を確認する
そして、ログに何も見つからなかったとしても「絶対安全」とは断定せず、WordPress 本体、管理者ユーザー、プラグイン、uploads 内のファイルなど、基本的な確認を続けることが大切です。
レンタルサーバーの管理画面やログファイルは、普段あまり触らない方にとっては分かりにくいと思います。ですが、今回のようなときに「どこからログを取れるのか」を一度確認しておくと、今後のトラブル対応でもかなり役に立ちます。
不安を煽るためではなく、自分のサイトの状態を落ち着いて確認するための手順として、参考になれば嬉しいです。
参考リンク
- Version 6.8.6 – WordPress.org Documentation
- WordPress 7.0.2 Release – WordPress News
- NVD – CVE-2026-63030
- アクセスログ | レンタルサーバーならエックスサーバー
- WordPress の脆弱性（wp2shell / CVE-2026-63030）に関する注意喚起とサーバー側対策のお知らせ | XServerビジネス
- アクセスログを設定し管理したい（Webalizer） | さくらのサポート情報
- アクセスログ解析の利用方法 | ロリポップ！レンタルサーバー
- エラーログ・アクセスログを確認する | ConoHa WING サポート
- アクセスログ・エラーログの確認方法 | mixhost ヘルプ＆サポート
- cPanel のログイン方法 | ColorfulBox サポートサイト
- Raw Access | cPanel & WHM Documentation
