XserverのWordPressがPHP 8.1だった。緊急の脆弱性修正で8.3へ切り替えた判断と、前後の確かめ方

XserverのWordPressがPHP 8.1だった。緊急の脆弱性修正で8.3へ切り替えた判断と、前後の確かめ方 AI活用術

課題

このブログは、レンタルサーバーのXserverでWordPressを動かしている。

2026年10月21日、PHP（WordPressを動かしているプログラムの言語）から、緊急の修正が出た。ログインしなくても、外からサーバー上で好きなプログラムを動かされうる（遠隔でのコード実行）、という重い脆弱性が2つ。翌22日、このニュースを見た自分は、AIに「自分のWordPressも影響を受けそうなので、解析してほしい」と頼んだ。

レンタルサーバーを使っていると、PHPのことはサーバー会社に任せきりになりがち。でも今回は、自分のブログのPHPの版が、公式の修正の対象から外れていた。

解決できるようにすること

共有のレンタルサーバーでWordPressを運営している人が、同じような緊急の修正が出たときに、次の4つを自分でできるようにする。

  1. 自分のサイトのPHPの版を確かめる
  2. どの版へ切り替えるかを、理由つきで決める
  3. 事故の最中で管理画面に入りにくいときの入口を知っておく
  4. 切り替えの前と後で、サイトが壊れていないかを確かめる

先に結論

  • PHP公式の修正版は8.5.12・8.4.27・8.3.36・8.2.35。PHP 8.1以前には、修正を入れた新しい版は出ない
  • 自分のブログはPHP 8.1.34だった。WordPressやプラグインを更新しても、PHP本体の不具合は直らない
  • Xserverのお知らせ（判断に使った10月22日9:30時点の内容）では、8.2〜8.5は修正済み、古い版は順次対応中で、8.1の完了は書かれていなかった
  • サーバーパネルでPHPを8.3系へ切り替えた。切り替え後のサイトヘルスは8.3.36で、公式の修正版と同じ番号になった。公開ページ8か所の状態は、切り替え前と同じだった
  • あとで更新されたXserverのお知らせには、7.4〜8.1の修正の適用が12:00に完了と書かれていた。ただ、自分のサイトの8.1にそれが入っていたかは、版の番号からは確かめられない

この記事でわかること

  • WordPressの画面だけで、PHPの版と動き方を確かめる場所
  • 版ごとに、次に何をすればいいか（図あり）
  • 8.3を選び、8.4と8.2を選ばなかった理由
  • サーバー会社の公式サイトが止まっているときに、どこから入ったか
  • 切り替えの前後で比べた8か所と、確かめられていないこと

こう思う人もいるかもしれない。

「レンタルサーバーなんだから、PHPの修正はサーバー会社が全部やってくれるのでは？」

8.2〜8.5については、今回もそうだった。困るのは、もう公式のサポートが終わった古い版を使っている場合。PHP公式からは修正版が出ないので、サーバー会社が独自に直すのを待つか、自分でサポート中の版へ切り替えるかになる。そして、どの版を使うかは、サーバーパネルで自分が選んでいる設定。ここは任せきりにできない部分だった。

10月21日に出た、PHPの緊急の修正

PHP公式のお知らせ（Security advisory: Critical remote code execution vulnerabilities, update now、2026年10月22日に確認）の要点は、次のとおり。

  • 修正されたのは、CVE-2026-109618とCVE-2026-109619の2つ。どちらも、ログインなしで遠隔からコードを実行されうる
  • 修正版は、PHP 8.5.12・8.4.27・8.3.36・8.2.35
  • 対象は、Webのリクエストを処理しているPHPすべて。PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedが挙がっている
  • PHP 8.1以前は、PHP公式の更新対象から外れている。提供元（Linuxのディストリビューションなど）に聞くか、サポート中の版へ上げるように、とある。重大さを考えて、ソースから自分でビルドする人向けに、7.4・8.0・8.1用の最小限の修正も公開されたが、修正を入れた新しい版の番号は出ていない

GitHubに出ている2つの勧告（GHSA-w8hw-w9fx-j79w、GHSA-6wmf-4rv5-p3rp）では、深刻度はどちらもCVSS v4.0（脆弱性の深刻さを0〜10で表す指標）で9.2、区分は「Critical」。2つ目の勧告には、PHP-FPMに対しても遠隔でのコード実行が確かめられた、と書かれている。

もう1つ大事なのが、1つ目の勧告の「mod_phpでは、アプリのコードが動き出す前に攻撃が成立する」という説明。WordPressはPHPの上で動くアプリなので、WordPress本体やプラグインを最新にしても、PHP本体の不具合は直らない。直すには、PHPそのものを修正版にする必要がある。

自分のブログのPHPは、8.1.34だった

