php2shell（CVE-2026-109618／109619）は php -v では判定できない — FPM・Docker・ディストリで版の数字がずれる所

Web リクエストを処理している PHP（PHP-FPM・Apache の mod_php・php-cgi・FrankenPHP・LiteSpeed）が 8.2.35／8.3.36／8.4.27／8.5.12 より前なら、php2shell と呼ばれる CVE-2026-109618 と CVE-2026-109619 の影響を受ける。直し方はこの修正版（ディストリのパッケージなら修正済みのパッケージ）へ上げてプロセスを再起動することで、確かめるべきは手元の php -v ではなく「Web を実際に動かしている PHP」と「入っているパッケージの版」だ。

この記事は、版の数字だけで判断すると間違える所を4つに絞ってまとめる。数字・状況はすべて 2026-10-22 時点 で、各項目の出典は末尾に並べた。

2026-10-22 時点で分かっていること

PHP の告知は「完全な対策は更新だけ」としている。更新までの間の緩和策は後半に書いた。

落とし穴1：php -v と Web 側の PHP は別物のことがある

SSH で打つ php -v は CLI 版の PHP の版を出す。Web を処理しているのは PHP-FPM のプロセスや Apache に読み込まれた mod_php で、これは別のバイナリ・別のパッケージだ。CLI だけ新しい PHP を入れた、複数の版を並べて入れている、FPM のプールが別の版を指している、といった構成では、php -v が修正版でも Web 側は古いままになる。

Web 側の本当の版を見る方法はいくつかある。

# Debian / Ubuntu の FPM（版ごとに名前が付いている）
php-fpm8.3 -v

# RHEL 系の FPM
php-fpm -v

# Apache に mod_php が読み込まれているか
apachectl -M | grep -i php

いちばん確実なのは、Web 経由で実際に実行される PHP に版を言わせること。推測されにくい名前のファイルを一時的に置いて、確かめたらすぐ消す。

<?php echo PHP_VERSION, ' ', PHP_SAPI;

PHP_SAPI が fpm-fcgi なら FPM、apache2handler なら mod_php、cgi-fcgi なら CGI で動いている。phpinfo() を出しっぱなしにするのは、それ自体が情報を漏らすので避ける。

もう1つ見落としやすいのが再起動だ。パッケージを入れ替えても、すでに動いている php-fpm や Apache のプロセスがそのまま古いコードで動き続けることがある。パッケージの更新時に自動で再起動される構成もあるが、されない構成もある。更新したら FPM／Apache を再起動し、上の方法で Web 側の版をもう一度確かめる。

落とし穴2：Docker は「タグの名前」では判断できない

公式イメージ php には、8.3 や 8.3-fpm のように中身が入れ替わる「動くタグ」と、8.3.30 のように版を固定したタグがある。

• 動くタグは Docker Hub 側で修正版に入れ替わっても、手元で pull し直すまでは古いイメージのまま。さらに、動いているコンテナは作り直すまで古いイメージで動き続ける。Dockerfile の FROM php:8.3-fpm も、ビルドのキャッシュに古いベースが残っていれば古いまま組み上がる。
• 固定したタグは、自分で番号を上げるまで永久に古い。

修正版のタグが出ているかは Docker Hub の API で確かめられる。

curl -s "https://hub.docker.com/v2/repositories/library/php/tags?name=8.3.36&page_size=100"

2026-10-22 に4つの系列で叩いた結果がこれ（時刻は UTC）。

このとき確かめて分かった、数字で判断すると迷う点が3つある。

