2026年10月21日、レンタルサーバーやWebサービスが相次いで緊急メンテナンスに入りました。原因は、Webサイトを動かすプログラミング言語「PHP」そのものに見つかった、深刻な脆弱性2件です。通称「php2shell」と呼ばれています。
このブログもWordPressで動いていて、サーバーはエックスサーバーです。そこで、修正版の公開後に自分のサイトを一通り確認しました。結論から言うと、修正は適用済みで、確認した範囲では侵入の痕跡は見つかりませんでした。
ただ、確認の途中で「最近更新されたファイル」が見つかり、一瞬ヒヤッとしました。調べた結果は正常なファイルだったのですが、同じ環境の人なら同じところで不安になるはずです。この記事では、確認した手順と、「正常なのに怪しく見えたもの」をまとめます。
php2shellとは：PHP本体の脆弱性
php2shellは、PHPに見つかった2件の脆弱性（CVE-2026-109618、CVE-2026-109619）の通称です。どちらも深刻度は「緊急」レベル（CVSS 9.2）で、ログインしなくても、外部からサーバー上でプログラムを実行されるおそれがあります。
PHPの開発チームは10月21日に、修正版を公開しました。
- PHP 8.5系：8.5.12
- PHP 8.4系：8.4.27
- PHP 8.3系：8.3.36
- PHP 8.2系：8.2.35
PHP 8.1以前も影響を受けるとされていますが、すでに公式サポートが終わっているため、PHPの開発チームからは修正版が出ていません。
今回は、予定していた公表の前に情報が外部に漏れたことが報告されています。実際の攻撃に悪用されたことも、セキュリティ企業から報告されています。
7月の「wp2shell」とは場所が違う
名前が似ているので混同しやすいのですが、2026年7月に話題になった「wp2shell」は、WordPress本体の脆弱性でした。WordPressを更新すれば直るものです。
一方、今回のphp2shellは、WordPressのさらに下で動いているPHP本体の脆弱性です。WordPressを最新にしていても防げません。
エンジニアの感覚で言うと、「アプリを最新にしたから安心」ではなく、「その下のレイヤーは誰が面倒を見ているか」を確認する必要がある、ということです。共用のレンタルサーバーの場合、PHPを更新するのは基本的にサーバー会社の役目になります（VPSなど自分でサーバーを管理している場合は、自分で更新が必要です）。
エックスサーバーの対応
エックスサーバーは公式のお知らせで、対応の経過を公開しています。要点は次のとおりです。
- 10月21日16時から、公式サイトや管理画面へのアクセスを一時的に止めた。予防のための措置で、不正アクセスが起きたためではないと明記されている
- その間も、利用者のサイトの表示と、メールソフトでの送受信は続けられていた
- 修正版の公開前から、緩和策を利用者のサーバーにも適用していた
- 10月22日中に、PHP 5.6〜8.5のすべてのサーバーへ修正を適用し終えた
ここで注意したいのが、修正の当て方がバージョンによって違う点です。
- PHP 8.2〜8.5：同じ系列の修正版（8.3.36など）に更新された
- PHP 5.6〜8.1：バージョン番号は変えずに、修正が当てられた
- PHP 5.5以下：10月23日時点で、修正の作成・検証中
エックスサーバーは、PHP 5.6〜8.5を使っている人について、今回の対策のために急いでPHPのバージョンを変える必要はないとしています。
ただし、PHP 8.1以前はPHP公式のサポートがすでに終わっています。今回は事業者が独自に修正してくれましたが、次も同じとは限りません。今回の件とは別に、落ち着いたタイミングで8.3や8.4への切り替えを計画しておくのがおすすめです。
エックスサーバー以外のレンタルサーバーを使っている場合は、契約しているサーバー会社のお知らせを確認してください。対応の時期や方法は事業者ごとに違います。
自分のサイトで確認した5項目
サーバー側で修正が済んでいても、修正が当たる前に入られていないかは別の話です。今回は公表前に情報が漏れ、悪用も報告されているので、次の5つを確認しました。どれもWordPressの管理画面と、サーバーのファイルマネージャで確認できます。
1. PHPのバージョン
WordPressの管理画面で「ツール」→「サイトヘルス」→「情報」タブ→「サーバー」を開くと、PHPのバージョンが表示されます。8.2〜8.5系なら、上の修正版の番号以上になっているかを見ます。
エックスサーバーでPHP 5.6〜8.1を使っている場合は、番号が変わらない形で修正されているので、この画面では判断できません。お知らせの「適用完了」を根拠にします。
2. 管理者ユーザーが増えていないか
「ユーザー」の一覧で、権限が「管理者」のユーザーを確認します。自分が作った覚えのない管理者がいたら要注意です。侵入した攻撃者は、あとで入り直すための管理者アカウントを作ることがよくあります。
3. 見覚えのないプラグインがないか
「プラグイン」の一覧で、入れた覚えのないものがないかを確認します。停止中のものも含めて見てください。
4. uploadsフォルダに.phpファイルがないか
画像などを保存する「wp-content/uploads」フォルダには、通常PHPファイルはほとんど置かれません。プラグインによっては、フォルダの中身を外から見られないようにするための、中身が空の「index.php」を置くことがあります。それ以外の.phpファイルがあれば、外から仕込まれた不正なプログラムの可能性があります。ファイルマネージャで、拡張子が.phpのファイルがないかを確認します。
5. 最近更新されたファイル
ファイルマネージャで、wp-contentの中を中心に、最近更新されたファイルを確認します。情報が外に漏れたのは日本時間の10月21日未明なので、私はその日以降を対象にしました。不安なら、もう少しさかのぼって見ても構いません。ここで見つかったファイルが「誰が作ったものか」を一つずつ確かめていきます。
私のサイトでは、1〜4はすべて問題なしでした。5では、いくつか新しい日付のファイルが見つかりました。それが次の章の話です。
正常なのに怪しく見えたもの
確認作業で一番迷うのが、「日付が新しいファイルがあるけど、これは大丈夫なのか」という場面です。私の環境で実際に見つかったものと、その正体を紹介します。
テーマが自動で作り直すファイル
サイトの一番上の階層にある「serviceWorker.js」というファイルの更新日時が、修正版の公開後に新しくなっていました。同じ時期に、テーマのフォルダの中にある「manifest.json」も更新されていました。
調べた結果、どちらも使っているWordPressテーマのPWA機能（サイトをアプリのように扱えるようにする機能）に関係するファイルでした。PWA機能を持つテーマやプラグインを使っていると、同じようなファイルが置かれることがあります。中身を読んで、次の点を確かめています。
- ページを訪問者のブラウザに一時保存して、表示を速くするだけの処理だった
- 外部のサイトへの通信や、外部からのプログラムの読み込みはなかった
- わざと読みにくくした（難読化した）コードもなかった
- ファイルの中に記録された日時が、ファイルの更新日時と一致していた。テーマがファイルを作り直したときに、その日時が書き込まれる仕組みとみられる
serviceWorker.jsは、公開ページから誰でも読めるファイルです。中身を確認したいときは、ブラウザで「サイトのURL/serviceWorker.js」を開けば読めます。
中身は古いのに、フォルダの日時だけが新しい
プラグインが使うフォルダの中には、中のファイルはすべて数か月前の日付なのに、フォルダ自体の日時だけが最近になっているものがありました。
フォルダの日時は、中でファイルを作ったり消したりすると新しくなります。画像を一時的に生成するものなど、動作中に一時ファイルを作ってすぐ消すプラグインは珍しくなく、その場合にこの状態になります。フォルダの中に新しいファイルが残っておらず、ほかの確認でも異常がなければ、過度に心配する必要はありません。
バックアップのログ
バックアップ用のツールが、毎日決まった時刻にログファイルを作っていました。作られた時刻が設定したスケジュールと一致していれば、正常な動きです。
日付だけで判断しない
3つに共通するのは、「日付が新しい＝不審」ではないということです。WordPressは、テーマやプラグインが裏でファイルを作ったり消したりしながら動いています。
大事なのは、見つかったファイルが「どの機能が作ったものか」を確かめることです。そして、不安だからといって慌てて消さないことです。正常なファイルを消せばサイトが壊れますし、本当に不審なファイルだった場合は、消すと調査の手がかりがなくなります。
同じ時期のもう一つの注意：UpdraftPlusを使っている人へ
php2shellとは別の話ですが、同じ週にWordPressの利用者向けの重要なお知らせがもう一つ出ています。バックアップ用プラグイン「UpdraftPlus」の開発元が、10月17〜18日に自社サイトへの不正アクセスを受けた件です。
- 開発元の顧客データベースから、遠隔管理機能「UpdraftCentral」の接続キーが盗まれたとみられている
- 盗まれたキーを使って、10月18日から一部のサイトに不正なプラグインが入れられた
- 開発元は10月19日に、古いキーを無効にする更新版（無料版1.26.13など）を出した
- UpdraftCentralを使った覚えがなくても、キーが作られている場合があると報告されている
UpdraftPlusを使っている場合は、プラグインを最新にしたうえで、「設定」→「UpdraftPlus バックアップ」→「高度なツール」→「UpdraftCentral」を開き、接続キーが残っていないかを確認してください。キーがあれば削除します。
注意したいのは、プラグインを更新しても、すでに入れられた不正なプラグインは消えない点です。前の章の「管理者ユーザー」と「プラグイン一覧」の確認も、あわせて行ってください。
これはプラグイン本体の脆弱性ではなく、開発元のサービスが侵害されたことによるものです。PHPの件と同じく、「自分のサイトの外」で起きたことが自分のサイトに影響する例と言えます。
もし不審なものが見つかったら
確認の結果、見覚えのない管理者やプラグイン、uploadsの中の.phpファイルなどが見つかった場合は、次の順で進めるのがおすすめです。
- 慌てて消さずに、どこに何があったかを記録する（スクリーンショットなど）
- WordPressの管理者パスワードと、サーバーのアカウントのパスワードを変える
- 契約しているサーバー会社のサポートに相談する
- 企業や団体のサイトで判断に迷う場合は、IPAの不正アクセス特別相談窓口に相談する
侵入された環境を「直して使い続ける」か、「きれいな状態から作り直す」かは、慎重に判断すべきポイントです。
関連記事：「直す」より「作り直す」時代へ｜サイバー攻撃からの復旧判断をエンジニアが解説
まとめ
- php2shellはPHP本体の脆弱性で、WordPressを最新にしていても防げない
- 共用のレンタルサーバーなら、PHPの修正は基本的にサーバー会社が行う。エックスサーバーはPHP 5.6〜8.5への修正を完了済み
- 修正が済んでいても、「修正前に入られていないか」は自分で確認する
- 確認するのは、PHPのバージョン、管理者ユーザー、プラグイン、uploadsの.phpファイル、最近更新されたファイルの5つ
- 日付が新しいファイルは、テーマやプラグインが作った正常なものであることも多い。誰が作ったかを確かめ、慌てて消さない
今回の件で、レンタルサーバーを使っていても、サイトの安全を全部サーバー会社任せにはできないと改めて感じました。とはいえ、確認に必要なのは管理画面とファイルマネージャだけです。まだ確認していない人は、この機会に一度見てみてください。
参考資料
- The PHP Group「PHP 8.4.27」ほか各系列のリリース告知（2026年10月21日）
- エックスサーバー「予防的な安全対策に伴う公式サイト・管理画面等の一時停止のお知らせ」（2026年10月22日、10月23日追記）
- watchTowr「Frequently Asked Questions About PHP Remote Code Execution (PHP2Shell CVE-2026-109618 & CVE-2026-109619)」
- Help Net Security「PHP2Shell: Critical PHP vulnerabilities patched, update now!」（2026年10月21日）
- TeamUpdraftのインシデント告知、および各セキュリティ企業の解説（2026年10月19〜21日）
- IPA「不正アクセス特別相談窓口の開設について」（2026年10月16日）
