UbuntuがPHP重大脆弱性を修正｜パッケージ番号と再起動で確認する適用状況

Ubuntuが、今回のPHP重大脆弱性に対する修正パッケージを公開しました。上流PHPの修正版より小さい番号が表示されていても、Ubuntuの修正が入っている場合があります。反対に、更新コマンドが正常終了しただけでは、Webサイトを処理するプロセスまで切り替わったとは判断できません。

Canonicalの10月21日付告知とセキュリティ通知を、2026年10月22日に確認しました。本記事はCVE-2026-109618・CVE-2026-109619へのUbuntu環境での対応を扱います。脆弱性自体の速報とは分け、配布元、パッケージの版、実行中プロセスを照合する手順を掘り下げます。以下の作業順序は本サイトの提案です。

上流PHPの番号とUbuntuの修正番号は違う

PHPプロジェクトの修正版は8.5.12、8.4.27、8.3.36、8.2.35です。一方、Ubuntuは自社が保守するパッケージへ修正を取り込み、Ubuntuのリリース番号を付けて配布します。判定では先頭の8.3.6などだけを切り出さず、末尾まで含むパッケージ番号を確認します。

USN-8948-1が示す標準サポート対象の修正番号は、次のとおりです。これはUbuntu公式パッケージの情報であり、PPA、独自ビルド、別の管理パネルが配るPHPへ、そのまま適用する判定表ではありません。

Ubuntu	PHP系列	通知に記載された修正パッケージ版
22.04 LTS	8.1	8.1.2-1ubuntu2.28
24.04 LTS	8.3	8.3.6-0ubuntu0.24.04.13
26.04 LTS	8.5	8.5.4-0ubuntu1.5
26.10	8.5	8.5.9-0ubuntu2.1

この表から、PHP 8.1だから今回の修正を一切受け取れない、と一律に判断するのも不正確だと分かります。PHPプロジェクトの保守と、OS配布元が提供する保守は別です。ただし、Ubuntuに修正があることは、同じ8.1を使うすべての製品が修正済みという意味ではありません。

まずOSとPHPの取得元をそろえて確認する

対象サーバーで、Ubuntuのリリース、インストール済みPHPパッケージ、更新候補の取得元を確認します。サーバー名や用途も一緒に記録すると、別の検証機を調べた結果を本番へ流用する取り違えを減らせます。

次はUbuntu 24.04のPHP 8.3環境を想定した、読み取り中心の確認例です。別の系列を使う場合は対象名を合わせます。該当パッケージが存在しない表示は、それだけで脆弱性がないという結論にはなりません。

cat /etc/os-release
dpkg-query -W 'php8.3-*' 'libapache2-mod-php8.3'
apt-cache policy php8.3-fpm php8.3-cli libapache2-mod-php8.3

dpkg-queryは導入済みのパッケージ番号を、apt-cache policyは導入版や更新候補、取得元を調べる材料になります。更新候補が見えない場合は、リポジトリー情報が古いのか、対象の配布元が違うのか、パッケージが固定されているのかを切り分けます。候補がないことだけで対応不要にしないでください。

OSがUbuntuでも、コンテナ内のPHPが別の配布元なら、そのPHPは別管理です。ホスト側のapt更新がコンテナイメージを作り直すわけではありません。今回の対象を「このマシン」とひとまとめにせず、Webリクエストを処理する実体まで追います。

CLIとFPMとApacheの確認欄を分ける

通知にはCLI、FPM、CGI、Apacheモジュールなどのパッケージが列挙されています。SSHでphp -vを実行した結果だけでは、Web側のFPMやApacheモジュールの更新状況を証明できません。実際の構成で必要なパッケージを確かめます。

仮想例として、同じサーバーで公開サイトがFPM、定期処理がCLIを使っている場合を考えます。CLIだけを更新しても公開サイトの処理系は未確認のままです。逆にWeb側だけ更新し、バックグラウンドの処理を確認欄から落とすと、環境全体を再現する情報が不足します。

FPMプールを複数持つ場合は、ドメインやサイトとプールの対応を残します。使っていない系列のパッケージを調べた数字を、稼働中の系列の証拠として扱わないためです。ホスティング契約で設定を見られないなら、利用者が推測するより、契約先の対象サーバーと系列を指定して確認します。

