PHPは言語であり、それを動かすソフトウェアでもある

PHPは、プログラムを書くための言語です。Webサイトでは、記事をデータベースから取り出す、ログインを処理する、入力内容を保存するといった仕事に使われます。

ただし、PHPで書かれたプログラムは、そのファイルを置くだけで動くわけではありません。内容を読み取り、実際に処理するためのソフトウェアが必要です。これがPHPの実行環境です。

普段「PHP」と呼んでいるものには、プログラミング言語としてのPHPと、プログラムを実行するソフトウェアとしてのPHPという、二つの意味があります。

今回問題になっているのは、その実行を担うPHP本体の不具合です。サイト側のプログラムに問題がなくても、土台となる実行環境に影響があれば対処が必要になります（Wizの調査報告）。

PHPの動かし方は一つではない

PHPの実行環境には、バージョンだけでなく、Webサーバーとの連携方法にも違いがあります。

PHP-FPMはFastCGI方式の実装の一つです。また、FrankenPHPやLiteSpeedと組み合わせた構成もあります。「PHPを使っている」という点は同じでも、その動き方まで同じとは限りません（PHP-FPM、CLI）。

さらに、PHPには8.2系、8.3系、8.4系、8.5系などのバージョンがあります。同じ系列でも修正が積み重ねられるため、「PHP 8を使っている」という情報だけでは、今回の対策が済んでいるか判断できません。

レンタルサーバー、仮想サーバー、コンテナといった設置場所の違いもありますが、それだけで安全性が決まるわけではありません。どのPHPが、どの構成で、どんなリクエストを処理しているかを確認する必要があります。

CMSやWebサービスは、その上で動いている

WordPressやDrupalなどのCMSは、PHPで作られたアプリケーションです。独自開発の予約システムや会員サイト、WebサービスのAPIにもPHPは使われています。

CMSはコンテンツ管理を目的としたWebアプリケーションの一種です。Webサービスは、それらを利用者に提供する仕組み全体を指します。

典型的なPHP-FPM構成を簡略化すると、次のようになります。

図1：PHPという言語、実行環境、その上で動くアプリケーション。構成例であり、すべてのサイトが三種類のアプリケーションを動かすわけではありません。

利用者の端末でPHPを実行するのではなく、通常はサーバー側で処理し、その結果としてHTMLやJSONなどを返します。

この関係を考えると、CMSの更新とPHPの更新が別の作業であることも分かります。WordPress本体やプラグインを最新にしても、サーバー側のPHPまで更新されるとは限りません。

今回は、アプリケーションより下の層に問題がある

今回公表されたのは、PHP内部のメモリ不足時の処理や、リクエスト間に残る内部状態に関係する二つの脆弱性です。

• CVE-2026-109618：メモリ不足時のエラー処理に起因する問題
• CVE-2026-109619：リクエストの処理後に残る内部状態に関係する問題

PHP公式の告知は、Webリクエストを処理するPHPの各構成をリスクの対象として挙げています。特にmod_phpでは、アプリケーションのコードが動く前に、認証なしのリクエストで攻撃が成立する実証があるとしています。

そのため、「管理画面にはログインが必要」「自分で書いた処理では入力チェックをしている」といった対策だけでは、今回の問題を防げるとは限りません。

一方で、PHPをインストールしているだけで必ず侵害される、という話でもありません。攻撃の成立条件は、バージョンや実行方式、設定、リクエストが届く経路によって変わります。

「外から接続できない」の意味が重要になる

ここでいう接続は、サーバーに物理的に触れることではありません。攻撃者から送られたリクエストが、脆弱なPHPの処理に届くかどうかです。

例えば、PHP-FPMを内部ネットワークに置き、インターネットから直接接続できなくしていても、公開Webサーバーがリクエストを転送していれば、PHPは外部からの入力を処理します。

CDNやリバースプロキシの背後に置いた場合も同様です。サーバーのIPアドレスを隠すことと、PHPへの攻撃経路を断つことは別です。