AIに確かめてもらうと、このブログのPHPは8.1.34。動き方（サーバーAPI）はPHP-FPMだった。

PHPの公式ページ（Unsupported Branches、2026年10月22日に確認）によると、8.1は2025年12月31日でサポートが終わっていて、最後の版が8.1.34。つまり、公式の修正版が出ない側に入っていた。

この確認は、WordPressの管理画面だけでできる。

  1. 管理画面の「ツール」→「サイトヘルス」を開く
  2. 上のタブを「情報」に切り替える
  3. 「サーバー」の項目を開く
  4. 「PHPのバージョン」と「サーバーAPI」を見る

自分のブログでは、ここに「8.1.34」と、PHP-FPMを表す「fpm-fcgi」が出ていた。

Xserverのお知らせで分かったこと、分からなかったこと

2026年10月21日から22日までの時系列を、左にXserverのお知らせの経過表、右に自分のブログで起きたことの2列で並べた図。Xserverは21日16:00に公式サイトと管理画面を停止し、23:00頃にPHPの修正版が公開され、22日6:45に8.2〜8.5の修正を終え、9:30から管理画面を順次再開した。自分は9:30時点のお知らせを読んで8.3への切り替えを決め、12時台に切り替え前の確認をし、臨時のログイン入口から8.3系へ切り替え、13:25に切り替え後を確認した。7.4〜8.1の修正が12:00に終わったという行は、判断に使った9:30時点の内容には無く、あとで更新された経過表に載っていた

次に、Xserverのお知らせを見た。

判断に使ったのは、10月22日9:30時点の内容。そこには、PHP 8.2〜8.5は修正済み、古い版は順次修正を進めている、とあった。ただ、8.1が終わったかどうかは書かれていなかった。

Xserverは、10月21日16:00から、公式サイトや管理画面などを予防のために止めていた。このあたりの経過は、同じお知らせ（予防的な安全対策に伴う公式サイト・管理画面等の一時停止のお知らせ、20:10時点の版を2026年10月22日の23時台に確認）にまとめられている。お知らせによると、利用者のサーバーは動き続けていて、Webサイトの表示に影響は無い。止めたのは不正アクセスが起きたからではない、とも書かれている。

そのお知らせの経過表を、あとから見直すと、こう並んでいた。

  • 10月21日 〜12:00 発表前の不正アクセスの危険を下げる措置（利用者の環境にも）
  • 10月21日 16:00 公式サイト・管理画面などを停止
  • 10月21日 23:00頃 PHPの修正版と詳細が公開
  • 10月22日 06:45 PHP 8.2〜8.5の修正の適用が完了
  • 10月22日 09:30〜 管理画面などを順次再開
  • 10月22日 12:00 PHP 7.4〜8.1の修正の適用が完了
  • 10月22日 20:10〜 各種サービスサイトを順次再開

Xserverの経過表の上では、8.1の修正の適用完了（12:00）は、自分が切り替えた12時台〜13時台より前の時刻になっている。判断に使った9:30時点の内容には、その行はまだ無かった。そして、自分のサイトの8.1に修正が入っていたかどうかは、確かめていない。

ここで1つ気づいたことがある。8.2〜8.5なら、サイトヘルスの番号が修正版と同じになったかで、自分の目で確かめられる。でも8.1は、公式の最後の版がもう8.1.34なので、サーバー会社が独自に直しても、比べる相手になる番号が無い。サイトヘルスを見ても、直ったかどうかは分からない（これはAIと整理した見立てで、Xserverが番号をどう扱っているかは確かめていない）。

公式が出した修正版の番号、サーバー会社のお知らせ、自分のサイトの画面。この3つが同じことを言っているかを、自分で突き合わせられるのは、サポート中の版を使っているときだけ、ということになる。

8.3を選んだ理由。8.4と8.2を選ばなかった理由

WordPressのサイトヘルスでPHPのバージョンを見て、次にやることを3つに分けた図。8.2〜8.5で番号が修正版（8.5.12・8.4.27・8.3.36・8.2.35）と同じか新しければ修正版になっているが、8.2は2026年12月31日で公式の修正が終わる。8.2〜8.5で番号が小さければホスティングのお知らせを見て、反映待ちか問い合わせか切り替えを決める。8.1以下なら公式の修正版は出ないので、修正が2027年末まで続く8.3か、2028年末まで続く8.4へ切り替える。自分のブログは8.1.34から8.3.36へ切り替えた

AIが出した案の中から、自分はPHPを8.3系へ切り替える案を選んだ。理由はこう記録している。

  • 8.4にしなかった理由: 新しすぎる版だと、使っているプラグインとの相性で不具合が出る危険がある、と見込んだ。これは推測で、8.4で実際に試したわけではない
  • 8.2にしなかった理由: 8.2は、2026年12月31日でPHP公式の修正が終わる。2か月後にまた同じ切り替えをすることになる
  • 戻し方: 不具合が出たら、同じ画面で8.1へ戻す