1. 「最近更新された」は「直っている」ではない。固定タグ 8.3.35 は 2026-10-21 中に作り直されていたが、中の PHP_VERSION は 8.3.35 のままだった。更新日時ではなく中の版を見る。
2. digest が違っても中身が同じことがある。8.3 と 8.3.36 はタグの digest（複数アーキテクチャをまとめた索引の値）が違ったが、amd64 のイメージは同じもので、どちらも PHP_VERSION=8.3.36 だった。8.3-fpm／8.3.36-fpm、8.4-apache／8.4.27-apache、latest／8.5.12、8.5-fpm、8.2-fpm も同じく、amd64 のイメージの PHP_VERSION は修正版だった。
3. 8.1 以前の公式イメージには修正版が無い。8.1-fpm の最終更新は 2025-12-31 だった。

手元のイメージと動いているコンテナで確かめるならこう。

# 手元に pull 済みのイメージの PHP の版
docker image inspect php:8.3-fpm --format '{{range .Config.Env}}{{println .}}{{end}}' | grep PHP_VERSION

# 取り直して、コンテナを作り直す
docker compose pull
docker compose up -d

# 自分でビルドしているなら、ベースを取り直してからビルドする
docker compose build --pull

# 動いているコンテナの中の版
docker compose exec app php -r 'echo PHP_VERSION, PHP_EOL;'

最後の app は自分のサービス名に置き換える。公式イメージは1つのイメージに1つの PHP_VERSION でビルドされているので、コンテナの中の CLI の版はそのコンテナの FPM／Apache の版と同じになる（落とし穴1はホストに直接入れた場合の話）。

FrankenPHP は PHP を中に組み込んでいるので、FrankenPHP 自体の版と中の PHP の版は別の数字になる。2026-10-21 公開の FrankenPHP 1.13.2 のリリースノートには、Docker イメージは PHP 8.2.35／8.3.36／8.4.27／8.5.12、静的バイナリは PHP 8.5.12 でビルドしたと書かれている。

落とし穴3：ディストリのパッケージは「古い数字のまま直る」

Ubuntu と RHEL は、修正だけを古い版に移植（バックポート）する。php -v に出る数字は古いままなので、「8.3.36 より小さいから危ない」と数字で判定すると、直っているのに危ないと出る。逆に、数字だけ見て安心することもできない。判定はパッケージの版と、各ディストリのセキュリティトラッカーで行う。

2026-10-22 時点で各トラッカーに載っていた修正済みパッケージ（2つの CVE で同じ）。

数字だけでは判定できない例がこの表にそのまま出ている。Ubuntu 24.04 の修正済み PHP は 8.3.6 で始まる版で、upstream の 8.3.36 よりずっと小さい。RHEL 9 の標準の PHP は 8.0.30 のまま直っていて、upstream では 8.0 にはもう修正版が出ない。Debian は upstream と同じ番号（8.2.35／8.4.27）に上げている。

まだ直っていない所もある（2026-10-22 時点）。

• RHEL 9 の php モジュール 8.4 は「影響あり・修正なし」の扱い。
• Debian の forky（testing）は php8.4 8.4.26-1 で「vulnerable」。sid（unstable）の php8.4 は 8.4.27-1 で修正済み。

自分のサーバーで確かめるコマンドの例。

# Debian / Ubuntu：入っている版と、取得できる版
apt-cache policy php8.3-fpm libapache2-mod-php8.3

# Ubuntu：この CVE が自分のサーバーで直っているか
pro fix CVE-2026-109618
pro fix CVE-2026-109619

# RHEL 系：この CVE を直す更新があるか、入っている版
dnf updateinfo list --cve CVE-2026-109618
rpm -q php-fpm php-cli

パッケージ名（php8.3-fpm など）は自分の環境に合わせる。出てきた版を上の表やトラッカーの「修正済みの版」と比べ、それ以上なら修正は入っている。その後、落とし穴1の再起動と Web 側の確認まで済ませる。

なお、ディストリの標準ではなく外部のリポジトリから PHP を入れている場合は、そのリポジトリの更新を見る必要がある。PHP の告知は、ボランティアが運営する rpms.remirepo.net は公開当日には更新が出ないとして、ディストリのパッケージか自前のビルドへの切り替えを勧めている。

