PHP2Shell対応後のUbuntu 26.04で、PHPが修正版になったか確かめるなら、まずパッケージの完全な番号を見ます。
dpkg-query -W php8.5-fpm
Ubuntu公式パッケージのPHP 8.5-FPMでは、8.5.4-0ubuntu1.5が今回の修正版です。 26.04の公式パッケージなら、この番号以上かを確認します。php -vに出る「8.5.4」だけでは判定できません。
PHP2Shellは、CVE-2026-109618とCVE-2026-109619の通称です。Ubuntuの公式解説のIntroductionとImpact of php2shellでは、認証なしのリモートコード実行につながり得ると説明されています。版の確認と、更新したPHPを実際の処理へ反映する確認を、一続きで進めましょう。
以下の例は、Ubuntu 26.04 LTS・Ubuntu公式パッケージのPHP 8.5-FPM・Nginxの構成です。コマンドは対象サーバーのBashで実行します。
なぜ、更新しても「8.5.4」のままなのか
Ubuntuでは、ソフトウェア全体を新しいバージョンへ入れ替える代わりに、必要なセキュリティ修正を既存のバージョンへ取り込むことがあります。これがバックポートです。
新機能までまとめて取り込むことによる動作の変化を抑え、既存環境との互換性を保つための方法です。Ubuntuのセキュリティ更新方針にも、この仕組みが説明されています。
そのため、上流のPHP本体では別の修正版番号が案内されていても、Ubuntu側では「8.5.4」に修正が入ります。見る場所は、後ろの-0ubuntu1.5まで含めたパッケージ番号です。
今回、私の環境で更新前後を確認した値は次のとおりでした。
| パッケージ | 更新前 | 更新後 |
|---|---|---|
| php8.5-fpm | 8.5.4-0ubuntu1.4 |
8.5.4-0ubuntu1.5 |
| php8.5-cli | 8.5.4-0ubuntu1.4 |
8.5.4-0ubuntu1.5 |
これは私の環境の記録です。一方、修正済みかを判断する基準は、UbuntuのUSN-8948-1にある、Ubuntu 26.04向けの一覧です。そこでもFPM・CLIの修正版は8.5.4-0ubuntu1.5になっています。
同じ更新ではphp8.5-commonも.5へ更新しました。ただし、commonはこのUSNの修正版一覧には載っていません。公式のパッケージ情報ではamd64・arm64向けの.5の配布を確認できますが、commonだけを見てFPMも対処済みと判断しないようにします。
自分の環境で、版と配布元を確かめる
まず、Ubuntuのリリースと、導入済みパッケージの状態を確認します。
cat /etc/os-release
dpkg-query -W -f='${binary:Package}\t${db:Status-Status}\t${Version}\n' \
php8.5-fpm php8.5-cli php8.5-common
dpkg-queryの表示形式を指定し、パッケージ名、状態、完全な版番号の順に表示しています。対象がinstalledになっていることと、FPMの版番号を確認してください。CLIはコマンドラインで動くPHP、FPMはWebからの要求を処理するPHPなので、片方の確認だけで済ませないようにします。
次にパッケージ一覧を更新し、導入済みの版・更新候補・配布元を見ます。
sudo apt update
apt-cache policy php8.5-fpm php8.5-cli php8.5-common
apt-cacheのマニュアルにあるpolicyで、次を確認します。修正版の番号は、26.04向けUSNと照合します。
-
Installedは導入済みの版。 -
Candidateは、現在の配布元設定で導入候補になる版。 - 版ごとの取得元は、どの配布元のパッケージかを示す。
InstalledとCandidateが同じでも、対象の脆弱性に対応した版とは限りません。USNの対象リリースと版番号まで照合します。
PPAなどの追加配布元や、独自ビルドのPHPには、この判定基準をそのまま当てはめられません。その配布元の修正情報で確認してください。
版の比較をコマンドに任せるなら
Ubuntu 26.04の公式パッケージだと確認できたら、版比較を自動化したい場合は、次の補足を使えます。取得失敗や未導入を、修正済みと誤判定しない形にしています。
補足：導入状態も確認する版比較スクリプト
if state=$(dpkg-query -W -f='${db:Status-Status}' php8.5-fpm) \
&& [ "$state" = installed ] \
&& version=$(dpkg-query -W -f='${Version}' php8.5-fpm); then
if dpkg --compare-versions "$version" ge '8.5.4-0ubuntu1.5'; then
printf '%s\n' 'FPMパッケージは今回の修正版の条件を満たしています'
else
printf '%s\n' 'FPMパッケージの更新が必要です'
fi
else
printf '%s\n' 'php8.5-fpmの導入状態を確認してください' >&2
fi
dpkg --compare-versionsは、Debian系のパッケージ番号の規則で比較します。geは「以上」です。文字列を単純に大小比較するより、番号の読み違いを避けられます。dpkgのマニュアルを参照してください。
この判定で分かるのは、今回のFPMパッケージの版が条件を満たすかどうかです。
再起動や画面の確認は、このあとに続きます。
図：パッケージの条件を満たしたあとも、起動先・再起動時刻・アプリの動作を確認する。
未更新なら、変更予定を読んでから更新する
以下は、FPM・CLIと共通パッケージを更新する例です。インストール済みのPHP拡張などにも更新があれば、それらを含めて対象を確認してください。
更新や再起動で利用中の処理に影響することがあるため、普段の保守時間と復旧手順を確保して進めます。
sudo apt install --only-upgrade php8.5-fpm php8.5-cli php8.5-common
表示される変更予定に、想定していない削除や変更がないかを読んでから確定します。更新候補が出ない場合は、apt updateのエラーや配布元を確認し、別リリース向けのパッケージを直接入れて合わせようとしないでください。
更新後は、先ほどのdpkg-queryで状態と版をもう一度確認します。Ubuntuの公式解説にも、パッケージの更新方法が案内されています。
FPMが、更新後に起動し直したことを確認する
PHP-FPM（ピーエイチピー・エフピーエム）は、Webサーバーから渡されたPHPの処理を担う常駐プロセスです。パッケージを入れ替えたあとも、稼働中のプロセスへの反映が必要です。
まず、サービスの起動先と現在の状態・時刻を控えます。
systemctl show php8.5-fpm \
-p ExecStart -p MainPID \
-p ExecMainStartTimestamp -p ActiveEnterTimestamp
ExecStartの実行ファイルが、今回更新したphp8.5-fpmのものかを確認します。標準の配置では/usr/sbin/php-fpm8.5です。別の場所から起動している場合は、パッケージの更新と、そのサービスが使うPHPの更新を同一視できません。
続けて設定構文を検査します。
sudo php-fpm8.5 -t
エラーがあれば、この段階で解消します。-tは設定を検査して終了するオプションです。Ubuntu 26.04・PHP 8.5-FPMのマニュアルで確認できます。
構文確認が通ったら、現在の日時を表示して控え、FPMを再起動します。あとで、FPMがその日時以降に起動したことを確認します。
date --iso-8601=seconds
sudo systemctl restart php8.5-fpm
再起動が成功したことを確認してから、FPMが稼働していることと、起動した日時が今回の再起動後になっていることを確認します。
systemctl is-active php8.5-fpm
systemctl show php8.5-fpm \
-p MainPID -p ExecMainStartTimestamp -p ActiveEnterTimestamp
systemctl is-active nginx
FPMとNginxがactiveであることに加えて、次を見ます。
-
MainPID：現在のFPMの主プロセスID。0ではないこと。 -
ExecMainStartTimestamp：主プロセスが作成された時刻。今回の再起動時刻になっていること。 -
ActiveEnterTimestamp：サービスがactive状態へ入った時刻。今回の再起動後の時刻になっていること。
それぞれの意味はsystemdの公式資料に記載されています。
activeだけなら、前から動き続けているプロセスでも同じ表示になります。時刻を加えると、更新後に起動し直したかを確認できます。ただし、時刻自体はバイナリの版を示しません。導入済みの版、サービスの起動先、更新後の再起動を組み合わせて確認します。別サービスや個別に起動したFPM、cronなどから動くCLI版PHPは、このサービスの確認には含まれません。
再起動に失敗した場合や、時刻が更新されていない場合は、先へ進まず状態を調べます。
sudo systemctl status php8.5-fpm --no-pager
最後は、いつもの画面からPHPを使う操作を確かめる
FPMが動いていても、アプリが普段どおり使えるかは画面から確かめます。静的なページの表示だけで終わらせず、ログインなど、PHPを通る代表的な操作を選んでください。
業務データを変更する確認には、普段の検証用アカウントや手順を使います。
今回の更新では、FPMの構文確認と再起動、FPM・Nginxの稼働、画面表示とログインまで確認しました。
更新後は、参照したUSN、更新前後の版、FPMの再起動結果と時刻、確認した画面操作を残しておきます。後から見直すときも、どの修正を入れ、どこまで確かめたかを追えます。