PHP公式のSupported Versions（2026年10月22日に確認）では、修正が続く期限は、8.3が2027年12月31日、8.4が2028年12月31日、8.5が2029年12月31日。8.3でも1年あまりは修正が続く。

上の図は、今回の記録とPHP公式の期限をもとに、版ごとの次の一手をAIと整理したもの。プラグインを日ごろから更新しているサイトなら、期限の長い8.4を選ぶ考え方も十分ある。自分の場合は、緊急の切り替えで不具合を出さないことを優先して、プラグインとの相性を考え8.3に落ち着いた。

管理画面に、いつもの入口から入れなかった

切り替えは、自分がXserverのサーバーパネルで行った。PHPの版を変える画面は「PHP Ver.切替」という名前で、このブログのドメインを8.1から8.3系へ変えた。

ただ、そこまでが大変だった。Xserverの公式サイトは止まったままで、いつもの公式サイトからログインする流れが使えない。代わりに、お知らせのページに臨時のログイン入口が載っていて、そこからサーバーパネルに入った。混雑していて、つながるまで時間がかかった。

お知らせの経過表を見ると、管理画面そのものは9:30から順次再開していて、公式サイトなどの再開は20:10から。管理画面は開いているのに、そこへの道になる公式サイトが閉じていた、という状態だったのだと思う（ここは経過表から考えたことで、Xserverの説明ではない）。

こういうときに気をつけたいのは、入口の探し方。同じ日のXserverのニュース一覧には、Xserverを装ったフィッシングメールへの注意も載っていた。事故の最中は「こちらからログインしてください」というメールが来ても、それを使わない。サーバー会社のお知らせのページや公式のSNSアカウントで、案内されている入口を自分でたどるほうが安全になる。

切り替えの前と後で、同じものを比べた

切り替えの前と後で比べた項目の表。トップのリダイレクト、ブログのトップページ、記事のページ3本、REST API、プライバシーポリシーは、切り替え前に状態を記録し、切り替え後も前と同じだった。sitemap.xmlは切り替え前から404で、切り替え後も同じ。ページ内のPHPのエラーや警告の文字は前後とも無し。サイトヘルスのPHPのバージョンは8.1.34から8.3.36に変わった。記事の編集画面は切り替え後に開けた。どれも表示の確認で、攻撃を受けていないことの確認ではない

切り替える前に、AIに公開ページ8か所の状態を記録してもらった。トップ（ブログへのリダイレクト）、ブログのトップ、記事3本、REST API（記事のデータを外から読める出口）、sitemap.xml、プライバシーポリシー。それぞれについて、HTTPの状態（ページが返ってきたか）と、ページの中にPHPのエラーや警告の文字が出ていないかを見た。

切り替えたあと、13:25に同じ8か所を同じ方法で見直した。結果は、切り替え前とすべて同じ。サイトヘルスのPHPのバージョンは8.3.36（PHP-FPM）になっていて、PHP公式の修正版と同じ番号だった。記事の編集画面も、問題なく開いた。

8.1のときには比べる相手が無かった番号を、ここでやっと公式の修正版と突き合わせられた。

1つ、比べ方で大事だったのがsitemap.xml。これは切り替える前から404（ページが見つからない）だった。「全部が正常か」を見ていたら、ここで「切り替えで壊れた」と勘違いしたかもしれない。見るべきは「切り替えの前と同じか」。だから、切り替える前に記録を取っておくことに意味がある。

自分でやるなら、AIに頼まなくても、ブラウザで同じページを開くだけでいい。ページの一番上や途中に「Warning:」「Fatal error:」「Deprecated:」のような英語の文字が出ていないか、レイアウトが崩れていないかを見る。コマンドを使える人なら、たとえば次のような形で、状態の番号とエラーの文字の有無を前後で比べられる（URLは自分のサイトに置き換える）。

curl -s -o /dev/null -w "%{http_code}\n" https://example.com/
curl -s https://example.com/ | grep -E "Fatal error|Warning:|Deprecated:|Parse error" || echo "エラーの文字なし"

確かめられたこと、確かめられていないこと

確かめられたのは、PHPが8.3.36になったことと、比べた8か所の表示が切り替え前と同じだったこと。ここまで。

