PHPの緊急アップデートを支えた、平常時の準備

2026年10月、PHPの重大な脆弱性への対応が必要になりました。開発・保守を支援しているサービスでも、10月22日にPHP 8.5.8から8.5.12へ更新しました。僕が行ったDockerでの更新手順と、それまでに進めていた準備をまとめます。

重大な脆弱性や情報漏洩の公表が重なったこの時期は、海外の一部の報道で「Black October（ブラックオクトーバー）」とも呼ばれていました。

PHPをどう更新したか

1. 動いているバージョンと、更新先を確認する

まず、本番のWebアプリとバッチで使っているPHPを確認します。今回の環境は8.5系だったため、同じ系統の修正版へ更新しました。PHP公式が10月21日に公開した修正版は次のとおりです。

OSのパッケージやレンタルサーバーを使っている場合は、提供元の修正状況と更新方法を確認します。古いバージョンに修正を取り込んで提供する場合もあるため、上の番号だけでは判断できません。

2. PHPイメージの指定を変えて、再ビルドする

今回は、PHPとWebサーバーをまとめたDockerイメージを使っていました。以下は、その構成の元になっている公式PHPイメージを、Dockerfileで直接指定する場合の例です。PHPのバージョンを8.5.8から8.5.12へ変更します。

FROM php:8.5.12-apache-bookworm

名前にあるapacheはWebサーバー、bookwormはDebianというOSのバージョン名です。PHP以外の部分は元の構成に合わせ、既存の拡張機能やアプリの構築手順も保ちます。@sha256:…で固定している場合は、ダイジェストも修正版のものに更新します。

今回の構成では共通のベースイメージを使っていたため、先にそのPHPを更新して再ビルドし、アプリ側が参照するダイジェストも差し替えました。composer.jsonのPHP指定を変えるだけでは、PHP本体は更新されません。

既存のDockerfileがあるディレクトリで再ビルドし、完成したイメージのPHPバージョンと拡張機能を確認します。myappはこの例で付けるイメージ名です。

docker build --pull -t myapp:php-8.5.12 .
docker run --rm --entrypoint php myapp:php-8.5.12 -v
docker run --rm --entrypoint php myapp:php-8.5.12 -m

ここまではローカルでの構築と確認です。既存コンテナを再起動するだけでは、新しいイメージへの切り替えにはなりません。

3. 動作を確かめて、本番へ反映する

今回は予防的にサービスを一時停止し、本番のデータや認証情報を持ち込まない環境で修正版を検証しました。失敗したテストは更新前のPHPでも比較し、既存テストの不整合を修正。更新後に単体・機能テスト328件が通ることを確認しました。

ステージングでログインや管理画面の表示・操作などを運営側と確認してから本番へ反映しました。本番のWebアプリとバッチの両方で、PHPのバージョンも確認しました。

それまでに用意していたこと

7月から基盤の更新を進め、8月にはPHP 8.0から8.5への移行に加え、フレームワークや画面側のライブラリも更新・検証していました。そのため、緊急対応ではPHPの修正更新と検証に作業を絞りました。

ログイン、管理画面、権限に応じたデータの表示、バッチ処理など、更新後も守るべき動作を確認項目やテストにまとめていました。共通のベースイメージを用意してバージョンを固定し、更新前後の変更範囲を追えるようにしました。

保守は、次の改善への投資

修正版が公開されても、それを適用して動作を確かめられる準備がなければ、すぐには更新できません。緊急時に基盤の移行やテストの整備から始めるとなると、対応の負担は大きくなります。その負担が、サービスを続けるかどうかの判断につながることもあります。

AIを使って実装を進めても、動作を確かめ、本番へ反映できる状態が整っていなければ、利用者へ届けるところで止まってしまいます。だから、日頃から基盤を更新し、変更後の動作を確かめる手順も整えておきます。

AI時代の保守は、サービスを続け、次の改善へ進むための投資だと思っています。今回も、事前に整えた基盤とテストを使い、影響を確認しながら更新と本番反映を進めました。

PHPのアップデートや、既存システムの保守・改善でお困りの方は、ウルフアプリケーションへご相談ください。