2026年7月17日に公開された WordPress の深刻度「緊急」の脆弱性（CVE-2026-63030 / CVE-2026-60137）、いわゆる「wp2shell」は、脆弱なバージョンでは認証なしに外部からサーバー上で任意のコードを実行されるおそれがある、非常に厳しい内容です。
前回の記事では、さくらインターネットのレンタルサーバーを対象に、攻撃の起点となる /batch/v1 へのアクセスがなかったかをアクセスログから確認するスクリプトをご紹介しました。
- 前回記事: さくらのレンタルサーバーで WordPress の緊急脆弱性「wp2shell」の攻撃アクセスがなかったか確認する方法
今回、同じ確認をエックスサーバーで行うためのスクリプト check-log-and-file-xserver.sh を追加公開しました。エックスサーバーはさくらとサーバー内のフォルダ構成が大きく異なるため、スクリプトの処理もそれに合わせて変えています。本記事では、その構成の違いと処理の違いも含めてご紹介します。
まず最優先はアップデートです
ログ確認の前に、WordPress 本体のアップデートを必ず行ってください。7.0系は 7.0.2 以上、6.9系は 6.9.5 以上、6.8系は 6.8.6 以上が修正版です（6.9.0〜6.9.4、7.0.0〜7.0.1 が wp2shell による未認証RCEの対象です）。詳しくは前回記事、および GMO Flatt Security さんの解説記事をご覧ください。
さくらとエックスサーバーで何が違うのか
同じ「アクセスログを検索する」だけの処理でも、ログがどこに・どんな名前で保存されているかはサーバー会社ごとに異なります。2社を比べると次のようになります。
| さくらのレンタルサーバー | エックスサーバー | |
|---|---|---|
| ログの置き場所 | アカウント全体で1箇所<br>~/log/ | ドメインごとに分かれる<br>~/ドメイン名/log/ |
| ログのファイル名 | access_*.gz | ドメイン名.access_log_YYYYMMDD.gz |
| 公開フォルダ | ~/www/ 配下 | ~/ドメイン名/public_html/ |
さくらはログが ~/log/ の1箇所に集約されているため、そのディレクトリを検索するだけで済みました。一方エックスサーバーは、ドメインを追加するたびにホームディレクトリ直下にドメイン名のフォルダが作られ、その中に公開フォルダ（public_html）とログフォルダ（log）がぶら下がる構成です。
~/ ← ホームディレクトリ
├── example.com/
│ ├── public_html/ ← example.com の公開フォルダ
│ └── log/
│ ├── example.com.access_log_20260721.gz
│ └── example.com.access_log_20260722.gz
├── example.jp/
│ ├── public_html/ ← example.jp の公開フォルダ
│ └── log/
│ └── example.jp.access_log_20260721.gz
└── （その他のファイル・フォルダ）
つまりエックスサーバーでは、「どのドメインを運用しているか」をまず把握しないと、検索すべきログフォルダが決まりません。ここが処理の分かれ目になります。
エックスサーバー版スクリプトの処理の流れ
さくら版が「~/log/ を find するだけ」だったのに対し、エックスサーバー版は次の2段階で対象ログを組み立てます。
① public_html を目印にドメインフォルダを特定する
ホームディレクトリ直下には、ドメインフォルダ以外のファイルやフォルダも置かれている可能性があります。そこでスクリプトは、ホームディレクトリ配下から public_html という名前のフォルダを再帰的に検索し、見つかった public_html の親フォルダをドメインフォルダとみなします。
find "$base_dir" -type d -name 'public_html' 2>/dev/null | sed 's#/public_html$##' | sort -u例えば ~/example.com/public_html が見つかれば、親フォルダ名の example.com がドメイン名です。「公開フォルダを持っている＝実際に運用されているドメイン」という確実な目印で判定するため、ホームディレクトリに他のフォルダが混在していても誤検出しません。
② 各ドメインの log/ から過去N日分のログを収集する
特定した各ドメインフォルダについて、log/ の中から ドメイン名.access_log_*.gz に一致し、かつ更新日時（mtime）が過去N日以内のファイルを収集します。
for d in "${domain_dirs[@]}"; do
domain="$(basename "$d")"
log_dir="$d/log"
[ -d "$log_dir" ] || continue
# find で "${domain}.access_log_*.gz" の過去N日分を収集
doneファイル名のパターンにドメイン名そのものを含めるのがポイントです。仮に log/ フォルダに無関係な gz ファイルが置かれていても対象にならず、確実にアクセスログだけを検索できます。
あとはさくら版と同じで、集めた gz ファイルをストリーム解凍（ディスクに展開しない）しながら、指定パターン（既定 /batch/v1）を grep で検索します。
複数ドメイン運用でも1回で全部確認できます
この作りのおかげで、エックスサーバーで複数のドメイン・複数の WordPress を運用している場合でも、1回の実行で全ドメインのログをまとめて確認できます。実行時には検出したドメインの一覧が表示されるので、「確認したいドメインが対象に入っているか」もその場で確かめられます。
使い方
エックスサーバーに SSH で接続し、ホームディレクトリで実行します（SSH はサーバーパネルから有効化が必要です）。
curl で直接実行する場合（おすすめ）
# 対話入力（何日分を対象にするかプロンプトで聞かれます。Enter で7日）
curl -s https://raw.githubusercontent.com/web-soudan/wp-security-audit-on-jp-hosting/refs/heads/main/check-log-and-file-xserver.sh | bash
# 引数で指定する場合（/batch/v1 を過去7日分から検索）
curl -s https://raw.githubusercontent.com/web-soudan/wp-security-audit-on-jp-hosting/refs/heads/main/check-log-and-file-xserver.sh | bash -s -- /batch/v1 7
パイプ実行でも /dev/tty から日数を読み取るため、対話プロンプトがそのまま使えます。cron など端末のない環境では、第2引数で日数を必ず指定してください。
ダウンロードして実行する場合
# 対話入力
bash check-log-and-file-xserver.sh
# 引数で指定（第1引数: 検索パターン、第2引数: 日数）
bash check-log-and-file-xserver.sh /batch/v1 7
実行結果の見方
実行すると、まず検出した公開フォルダ（ドメイン）の一覧が表示され、続いて対象期間・対象ログファイル・検索パターンのあとに、マッチしたログの行と件数が出力されます。
検出した公開フォルダ:
/home/ユーザー名/example.com/public_html (ドメイン名: example.com)
/home/ユーザー名/example.jp/public_html (ドメイン名: example.jp)
--------------------------------------------------
対象期間 : 過去 7 日
対象ファイル : 9 件
...
検索パターン : /batch/v1
--------------------------------------------------
（マッチしたログの行）
--------------------------------------------------
マッチ件数 : 3
- マッチ件数が 0 件 … 対象期間のログには
/batch/v1へのアクセスは記録されていません。 - マッチした行がある … アクセスがあったということです。マッチ行の中身（どのドメインのログか、いつ・どこからのアクセスか）を確認してください。
なお、このスクリプトは読み取り専用で、サイトのファイル・データベース・ログには一切変更を加えません。WP-CLI も不要で、gzip / find / grep だけで動作します。
結果を見るときの注意点
さくら版の記事と共通ですが、改めて要点をまとめます。
ログにアクセスがあった＝侵害された、ではありません。 脆弱性公開後はスキャナやリサーチャーによる探索的なアクセスも増えています。また、バッチ API はレスポンス全体に 207 を返し個々の成否は JSON 本文に入るため、アクセスログのステータスコードだけでは攻撃の成否を判断できません。
ログにアクセスがなかった＝100%安全、でもありません。 ログの保存期間より前のアクセスは確認できませんし、HTTP メソッドを上書きする手法などもあるため、単純な検索では見落としの可能性が残ります（本スクリプトはメソッドを限定せず、パス文字列でマッチさせる方針にしています）。
アクセスが確認でき、かつ脆弱なバージョン（6.9.0〜6.9.4 / 7.0.0〜7.0.1）を使っていた期間と重なる場合は、侵害されている前提での対応をおすすめします。同リポジトリの check-wp.sh を使えば、WP-CLI の verify-checksums によるコア・プラグインのファイル改ざん検知も実行できます。
まとめ
- まずアップデート（7.0.2 / 6.9.5 / 6.8.6 以上へ）
- アクセスログを確認 — エックスサーバーは
check-log-and-file-xserver.shで、全ドメインをまとめて検索 - 怪しい場合はファイル改ざん検知や専門家への相談へ
エックスサーバーはドメインごとにフォルダとログが分かれる構成のため、スクリプト側で「public_html を目印にドメインを自動検出 → 各ドメインのログをまとめて検索」という一手間を加えています。逆に言えば、複数サイトを運用している方ほど、1回の実行で全体を確認できるメリットが大きいはずです。
Webの相談所では、エックスサーバーやさくらインターネットをはじめとする国内ホスティング上の WordPress サイトの保守・セキュリティ対応を行っています。「該当バージョンか分からない」「ログの見方に自信がない」という場合も、お気軽にご相談ください。