PHP 脆弱性 CVE-2026-109618・109619｜php2shell と呼ばれる2件、修正版の公開前にやる準備

緊急時の対応表です（詳しい手順は各節）。

PHP は Composer で取り込む依存パッケージとは別に、実行環境として更新します。依存関係から入る攻撃と防御の全体像はサプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説にまとめています。本記事は修正版が出る前の準備が主で、影響する版と修正版は公開後に追記します。

PHP 脆弱性 CVE-2026-109618・109619 の時系列（タイムライン）

日時は日本時間です。出典が別の時間帯で書いている時刻は、カッコに添えました。

悪用について、watchTowr は観測していないと述べています。Threat Landscape によれば、2件の CVE は予約の状態で、説明はまだ公開されていません。

公式が言っていること・報道だけのこと（php2shell の呼び名も）

公式の告知は短く、影響範囲はまだ書かれていません。報道で出回っている数字と、公式が書いたことを分けます。

CVE 番号は watchTowr の FAQ などが挙げているものです。公開時の公式の告知で突き合わせてください。

php2shell という呼び名と、出回るコードの扱い

海外の研究者の X の投稿や、watchTowr の「Rapid Reaction」を引用した投稿で、CVE-2026-109618 が「php2shell」と呼ばれて話題になっていると報じられています。PHP の公式はこの呼び名を使っておらず、php2shell が2件のどちらを指すのか、同じものなのかも確認していません。7月の WordPress の wp2shell（CVE-2026-63030）とは別の件です。

SNS やコードの共有サイトに「PoC」と称するコードが出ても、本番のサーバーや業務の端末で動かさないでください。中身を確かめられないコードを動かすこと自体が危険です。自分の環境が当てはまるかは、修正版の告知に出る影響する版と、次の節で控えた版を比べて決めます。

今日やる準備：PHP の在りか・版・更新の段取り

影響する版が分からなくても、どこで PHP が動いていて、誰が更新するかは今日のうちに洗い出せます。

パッケージの出どころで、修正の届き方が変わる

・OS の標準のリポジトリ（Ubuntu・Debian・RHEL 系など）：配布元が修正を自分のパッケージに取り込んで出す。版の番号は上がらないことがあり、Ubuntu 24.04 の php8.3-cli は 8.3.6-0ubuntu0.24.04.12 で、php -v は 8.3.6 と出る（2026-10-21 確認）。判断は配布元のセキュリティ告知で
・Ondřej Surý のリポジトリ（Ubuntu の ppa:ondrej/php、Debian の packages.sury.org）と Remi のリポジトリ（RHEL 系）：上流の版を追って出す。EOL の系列を入れているなら、その系列に修正が出るかはそれぞれの告知を見る
・Docker の公式イメージ（php:8.3-fpm など）：新しい版でタグが作り直されるのを待ち、自分のイメージを作り直す
・ソースからのビルド・PHP を組み込んだ製品：自分でビルドし直すか、製品の更新を待つ

23:00 の公開に向けて決めておくこと

・担当と時間：日本時間の夜になる。翌朝に回すなら、それまで外から届く範囲を絞る
・再起動する対象：PHP-FPM（Ubuntu・Debian では php8.3-fpm のように系列ごとの名前）、mod_php なら Apache、常駐するワーカー（キューのワーカーなど）。cron から呼ぶ CLI は次の実行から新しい版になる
・試験と戻し方：CI を本番と同じ版で回せるか。前のパッケージ・前のイメージに戻す手順
・公開前の緩和：公式の案内はまだ無いが、GMO Flatt Security は独自調査から、原因を Session Upload Progress 機能（既定で有効）に関係すると見て、緩和策候補に session.upload_progress.enabled=0（php.ini）を挙げている。確定ではなく、この機能に依存しないか確認のうえで。WAF の仮想パッチは攻撃の形が判明してから（仮想パッチとは）

修正版を当てるまでの検知：process-watcher の PHP 向け手引き

Florian Roth（Neo23x0）は、自作の process-watcher に PHP 向けの手引きを 2026-10-20 に足しました（GPL-3.0）。eBPF で、PHP-FPM・mod_php・php-cgi・PHP の CLI が起動したプログラムとそのコマンドラインを記録します。特定の脆弱性に依存しない追加の検知の層で、修正の代わりにはなりません。本記事は動かしておらず未検証です。手順は作者の README を参照してください。

PHP のアップデート方法（版の確かめ方）：自システムの確認コマンド

どれも読み取りだけのコマンドです。見ているのは「どこで何版の PHP が動いているか」と「その系列がサポート中か」で、影響を受けるかの判定ではありません。影響する版は修正版の告知で公表されるので、その表とこの結果を突き合わせます。

