2026年10月21日、PHPの開発チームが、認証なしで遠隔からコードを実行されるおそれのある脆弱性2件（CVE-2026-109618／CVE-2026-109619、CVSS v4.0 9.2）を修正したリリースを出しました。

この記事は、サーバーを管理している人向けに「Webのリクエストを処理しているPHPが、本当に修正版になっているか」を確かめる手順をまとめたものです。公式の発表の要点は最後の「参考」にまとめています。

修正版

8.1以前は公式のリリースが出ません（7.4／8.0／8.1向けの最小限のバックポートがGitHubで公開されています）。

公式の発表では、Webのリクエストを処理するPHPはすべて対象で、PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedが挙げられています。mod_phpがいちばん危険度が高いとされています。

1. CLIのバージョンだけで安心しない

php -v

これで出るのはコマンドラインのPHPです。Webで使われているPHP（FPMやmod_php）とは、別のバイナリ・別のバージョンのことがよくあります。

FPMを使っている場合は、FPMのバイナリも確認します。

# 名前はディストリビューションで違います（例：php-fpm8.3）
php-fpm -v
# 動いているFPMのプロセスと、どの設定で起動しているか
ps aux | grep [p]hp-fpm

Apacheでmod_phpを使っているかは、読み込まれているモジュールで確認できます。

apachectl -M 2>/dev/null | grep -i php

いちばん確実なのは、Webサーバー経由でPHPに聞くことです。推測しにくい名前の一時ファイルを作り、確認したらすぐ消します。

<?php
// 確認したら必ず削除する
echo PHP_VERSION, ' / ', PHP_SAPI;

phpinfo() を置くのは、サーバーの情報が丸見えになるので避けたほうが安全です。使う場合も確認後すぐに削除してください。

OSのパッケージ（Debian／Ubuntu／RHELなど）でPHPを入れている場合、修正が**元のバージョン番号を上げずに取り込まれる（バックポート）**ことがあります。この場合、php -v の番号が上の表と一致しなくても修正済みのことがあり、逆に番号だけ見て判断すると誤ります。

お使いのディストリビューションのセキュリティ情報で、CVE-2026-109618／109619への対応状況とパッケージのバージョンを確認してください。

公式イメージを使っているなら、イメージを取り直してビルドし直し、動いているコンテナを入れ替えるまでが更新です。

docker pull php:8.3-fpm   # 使っているタグに合わせる
# ビルドし直して、コンテナを作り直す
docker compose build --pull && docker compose up -d

コンテナの中で、Web側のバージョンも確認します（上の2の手順）。

パッケージを更新しても、古いプロセスが動き続けていれば意味がありません。FPMやApacheを再起動して、2の手順でもう一度確かめます。

sudo systemctl restart php8.3-fpm   # サービス名は環境に合わせる
sudo systemctl restart apache2      # mod_phpの場合

公式の発表は「完全な対策は更新だけ」としています。そのうえで、特定の攻撃の経路を減らす設定が示されています。たとえば次のようなものです。

session.upload_progress.enabled=0 を php.ini かFPMのプールで設定し、すべてのワーカーを再起動する（ini_set() や .user.ini では効かない）
PHP 8.5 では fatal_error_backtraces=0 を設定して再起動する

設定が反映されたかは、Web側で確認します。

<?php
// 確認したら必ず削除する
var_dump(ini_get('session.upload_progress.enabled'));

公式は、これらはインストールを安全にするものではないと明記しています。あくまで更新までのつなぎです。

※この記事は、2026年10月21日時点のPHP公式の発表をもとに、AIを活用して作成しました。コマンドの名前やサービス名は環境によって違います。