サーバーのアクセスログを見ると、自社サイトが WordPress ではないのに、`/wp/` や `/wordpress/`、`/wp-json/`、`/?rest_route=` といったパスへのアクセスが並んでいることがあります。管理画面を開いた覚えがなくても、世界中から同じ形の探索が届きます。
2026年7月には、WordPress の重大な脆弱性として「wp2shell」が注目され、IPAも注意喚起を出しています。その前後から、REST API まわりを探すアクセスが増えた、という報告も少なくありません。この記事では、ログに出やすい探索の意味と、WordPress を使っている場合と使っていない場合で、それぞれ先に見る場所を整理します。攻撃の再現手順は書きません。
なぜ WordPress 専用のURLが来るのか
公開サイトの多くが WordPress で動いているため、攻撃側やスキャナは、まず WordPress らしい入口があるかどうかを機械的に試します。自社が Laravel や静的サイトでも、相手は「ここは違う」と知ってから来るわけではありません。リストに載ったドメインへ、同じパターンを順番に投げます。
よく見る例は、次のようなパスです。サブディレクトリに入れている前提の `/blog/` や `/cms/` も混ざります。
- /wp/ や /wordpress/ など、インストール先の当たりつけ
- /wp-login.php や /wp-admin/ など、管理画面の有無
- /wp-json/ や /?rest_route= など、REST API の有無
- /wp-json/batch/v1 や rest_route=/batch/v1 など、特定の窓口を探す通信
ログにこれらの行があること自体は、すでに侵入された、という意味ではありません。多くの場合は、入口があるかどうかを見に来ただけの試行です。一方で、放置すると「このサイトは WordPress として応答する」と誤解され、次の試行が続きやすくなります。
ステータスコードの見方
ログで一緒に見るのは、HTTPの応答コードです。ざっくり次のように読みます。
- 404 … そのパスが無い、または用意していない。WordPress を使っていないサイトでは自然な応答
- 403 … WAFやサーバー側で拒否した可能性。遮断できているサインになりやすい
- 301 / 302 … 別URLへ送っている。正規化やログイン誘導のことがある
- 200 / 207 … 何らかの内容が返っている。WordPress を使っているなら中身の確認が必要。使っていないのにトップと同じページが返ると、探索を続けられやすい
重要なのは、「200だから侵害」でも「404だから安全」でもない、という点です。200や207は、正常なAPI応答でも出ます。逆に、404でも別の入口が開いていれば足りません。ログは、次に何を確認するかの手がかりです。
WordPress を使っている場合
2026年7月の注意喚起では、WordPress 6.9 以降などで、特定の脆弱性の組み合わせにより、遠隔でのコード実行につながり得るとされています。修正版は WordPress 6.9.5 や 7.0.2 などです。まず本体の版を確認し、修正版へ上げます。自動更新を入れている場合も、実際にその版になっているかを見ます。
ログでは、REST API のバッチ用窓口を示す文字列を探す報告が多いです。代表的なのは `/wp-json/batch/v1` と `rest_route=/batch/v1` です。見つかっただけでは侵害の断定にはなりません。同じ送信元から、直後にプラグインのアップロードや、見慣れないPHPファイルへのアクセスが続いていないかを見ます。ログの保存期間が短いと、過去分は確認できないことがあります。
版の更新と、コア・プラグインの改ざん確認、管理者ユーザーの棚卸しはセットです。WAFで特定パスを止めるのは更新までのつなぎであり、更新の代わりにはなりません。一次情報は IPA の注意喚起と、WordPress 公式のリリース情報を見てください。
WordPress を使っていない場合
CMSが違うサイトでも、同じ探索は来ます。ここで効くのは、「WordPress 専用の入口が無い」ことを、応答ではっきり示すことです。存在しないパスは 404 にする。トップページと同じ本文を 200 で返さない。クエリだけ付けた探索用のパラメータで、通常ページを開かない。
www の有無や末尾スラッシュが別ホスト・別URLとして両方 200 だと、同じ探索が二重に記録され、検索エンジンにも重複として見えやすくなります。正規のホストへ 301 で寄せるのは、SEOだけでなく、ログの読みやすさにもつながります。
確認の順番は次のとおりです。
- アクセスログで /wp/ /wordpress/ /wp-json/ rest_route の有無を見る
- WordPress を使っていないのに 200 で中身が返るURLがないか見る
- 正規ホスト（https・wwwなしなど）へ寄せているか確認する
- 管理画面やAPIの公開範囲を、別経路でも棚卸しする
よくある誤解
「ログに WordPress のパスがある＝自分のサイトが WordPress だ」ではありません。探索側が勝手に試しているだけ、というケースが大半です。「WAFを入れたからログ確認は不要」も危険です。遮断できているかを、応答コードとログで見ます。
「スキャンされた＝すぐ公表や全面停止」も早すぎます。まず版と入口、同じ送信元の前後の動きを見ます。判断が難しいときや、見慣れないファイルが増えているときは、保全したうえで専門家へ相談します。
まとめ
公開サイトのログには、WordPress 向けの探索が日常的に混ざります。2026年7月の wp2shell 関連の注意喚起以降は、REST API まわりを探す行が増えた、という報告もあります。WordPress を使っているなら、修正版への更新とログ確認が先です。使っていないなら、存在しない入口を 404 にし、200 で中身を返さないことが大切です。
一次情報は、IPA「WordPressの脆弱性対策について」と、WordPress 公式のセキュリティリリースを見てください。
Makoto Tejimaでは、アクセスログの読み方、公開URLの応答、WordPress や自社開発サイトの入口の棚卸しを一緒に整理しています。ご相談ください。