1. リポジトリ：コンテナ・Composer・CI で指定している版

アプリのリポジトリのルートで実行します。

git fetch --all --prune
git grep -nE '^FROM +([^ ]+/)?php:|image: *([^ ]+/)?php:' origin/main -- '*Dockerfile*' '*compose*.yml' '*compose*.yaml'
git grep -nE '"php" *:' origin/main -- '*composer.json'
git grep -nE 'php-version|image: *([^ ]+/)?php:' origin/main -- .github/workflows .gitlab-ci.yml

origin/main は配備するブランチに置き換えます。2行目はコンテナの元にする PHP のイメージ、3行目は Composer が求める PHP の版、4行目は CI で使う版です。composer.json の "php" は動かせる版の範囲の指定で、本番で動いている版そのものではありません。

2. サーバー：動いている PHP と PHP-FPM の版

php -v | head -n 1
for b in php-fpm php-fpm8.5 php-fpm8.4 php-fpm8.3 php-fpm8.2 php-fpm8.1 php-fpm8.0 php-fpm7.4; do command -v "$b" >/dev/null && echo "$b: $("$b" -v | head -n 1)"; done
for pid in $(pgrep '^php'); do sudo readlink "/proc/$pid/exe"; done | sort | uniq -c
apache2ctl -M 2>/dev/null | grep -i php
dpkg -l | awk '/^ii/ && $2 ~ /^(php[0-9.]*-(cli|fpm|cgi|common)|libapache2-mod-php)/ {print $2, $3}'
for c in $(docker ps -q); do echo "$c: $(docker exec "$c" php -v 2>/dev/null | head -n 1)"; done

1行目はコマンドラインの PHP、2行目は PHP-FPM の版です。3行目は動いているプロセスの実体で、ウェブで実際に動いている版はここで分かります。4行目に php_module が出れば、Apache に組み込んだ mod_php で動いています。5行目は Ubuntu・Debian のパッケージの版です（RHEL 系では代わりに rpm -qa 'php*'）。6行目は動いているコンテナの中の版です。

3. サーバー内の PHP をすべて洗い出す

管理パネル（cPanel・Plesk）や Remi で複数の版を入れた構成では、php -v で出る版のほかに別の版が入っていることがあります。探すのは、usr と opt の下にある bin のディレクトリ（usr/local/bin/ や usr/sbin/ など）の php・php8.3・php-fpm といった名前のファイルです。公式の Docker イメージは usr/local/bin/ に置きます。ルートに移ってから実行します。

cd / && pwd
find usr opt -xdev -type f -path '*bin/*' \( -name php -o -name 'php5*' -o -name 'php7*' -o -name 'php8*' -o -name 'php-fpm*' -o -name 'php-cgi*' \) -print
for b in $(find usr opt -xdev -type f -path '*bin/*' \( -name php -o -name 'php5*' -o -name 'php7*' -o -name 'php8*' -o -name 'php-fpm*' -o -name 'php-cgi*' \) 2>/dev/null); do echo "/$b: $("/$b" -v 2>/dev/null | head -n 1)"; done

2行目が見つけたファイルの一覧、3行目がそれぞれの版です。ソースからビルドした PHP を /home や /srv に置いているなら、2・3行目の usr opt の後ろに足します。

4. 版を系列ごとに振り分ける

printf '%s\n' 'PHP 8.5.1 (cli)' 'PHP 8.3.6 (fpm-fcgi)' 'PHP 8.1.31 (cli)' 'PHP 7.4.33 (cli)' | awk 'match($0, /PHP [0-9]+\.[0-9]+/) { s = substr($0, RSTART + 4, RLENGTH - 4); st = "EOL（公式のサポート外）"; if (s == "8.4" || s == "8.5") st = "アクティブサポート中"; if (s == "8.3") st = "セキュリティ修正のみ（2027-12-31まで）"; if (s == "8.2") st = "セキュリティ修正のみ（2026-12-31まで）"; print s, st, "|", $0 }'

printf の4行は例です。3. の3行目の末尾に | awk '…'（この awk の部分）をつなげば、見つけた版をまとめて振り分けます。期限は 2026-10-21 時点の公式のサポート表によります。

結果の読み方と、このコマンドの限界

掲載したままのコマンドを、Ubuntu 24.04 に PHP 8.3 の CLI・PHP-FPM・mod_php を入れた環境と、ダミーの構成で走らせました。

