エックスサーバーのPHP脆弱性対応は3つだけ｜WordPressでの確認手順

はじめに

2026年10月21日、PHP に認証なしで任意のコードを実行できる脆弱性が2件公開されました。このブログはレンタルサーバーに置いた WordPress で動いているので、影響を受ける側です。ニュースを見て自分のサイトを確認したので、そのときに何を見て何を判断したかを書きます。

ここで扱うのは、共用サーバーの利用者が自分の環境をどう確かめるかだけです。脆弱性そのものの解説はしません。攻撃の仕組みを知りたい方は、記事の最後に挙げた解説記事のほうが詳しいです。

本記事のまとめ

• 自分のサイトの PHP バージョンは、WordPress の管理画面にある「サイトヘルス」から確認できる。サーバーの管理画面が止まっていても読める
• 外からは確認できない。このブログでは X-Powered-By が返らず、HTTP ヘッダーからは PHP のバージョンが読めなかった
• 共用サーバーでは PHP 本体の更新ができない。利用者にできるのは確認までで、更新はサーバー会社の作業である
• ただしサポートが終わった系列を選んでいると、PHP 公式からは修正版が出ない。サーバー会社が独自に直すのを待つことになるので、自分で切り替えたほうが早い
• バージョン番号が古いままでも、危険だと断定はできない。サーバー会社が独自に修正を当てている場合があり、外からは見分けられない

今回の脆弱性は php2shell と呼ばれています。概要は次のとおりで、番号と修正版は PHP 公式のセキュリティ告知に載っているものです。

※CVE とは、公表された脆弱性に世界共通で振られる識別番号です。CVSS は深刻度を 0 から 10 で表した指標で、9 以上は最も高い区分になります。

共用サーバーで自分がやることは3つ

PHP 本体へ修正を当てる作業は、共用サーバーの利用者にはできません。サーバーにログインして更新コマンドを打つ権限が、そもそも渡されていないためです。

では何もしなくてよいかというと、そうではありません。自分の側に残る作業が3つあります。

1. いま動いている PHP のバージョンを確認する。更新が届いたかどうかを知る手段がこれしかない
2. その系列がまだサポートされているかを確認する。終わっていれば、自分で新しい系列へ切り替える
3. 侵入された形跡がないかを見る。修正が当たっても、当たる前に入られていたものは消えない

作業の分かれ目を整理すると次のようになります。

2番目を見落としやすく、ここを間違えると修正は大きく遅れます。あとの節で詳しく書きます。

自分のサイトのPHPバージョンを確認する

確認の経路は3つあります。このうち確実に使えたのは、WordPress の管理画面から読む方法だけでした。順に書きます。

WordPress の管理画面から確認する

WordPress には「サイトヘルス」という画面があり、そこに PHP のバージョンが載っています。管理画面の左メニューから「ツール」→「サイトヘルス」と進み、上部の「情報」タブを開いて「サーバー」の行をクリックすると展開されます。

私の環境では次のように表示されました。

この方法の利点は、サーバー会社の管理画面が止まっていても読めることです。今回まさにその状況になりました。サーバーの管理画面は一時停止していましたが、WordPress 自体は動き続けていたので、こちらからは問題なく確認できました。

エックスサーバーの管理画面から確認する

契約しているプランによりますが、サーバーパネルに「PHP Ver.切替」という項目があり、ドメインごとに現在のバージョンを確認できます。ただし今回は、この画面が使えませんでした。

修正版の公開にあわせて、サーバーパネルを含む管理画面がまとめて一時停止されていたためです。更新を確認したいタイミングで、ちょうど管理画面が止まっていました。

サーバー会社の画面に頼り切っていると、こういうときに手段がなくなります。WordPress 側からも読めることを知っておくと、確認の手が1つ増えます。

外から見ても分からない

サイトに HTTP リクエストを送って、応答ヘッダーから PHP のバージョンを読む方法もあります。ただしこのブログでは読めませんでした。

実際に試したコマンドは次のとおりです。

curl -I https://data-atelier.net/

返ってきたヘッダーのうち、サーバーに関係する行はこれだけでした。

server: nginx

PHP のバージョンを示す X-Powered-By は返っていません。このヘッダーは PHP の設定で出力を止められるようになっていて、このブログでも止まっていました。攻撃する側に手がかりを渡さないための設定です。

つまり、外から読み取れるのはサーバーが nginx だということだけです。自分のサイトであっても、外から PHP のバージョンは確認できません。確認するには、管理画面にログインする必要があります。

確認した結果と、そこから分かったこと

