PHPの重大な脆弱性に対応。「更新されたはず」で終わらせないWebサイト保守の話
2026年10月21日、Webサイトの動作を支えるプログラミング言語「PHP」に、重大なセキュリティ上の問題を修正する緊急アップデートが公開されました。
私はWordPressとLaravelを使ったWebサイトを運営しているため、公式情報を確認し、本番環境の更新状況を調査しました。
今回は、その対応過程と、実際に確かめて気づいたことを紹介します。
何が起きたのか？
PHPは、WordPressをはじめ、多くのWebサイトやWebアプリケーションで使われている技術です。
今回公表されたのは、条件がそろうと、認証されていない第三者がサーバー上で不正なプログラムを実行できる可能性がある、重大な脆弱性です。
「脆弱性」とは、簡単にいえばシステムの安全性に関わる弱点のことです。
PHP公式は10月21日、2件の脆弱性を修正したバージョンを公開。私が利用しているPHP 8.3系では、8.3.35から8.3.36への更新が必要になりました。
ただし、脆弱性の存在と、実際に攻撃を受けたことは別の話です。大切なのは、被害が起きる前に状況を把握し、対策を確認することだと考えています。
サーバー会社に任せていれば大丈夫？
私が利用しているのは、国内レンタルサーバーの「エックスサーバー」です。
こうした環境では、PHP本体の更新は基本的にサーバー事業者の管理範囲です。利用者が直接更新作業を行わない場合もあります。
しかし、そこで疑問が生まれました。
「PHP公式が修正版を出したとして、自分のサイトでも実際に使われているのだろうか？」
10月22日の最初の確認では、WordPressの管理画面に表示されていたバージョンは、まだ8.3.35でした。
公式から修正版が公開されても、自分の利用環境へ反映されるまでには時間差がある。今回はそれを実際に確認することになりました。
実際に行った3段階の確認
① WordPressの管理画面で調べる
WordPressには、サイトの動作環境などを確認できる「サイトヘルス」という機能があります。
まずはそこでPHPのバージョンを確認しました。
当初は8.3.35でしたが、その後、8.3.36に更新されていることを確認できました。
② SSHでサーバー側を調べる
次に「SSH」という、サーバーへ遠隔接続する方法でPHPのバージョンを確認しました。
こちらでも8.3.36が利用できる状態になっていました。
ただし、ここには落とし穴があります。
SSHで確認するPHPと、訪問者がWebサイトにアクセスしたときに動くPHPは、必ずしも同じとは限りません。
「サーバー側で8.3.36と表示された」だけで、すべてのWebサイトが更新済みとは判断しないことにしました。
③ LaravelのWeb実行環境を直接調べる
Laravelは、PHPを使ってWebアプリケーションを開発するための仕組みです。
まず、その公開URLへアクセスし、正常な応答（HTTP 200）が返ることを確認しました。
しかし、サイトが表示できることと、安全なPHPバージョンで動いていることは別問題です。
そこで、公開ディレクトリに一時的な確認ファイルを設置し、実際のHTTPSアクセスを通じてPHPのバージョンだけを取得しました。
結果は、8.3.36。
Laravelを配置したドメインのWeb実行環境でも、緊急修正版のPHPが動いていると確認できました。確認用ファイルは調査が終わると削除される手順にしています。
なお、この確認で分かるのはWeb側のPHPバージョンです。Laravelのすべての機能が正常に動くかどうかは、別途テストする必要があります。
OpenAIもPHPの確認ツールを公開していた
今回の対応を調べるなかで、OpenAIがGitHub上に公開した「php2shell-checker」というツールも確認しました。
これはWebサイトやサーバーのPHPバージョンを調べ、今回の脆弱性に関して、修正版と判断できるかを確認するためのものです。
結果は大きく3種類に分かれます。
- OK： 取得したバージョンが、ツールの判定基準では修正版に該当する
- VULNERABLE： 取得したバージョンが、判定基準では影響を受ける範囲にある
- UNKNOWN： バージョンを取得できないなど、判断するための情報が足りない
ここで大切なのは、「UNKNOWN＝安全」ではないことです。
Webサイトによっては、外部にPHPのバージョン情報を公開していません。その場合、このツールだけでは判断できません。また、ツールは実際に攻撃を試して脆弱性を検証するものではなく、取得したバージョンを基準に判定しています。
私は今回、このツールを使って自分のサイトを検査したわけではありません。実際の確認には、WordPressの管理画面、SSH、Web経由のPHP実行結果を使用しました。
今回のような便利なツールを知っておくことは有益ですが、何を確認できて、何までは確認できないのかを理解して使うことが重要だと感じます。
今回の調査結果
2026年10月22日時点で、次の状態を確認しました。
確認対象確認結果
WordPress本番環境
PHP 8.3.36
Laravelを配置したWeb環境
PHP 8.3.36
SSHから使う標準PHP
PHP 8.3.36
これは修正版PHPの稼働確認であり、WordPressのフォーム送信やLaravelの全機能について、動作確認を完了したという意味ではありません。
Webサイト保守で大切なのは「更新後の確認」
今回、PHP本体の更新は利用しているサーバー事業者の管理範囲でした。私は自分でPHP本体を書き換えたわけではありません。
私が行ったのは、公式情報の確認、対象環境の特定、更新状況の追跡、そしてWebサイトで実際に使われるPHPの確認です。
Webサイトの保守というと、画面が崩れたときの修正や、WordPressのプラグイン更新を思い浮かべるかもしれません。
しかし、利用している技術の状態を把握し、問題が起きる前に対処することも大切な仕事です。
「サイトが表示されているから大丈夫」ではなく、「何が動いていて、どこまで確認できているかを説明できる」こと。
今回、その重要性を改めて実感しました。
最後に：作るだけでなく、安心して使い続けられるWebサイトへ
Webサイトは、公開したら完成というものではありません。
技術は日々更新され、新しい問題が見つかることもあります。
特に中小企業では、制作時の担当者が退職していたり、現在の管理状況が分からなくなっていたりするケースも考えられます。
私はWebサイトの制作・改修だけでなく、こうした運用面も含めて、既存の仕組みをなるべく壊さず、小さな改善を積み重ねることを大切にしています。
問題が起きてから直すだけでなく、問題に気づける状態をつくる。
今回の緊急セキュリティ対応は、その考え方を改めて確かめる機会になりました。
参考情報
※本記事は2026年10月22日時点の公開情報と、筆者自身の調査・検証結果をもとにまとめたものです。