落とし穴4：共有レンタルサーバー・マネージド環境は自分では上げられない

共有のレンタルサーバーやマネージドの PHP 環境では、PHP 本体を入れ替えるのは事業者だ。ここでも数字だけでは判断できない。事業者が独自にビルドしたり修正を移植したりしていれば、版の数字は古いままのことがある。

自分でできるのはこの3つ。

1. Web 側の版を確かめる。落とし穴1の一時ファイルで PHP_VERSION と PHP_SAPI を出して、すぐ消す。管理画面に PHP の版を選ぶ画面があれば、どの版を選んでいるかも控える。
2. 事業者の告知を見て、無ければ問い合わせる。聞くことは「CVE-2026-109618 と CVE-2026-109619 の修正は、自分の契約のどの PHP の版に、いつ入るか（入ったか）」。版の数字ではなく CVE 番号で聞くと、バックポートの有無まで答えてもらえる。
3. サポートが切れた版を選んでいるなら上げる。8.1 以前は PHP プロジェクトから修正が出ない。8.2 も 2026-12-31 でサポートが終わる。事業者が修正を移植していない限り、版の切り替えが確実な道になる。

レンタルサーバー別の対応状況（2026-10-22 時点）

共用のレンタルサーバーでは、PHP 本体の更新は業者側で行うのが普通で、告知でも「利用者側の作業は不要」とする社が多い。利用者がやることは、契約中の会社の公式告知を確かめることと、管理画面で古い PHP の版を選んでいる場合に、告知が案内している版（修正版のある版）へ切り替えるかどうかを見ることの2つだ。

下の表は各社の公式ページ（お知らせ・メンテナンス情報）に書いてある内容だけをまとめたもので、告知の文言を要約している。告知は随時更新されるので、実際の状況は必ず出典の公式ページで確かめてほしい。

公式の告知が見つからない、または開けなかった社は、表に「確認できず」「見つけられなかった」と書いた。そこに載っていないことは、対応していないという意味ではない。契約中の会社のお知らせとサポートで直接確かめてほしい。

すぐに更新できない間の緩和策

PHP の告知には、更新までの間に攻撃の経路を減らす設定が載っている。ただし告知自身が「安全にはならない」と明記している。主なものは次のとおり。

• CVE-2026-109619 向け：session.upload_progress.enabled=0 を php.ini・FPM のプール・サーバーの設定で入れ、すべてのワーカーを再起動する（ini_set() や FPM の .user.ini では効かない）。PHP 8.5 では fatal_error_backtraces=0 も。
• CVE-2026-109618 向け：アプリから上書きできない形で memory_limit=-1 にし、post_max_size を小さくする（アップロードが無いなら 8M、あるなら 32M）。RLIMIT_AS／RLIMIT_DATA で代用しない。

英国の NCSC は、すぐに更新も緩和もできないシステムはオフラインにすることを検討し、更新や緩和の前に侵害の痕跡が無いかを確かめるよう勧めている。

出典（2026-10-22 に確認）

• php.net：Security advisory: Critical remote code execution vulnerabilities, update now（2026-10-21）
• php.net：Upcoming Critical PHP Security Release（2026-10-20）
• php.net：PHP 8.5.12／8.4.27／8.3.36／8.2.35 のリリース告知
• GitHub：GHSA-w8hw-w9fx-j79w（CVE-2026-109618）
• GitHub：GHSA-6wmf-4rv5-p3rp（CVE-2026-109619）
• Docker Hub：公式イメージ php
• FrankenPHP 1.13.2 リリースノート
• Debian Security Tracker：CVE-2026-109618／CVE-2026-109619
• Ubuntu：CVE-2026-109618／CVE-2026-109619／USN-8948-1／USN-8948-2
• Red Hat：CVE-2026-109618／CVE-2026-109619（修正済みパッケージの版は Red Hat の VEX データ）
• NCSC：Critical security issue affecting PHP