2026年10月22日の未明に確認した時点で、私のサイトで動いていたのは PHP 8.2.34 でした。修正版が公開された翌日で、8.2.35 にはまだ届いていませんでした。

公開された修正版と、自分の環境を並べると次のようになります。

ここで確認できたことは2つあります。

• 番号の上では、まだ修正版が届いていない
• 使っているのは 8.2 系で、サポートが続いている系列である

効いてくるのは2つ目です。PHP 8.1 以前を使っていると、今回のように修正版が出ても修正版そのものが作られません。サポートが終了した系列には、開発チームが修正を出さないためです。どの系列がいつまでサポートされるかは PHP の公式サイトのサポート状況のページに一覧があります。

では、サポートが終わった系列を使っていたらどうなるか。何も来ないわけではありません。エックスサーバーは告知で、公式の修正版が無い系列にも自社で修正を作ると書いています。

公式修正版が提供されたPHPバージョン（8.2～8.5）から順次、修正の適用を開始しております。公式修正版が提供されていない古いPHPバージョンについては、弊社独自の修正の作成に着手しております。こちらは対応までにお時間をいただく見込みですが、引き続き対応を進めてまいります。

同じ告知が「お時間をいただく見込み」とも書いています。待つ時間が読めないなら、サーバーパネルで新しい系列へ切り替えるほうが早いです。切り替えは利用者にしかできません。

私は 8.2 系だったので、切り替えは不要でした。ニュースを見たときは「古い系列のままだったらどうしよう」と思いましたが、これは確認して初めて分かることです。

なお、この確認のあと同じ日のうちに、サイトヘルスの表示が 8.2.35 に変わっていました。修正版が適用されたということです。

バージョンが古いままでも脆弱性が残るとは限らない

番号が 8.2.34 のままだったあいだも、無防備だったとは言い切れません。表示されている番号と、実際に穴が塞がっているかどうかは別の話だからです。

エックスサーバーは修正版の公開にあわせて告知を出しており、そこに次の記述がありました。

今回の脆弱性については、お客様のご利用サーバーにも、修正版公開前の緩和策を含む安全対策を弊社にて順次適用しております。修正版の公開後は、弊社で提供している各PHPバージョンを対象に、公式の修正版や弊社独自の修正を順次適用する予定です。

「弊社独自の修正」という言葉があります。エックスサーバーのように、公式のバージョン番号を上げずに問題のある箇所だけを直して配る場合、画面に出るバージョンは古いままなのに脆弱性は塞がっているという状態になります。

そして、それが当たっているかどうかを利用者が外から確かめる手段はありません。番号を見ても分からず、動作からも判別できません。結局はサーバー会社の告知を読むしかないのが実際のところです。

同じ告知には、こういう一文もありました。

なお、ご利用状況によっては、管理画面の提供再開後にお客様にも追加の対策をお願いする場合があり、その際は改めてご案内いたします。

「完全に待っているだけでよい」とは書かれていません。告知は更新されるので、お知らせのページを数日は見ておいたほうがよさそうです。

なお、侵入の形跡を調べる作業は、サーバーの管理画面が復旧してからになります。ファイルの更新日時を一覧で見る機能がそちらにあるためです。私もこの記事を書いている時点では終えていないので、「安全だった」とは書けません。

まとめ

共用サーバーでは PHP 本体の更新を利用者ができないので、修正が届くのを待つことになります。ただし待っていれば必ず届くわけではなく、前提として「サポートが続いている系列を使っていること」が要ります。

• 自分のサイトの PHP バージョンは、WordPress の「ツール」→「サイトヘルス」→「情報」→「サーバー」で確認できる
• サーバー会社の管理画面が止まっていても、この経路なら読める
• 外部から HTTP ヘッダーを見ても分からない。確認には管理画面へのログインが要る
• PHP 8.1 以前を使っているなら、自分で新しい系列へ切り替える。PHP 公式からは修正版が出ないので、サーバー会社の独自対応を待つことになり、届くとしても遅れる
• バージョン番号が古いままでも、サーバー会社が独自に修正を当てていることがある。番号だけでは判断できない
• 私の環境では、確認した日のうちに 8.2.35 が適用された

脆弱性そのものの内容や、国内でどれくらいの影響が出たかは、GMO Flatt Security の解説と piyolog のまとめが詳しいです。攻撃の仕組みと各社の対応状況は、そちらをご覧ください。

同じエックスサーバー上の WordPress を扱った記事として、WordPress MCPをClaudeに繋ぐ｜エックスサーバーで動かすまでの全手順もあります。

なお、管理画面の構成やサポート期限は変わります。実際に確認するときは、最新を公式のページでご確認ください。