PHP 8.1以下はどう対応する？バックポート確認と8.3以降への移行手順

PHP 8.1以下を使っている場合、今回のCVE-2026-109618とCVE-2026-109619に対して「同じ系列の最新版へ上げればよい」とは限りません。PHP 8.1は2025年12月31日にEOLを迎え、PHPプロジェクトが公開した修正版はPHP 8.2.35、8.3.36、8.4.27、8.5.12です。一方で、UbuntuなどのOSベンダーが旧系列へ修正をバックポートしている例もあります。

したがって、PHP 8.1以下を一律に「未修正」と判定するのも、php -vに表示される上流版だけを見て「古いから危険」と判定するのも正確ではありません。最初にPHPの入手元を特定し、その配布元が示す修正済みパッケージと照合します。ただし、バックポートは今回の緊急対応であり、EOLになったPHPを使い続ける長期策ではありません。

結論は「今すぐ保護」と「8.3以降への移行」を分ける

現在の状態	直ちに行うこと	次の判断
PHP公式ビルドや自作ビルドの8.1以下	公開面を縮小し、対応版へ更新	PHP 8.3または8.4への移行を優先
OSベンダーの旧PHP	ベンダーのCVEページと修正済みパッケージを確認	修正版を適用して再起動後、移行期限を設定
商用LTS・延長保守のPHP	契約範囲、対象パッケージ、修正番号を確認	保守期限内に対応版へ移行
配布元や保守状況が不明	未修正として扱い、外部到達性を下げる	追跡可能な公式パッケージへ置き換える

2026年10月時点でPHP 8.2はサポート中ですが、セキュリティサポートは2026年12月31日までです。互換性上どうしても8.2を中継地点にする場合を除き、新しい移行先としてはPHP 8.3または8.4を軸にした方が、短期間で再度メジャー更新する負担を減らせます。PHP 8.5も選択肢ですが、アプリケーションや拡張の対応状況を先に確認します。

「PHP 8.1.2だから未修正」とは限らない

Linuxディストリビューションは、上流の新しい版へ番号を合わせず、必要な修正だけを既存パッケージへ取り込むことがあります。Ubuntuは今回、Ubuntu 22.04 LTSのPHP 8.1を8.1.2-1ubuntu2.28で修正済みとしています。PHPの上流版だけを見ると8.1.2ですが、Ubuntuのパッケージ改訂番号まで含めて判定する必要があります。

Ubuntu 20.04以前についても修正版が案内されていますが、PHP 7.4、7.2、7.0、5.5の更新はUbuntu ProやLegacy Supportの対象を含みます。リポジトリを追加していない環境や契約対象外の環境では、同じOS名でも修正版を受け取れない可能性があります。「修正が公開された」と「自分のサーバーに配信される」を分けて確認してください。

php -v
php --ini
command -v php

apt-cache policy php8.1-cli php8.1-fpm
dpkg-query -W 'php8.1*'

これらはCLI側の所在とパッケージ版を調べる例です。Webサーバーが使うPHP-FPMやApacheモジュールが別の版である場合もあるため、CLIの表示だけで完了にしません。稼働中のFPMプール、コンテナ、cron、キューワーカー、管理画面用PHPも同じ対象として棚卸しします。外部へphpinfo()を公開して確認する方法は、構成情報を漏らすため避けます。

バックポートを確認できない場合は未修正として扱う

配布元が不明なバイナリ、長期間更新されていないコンテナ、非公式リポジトリ、保守契約の切れた製品では、版番号だけから今回の修正有無を証明できません。CVE番号を明記した配布元のアドバイザリ、修正済みパッケージ番号、取得元リポジトリの三点がそろわなければ、暫定的に未修正として扱うのが安全です。

• PHPを直接インターネットへ公開する経路を減らす
• 不要なアップロード、管理画面、APIエンドポイントを一時停止する
• WAFやロードバランサーを経由しない直通経路を閉じる
• サービス停止が可能なら、移行完了まで公開を止める
• 脆弱な版が稼働していた期間のログと認証情報の利用を調査する

PHP公式は今回の2件について、完全な緩和策はなく更新が唯一の安全な選択だと説明しています。WAF、要求サイズ制限、ワーカー再起動は被害可能性を下げる補完策であり、修正の代わりにはなりません。例外運用には終了日時と責任者を設定します。

移行は本番切替より前に互換性を洗い出す

旧PHPからの移行で止まりやすいのは、PHP本体よりもComposer依存関係、フレームワーク、拡張モジュール、独自コードです。現在の本番を直接更新するのではなく、同じ設定とデータ条件を再現した検証環境へPHP 8.3または8.4を用意し、差分を先に出します。

composer check-platform-reqs
composer prohibits php 8.3
composer outdated --direct

• ComposerのPHP制約とロックファイルを確認する
• 必要な拡張と、各拡張の対応版をそろえる
• 非推奨警告、型エラー、動的プロパティ、文字列処理の差をテストする
• ログイン、決済、メール、アップロード、バッチを重点的に試す
• ステージングで負荷とメモリー上限を確認し、切り戻し手順を作る

composer prohibitsは指定版への移行を阻む依存関係を探す材料です。ただし、Composer管理外の拡張や独自コードまでは保証しません。自動テストが少ないシステムでは、アクセスログから主要経路を抽出し、業務上重要な操作を手順化して回帰試験へ加えます。

切替後は「実際に要求を処理する版」を確認する

パッケージ更新やコンテナのビルド成功は完了条件ではありません。PHP-FPMとWebサーバーを再起動し、新しいプロセスが起動したことを確認します。コンテナ環境では、新しいイメージのダイジェストへPodやリビジョンが切り替わり、古い実体へトラフィックが届かないことまで確認します。

• Web、CLI、cron、キューワーカーのPHP版を個別に確認する
• FPM、Apache、コンテナを再起動し、古いプロセスを残さない
• ロードバランサー配下の全ノードと待機系を確認する
• 更新前から更新完了までのログを保全する
• 不審な子プロセス、外向き通信、ワーカー異常、認証情報の利用を調べる

PHP 8.1以下で今回の修正を受け取れた環境でも、それは移行猶予が生まれたという意味です。バックポートの有無を今日確認し、修正版を適用しながら、PHP 8.3以降への移行期限を決める。この二段構えが、緊急対応と将来の保守性を両立させます。

関連記事

• PHPが重大RCEの修正版を公開！8.5.12など4系統へ緊急更新（脆弱性の影響範囲とPHP公式の修正版を確認できます）
• Google CloudがPHP緊急対応を更新｜自動更新と再デプロイの境界を確認する（App Engine、Cloud Run、GKEの対応を実行方式別に整理しています）
• UbuntuがPHP重大脆弱性を修正｜パッケージ番号と再起動で確認する適用状況（Ubuntuの修正済みパッケージ番号を確認できます）