反対に、外部からPHPへ届く経路を確実に遮断できれば、その経路からの攻撃は防げます。ただし、それは脆弱性が修正されたという意味ではありません。内部ネットワークや別の公開経路から到達できないかも確認が必要です。

メンテナンス画面を出す場合も、その画面自体をPHPで生成しているなら、PHPの処理は残っています。遮断するなら、PHPに渡す前の段階で止める必要があります。

PHP公式も、緩和策だけで安全になったと考えず、更新を行うよう求めています。

公開サイトとCMSを分けるという選択肢

記事やお知らせを中心とするサイトなら、CMSで生成したHTMLなどを、別の公開環境へ配信する構成も考えられます。

図2：動的配信と、CMSへの接続を制限した静的配信の比較。「内部に置いたこと」だけでは、PHPへの経路を断ったことにはなりません。

この構成で、閲覧リクエストがPHPへ転送される経路をなくせれば、公開ページを見るためにPHPを動かす必要がなくなります。今回のような問題に対して、公開側の攻撃経路を減らせる設計です。

ただし、静的サイトでも、検索やフォーム、会員機能などがPHPのAPIを呼んでいれば、その部分は別途確認が必要です。また、ヘッドレスCMSという名前だけで安全になるわけでもありません。公開APIをPHPで処理していれば、その実行環境は引き続き対策の対象です。

CMSを非公開にしても、CMS自体の更新が不要になるわけではありません。公開する範囲を絞ることと、ソフトウェアを保守することは、両方必要です。

まず確認したいこと

2026年10月23日時点で、今回の修正が入ったPHP公式のリリースは次のとおりです。

古い系列も影響を受けるため、この表にないバージョンなら安全ということではありません。PHP 8.1以前は公式の通常サポートが終了しています（IPAの対策情報）。

なお、OSやホスティング事業者が、以前のバージョンへ修正を取り込んだパッケージを提供する場合もあります。表示される番号だけで判断せず、提供元の対策情報を確認します。

サイトの運営者としては、次の点を管理会社やサーバー提供元に確認しておきたいところです。

• 公開サイトやAPIでPHPを使用しているか
• 実際にWebリクエストを処理しているPHPのバージョンと実行方式
• 今回の二つの脆弱性について、修正が適用されているか
• 未対応の場合、更新予定と、それまでのアクセス制限

正しく騒ぐために

ここからは私見ですが、こうした脆弱性については、必要なだけ、正しく騒ぐべきだと思っています。重大な問題を広く知らせ、対応を急ぐことには意味があります。

ただ、「PHPを使っていたら危険」「Webサイトを見るだけで危ない」といった、対象や条件を省いた伝え方では、何をすればよいのか分からないまま、不安だけが広がってしまいます。影響を受ける環境、確認すること、取るべき対策まで伝えてこそ、注意喚起として役に立ちます。

混乱は、別の犯罪につけ込まれる余地にもなりかねません。例えば「緊急の更新が必要」と偽のサイトへ誘導したり、「対策を代行する」と管理画面の認証情報を求めたりする口実です。今回そうした被害を確認したという話ではなく、不安をあおる発信が新たな被害の入口になることを懸念しています。

脆弱性の公表や報道そのものを控えるべきだとは思いません。必要なのは、危険の大きさと、その危険が生じる条件を一緒に伝えることです。発信する側も、共有する側も、公式情報への導線を添え、分かっていることと推測を分けたい。

この記事も含めて、読んだ人が慌てるだけで終わらず、自分に必要な確認と対策に進めるものにしたいと思います。

PHPは、CMSやWebサービスを支える土台です。普段は見えにくい部分ですが、サイトを公開し続けるなら、その土台も継続して更新する必要があります。

今回を機に、どこでPHPが動き、誰が更新を担当し、どこまで外部から到達できるのか。一度確認しておこうと思います。

参考：

• PHP公式：2026年のセキュリティ告知
• IPA：PHPの脆弱性対策について
• Wiz：PHP2Shellの調査報告
• PHP公式マニュアル：PHP-FPM
• PHP公式マニュアル：CLI