確かめられていないことも、はっきりさせておく。

  • 攻撃を受けたかどうか: 管理者のユーザーが増えていないことは見たけれど、それは攻撃されていない証明にはならない。2つ目の勧告にも、ログにエラーが無いことは安全の証明にならない、と書かれている
  • 切り替える前の8.1に、Xserverの修正が入っていたか: お知らせには12:00に完了とあるが、自分のサイトでは確かめていない
  • 8.4での相性: 試していない。8.4を避けたのは見込み
  • テーマとプラグインの見直し: 今回の脆弱性とは別に、PHPの切り替えが落ち着いたあとで、テーマとプラグインの更新を別の作業として見直す

設定での回避は、代わりにならない

PHPのお知らせには、すぐに更新できない人向けの設定も載っている。たとえばsession.upload_progress.enabled=0にして、すべてのワーカー（PHPの処理を受け持つプロセス）を再起動する、といったもの。

ただ、お知らせ自体が「完全な解決は更新だけ。これらの設定は特定の攻撃の道を狭めるが、安全にするものではない」と書いている。しかもこの設定は、php.ini、FPMのプール、サーバーの設定のように、リクエストを読む前に効く場所で行うように、とある。ini_set()やFPMの.user.iniには頼らないように、とまで書かれている。

共有のレンタルサーバーで利用者が触れる設定が、このどれに当たるのかは、利用者の側からは分かりにくい（ここはAIの見立て）。自分の記録に残っている方針は、設定での回避ではなく、修正版のあるPHPへの切り替えだった。

チェックリスト

ふだんからやっておくこと

  1. サイトヘルスで、PHPの版を年に数回見る。「ツール」→「サイトヘルス」→「情報」→「サーバー」
  2. その版のサポートがいつまでかを知っておく。PHP公式の「Supported Versions」に期限が載っている
  3. プラグインを更新しておく。古いプラグインが残っていると、新しいPHPを選びにくくなる

緊急の修正が出たとき

  1. 公式の修正版の番号と、自分の版を比べる。番号が修正版と同じか新しければ、修正版になっている
  2. ホスティングのお知らせで、自分の版の対応状況を見る。お知らせは更新されていくので、見た時刻も控える
  3. 公式の修正が出ない版なら、サポート中の版へ切り替える。期限の短い版（今なら8.2）は避ける
  4. 管理画面への入口は、お知らせのページや公式アカウントの案内から自分でたどる。メールのリンクは使わない

切り替えるとき

  1. 切り替える前に、公開ページを数か所、状態を控える。もともと404のページがあれば、それも控える
  2. 戻し方を先に決めておく。多くの場合、同じ画面で元の版に戻せる
  3. 切り替えたら、同じ場所を同じ方法で見直す。サイトヘルスの番号と、記事の編集画面が開くかも見る

こんな人に向いている

レンタルサーバーで、個人のWordPressブログを運営している人に向いている。特に、サーバーを契約したときの設定のまま、PHPの版を意識したことがない人。「WordPressは最新にしているから大丈夫」と思っている人にも、PHPは別に見る必要がある、という話として役に立つと思う。

まとめ

PHPの緊急の修正は、WordPressの更新では直らない。自分のブログは、PHP公式の修正が出ない8.1を使っていた。サーバー会社のお知らせは時間とともに更新されていき、判断した時点では8.1の扱いが分からなかった。だから、修正版の番号を自分の画面で確かめられる8.3へ切り替えた。切り替えの前後で同じ8か所を比べ、変わったのはPHPの版だけだった。

項目内容
結論ブログのPHPを8.1.34から8.3.36（PHP公式の修正版）へ切り替えた。公開ページ8か所の状態は前後で同じで、編集画面も開いた
教訓公式の修正版の番号、サーバー会社のお知らせ、自分のサイトヘルスの3つを突き合わせる。番号で確かめられるのは、サポート中の版だけ。切り替えるなら、前の状態を控えてから
対象読者共有のレンタルサーバーでWordPressブログを個人で運営している人

同じ状況に陥ったときの回避策

  • まずサイトヘルスで、PHPの版を確かめる。WordPressの更新だけで安心しない
  • PHP公式の修正が出ない版なら、ホスティングのお知らせを見つつ、サポート中の版への切り替えを考える
  • 切り替え先は、修正が続く期限と、使っているプラグインの古さで選ぶ
  • 管理画面に入りにくいときは、お知らせのページや公式アカウントが案内する入口を使う
  • 切り替える前に公開ページの状態を控え、切り替えたら同じ方法で比べる。「前と同じか」を見る
  • 表示の確認は、攻撃を受けていないことの確認ではないと覚えておく

次に読むなら

参考にした公式の情報（2026年10月22日に確認）

この記事は、筆者が個人で運営しているこのブログの運用記録（2026年10月22日）と、PHP公式・Xserverの公開情報を基に、独自調整したAIが下書きを作成し、筆者が事実確認・編集を行った上で公開しています。

トップへ戻る
タイトルとURLをコピーしました