更新と再起動を別の作業として扱う

Canonicalの告知はパッケージ更新に加え、それを使うアプリケーションの再起動が必要になると説明しています。Apacheでmod_phpを使う場合にはApacheの再起動を例示しています。FPMを使う環境では、対象のサービスや運用手順を確認して切り替えます。

同告知が示す基本の更新方法はaptによるシステム更新です。ただし、システム全体の更新はPHP以外にも影響するため、保守担当者が変更内容と停止影響を確認して実施してください。本記事は、すべての環境へ一律の再起動コマンドを流す提案ではありません。

作業記録では「パッケージを導入した時刻」と「古いプロセスを切り替えた時刻」を別にします。後者が未確認なら、対応済みへまとめません。長く処理を続けるワーカーや、別のサービス名で動くプロセスがないかも、構成に合わせて確認します。

サービスを再起動すると、処理中のリクエストやジョブへ影響する可能性があります。公開サイトの更新担当だけでなく、注文処理やバッチ運用の担当へも予定を共有します。必要な作業を遅らせるためではなく、切り替え後に二重実行や処理漏れを起こさないための調整です。

自動更新があっても今回の完了を確認する

Canonicalは、unattended-upgradesを有効にしている環境ではセキュリティ更新が自動適用される一方、影響するアプリケーションの再起動やシステム再起動が必要になると説明しています。自動化の設定があることと、今回の更新・反映が完了したことは別です。

本サイトでは、完了の根拠を三つに分けることを勧めます。修正が配布されたこと、必要なパッケージが導入されたこと、稼働する処理が新しい内容へ切り替わったことです。更新ツールの成功だけを記録するより、担当者が変わっても状態を説明できます。

自動更新の履歴に該当の変更が見つからない場合は、最初に対象のリリースと取得元を確認します。管理パネル独自のPHPや手動配置したPHPを、Ubuntuの自動更新が管理していると考えないでください。更新経路が違うものは、確認する提供元も変わります。

Ubuntu 20.04以前はESMの条件も確認する

USN-8948-2は20.04、18.04、16.04、14.04向けの対応を案内しています。通知はUbuntu Proで提供される修正を示し、16.04と14.04ではLegacy Supportアドオンの記載もあります。利用する契約と更新経路を確認してください。

ここで避けたいのは、修正番号を一覧で見つけただけで、自分もそのパッケージを取得済みと判断することです。配布条件に該当するか、必要なリポジトリーを利用できるか、導入したパッケージが対象かを別々に確認します。ホスティング契約に保守が含まれる場合は、契約先がどの更新経路を管理するかを確認します。

古い環境で直ちに修正を受け取れない場合は、保守提供元へ修正の有無と入手方法を確認し、公開制限や更新先への移行を含めて判断します。今回の修正を受け取れた場合も、将来の保守方針を決める作業までは終わりません。

検証では機能と修正の証拠を両方残す

更新後は、利用するWeb処理の実行版とサービス状態を確認したうえで、ログイン、フォーム、アップロード、画像処理などの代表機能を試します。PHPの系列そのものを変えた場合は、パッチ更新とは別に互換性の確認も必要になります。

本番環境では実注文や利用者への通知を不用意に発生させない方法を選びます。エラーがあれば、対象URL、操作、時刻、サーバー、FPMプールなどを残し、配布元の更新によるものか、別の設定問題かを切り分けます。すべての不具合を今回の脆弱性へ結び付ける必要はありません。

複数台構成では、代表の一台だけの結果を全台の完了へ広げないでください。復旧用イメージ、自動増設の元、停止中の予備機も別の対象として残します。緊急対応後の再起動で古い状態が戻らないよう、将来起動するものまで更新経路をそろえます。

受け入れ条件の例は、対象パッケージを通知と照合できること、必要なプロセスを切り替えたこと、主要機能を確認したこと、未確認の台が明示されていることです。修正番号が分からない環境は、無理に緑の欄へ入れず調査中として扱う方が、次の作業を決めやすくなります。

関連記事

• PHP緊急修正で国内ホスティング各社はどう動いたか：自分でOSを管理しない契約での告知の読み方を整理しています。
• PHP重大RCEの修正版と更新対象を確認する：今回の脆弱性と上流の修正版を扱う先行記事です。