1. の6行目（コンテナ）は Docker の代わりの模擬コマンドで出力の形だけを確かめ、実際の Docker では試していません。rpm -qa は PHP の RPM が無い環境でだけ走らせました。

読むときの注意は3つです。

・何も出なくても PHP が無いとは限らない：止まっているコンテナ、レジストリにだけあるイメージ、別のサーバー、共用サーバーで選べる別の版は拾わない。3. は usr と opt の下の bin のディレクトリしか見ていない
・版の番号だけでは判断できない：OS の配布元は修正を取り込んでも番号を上げないことがある（上の Ubuntu の例）。公式の修正版の番号と比べられるのは、Docker の公式イメージ・Sury・Remi・ソースからのビルド。OS のパッケージは、配布元の告知に出るパッケージの版と比べる
・振り分けはサポートの状態で、影響の判定ではない：サポート中の系列でも影響を受けうる。影響する版は公開時の告知で確かめる

PHP EOL・サポート期限：修正が出ない系列を使っている場合

公式のサポート表（2026-10-21 時点）では、各系列の期限は次のとおりです。

EOL の系列は公式の修正の対象外です。今回の2件で EOL の系列に修正版が出るかは、報道ごとに食い違い、公式は告知で触れていません。出ない前提で段取りを組み、出たら使います。

・上げる：サポート中の系列へ。8.2 は年末に期限が来るので、上げるなら 8.3 以降。アプリと拡張の互換性を試験する
・配布元のサポートを使う：OS の配布元が自分のサポート期間に修正を出す系列（Ubuntu 22.04 の PHP 8.1 など）なら、配布元の告知を待つ
・延長サポートを検討する：EOL の PHP 向けに修正を出す商用のサービスがある。今回の2件を対象にするかは、各社に確かめる
・隔離する・公開側を閉じる：上げるまでは、インターネットから直接届かないようにする。社内や特定の IP からだけにする、使っていない機能やアプリを止める

PHP 脆弱性の修正版が出たらやること（PHP-FPM の再起動まで）

1. 公式の告知で、影響する版・修正版・悪用の条件を確かめる（23:00 以降。早まることがある）
2. 自分の出どころの修正を当てる。OS のパッケージなら配布元の告知に出る版、Docker の公式イメージなら新しいタグ、Sury・Remi なら公式の修正版
3. 再起動する。PHP-FPM、mod_php なら Apache、常駐するワーカー
4. 確認コマンドの 2. を走らせ直し、動いているプロセスが新しいバイナリか確かめる。パッケージを入れ替えたあとも古いプロセスが残っていると、3行目の実体に (deleted) が付く
5. コンテナはイメージを作り直して入れ替え、古いイメージで動くものが残っていないか確かめる

6. EOL の系列は前の節の段取りへ進む

7. の (deleted) は、動いている PHP のバイナリを別のファイルで置き換える操作で確かめました。パッケージの更新が PHP-FPM を自動で再起動するかは、配布元と設定で違います。

当てたあとの監視は、残っている記録しだいです。何を記録すべきかは連載の監査ログの設計｜事故のあとに「誰が・いつ・何を」答えるための記録項目にまとめています。

参照ソース

・PHP: News Archive - 2026（2026-10-20 の事前告知） — 2件・CVSS v4.0 で各 9.2・公開予定の日時・早める条件・詳細は公開時に出すこと
・PHP: Supported Versions — 系列ごとのサポートの期限と EOL
・[ANNOUNCE] Upcoming Critical PHP Security Release（php.announce） — 同じ事前告知のメーリングリスト版
・PHP Remote Code Execution FAQ: CVE-2026-109618 & CVE-2026-109619（watchTowr） — CVE 番号・悪用を観測していないこと
・PHP warns admins of two critical flaws, emergency patches coming tomorrow（BleepingComputer） — watchTowr の再現と、もともとの公表予定（木曜 11:00 ET）・PHP 5〜8 という見立て
・PHP Core RCEs CVE-2026-109618 and CVE-2026-109619 Leak Early（Threat Landscape） — Hacker News の投稿・CVE が予約の状態であること
・PHP Remote Code Execution (RCE) Rapid Response（Mallory） — 修正予定の版の番号（Kevin Beaumont の見立て。未確認）
・process-watcher：Watching PHP with process-watcher（Neo23x0） — PHP の下で起動したプログラムを記録する手引き・要件・できないこと（2026-10-20 更新）
・PHP の脆弱性 php2shell（CVE-2026-109618/109619）について（GMO Flatt Security） — 独自調査で Session Upload Progress に関わるとの見立てと、緩和策候補 session.upload_progress.enabled=0（確定前）