PHP脆弱性の修正手順｜Ubuntu・Debian・RHEL・Dockerの更新ガイド

1. 自分で作業する環境かを判断する

作業権限があるサーバーだけを対象にしてください。複数台構成では、Web、バッチ、キュー、予備系の担当を一覧にします。ロードバランサー配下では、対象ノードを外す手順と戻す条件も決めます。

今回の2件の脆弱性を技術的に理解する →

2. OS・PHP・動いているサービスを記録する

次は状態を調べるための例です。php -v、php --ini、php -m はCLI側の情報で、Webサイトが使うPHPを証明するものではありません。FPMのプール、Apacheの設定、コンテナー、ホスティング管理画面と対応を確認してください。

cat /etc/os-release
command -v php
php -v
php --ini
php -m
systemctl list-units --type=service --state=running --no-pager

PHPが複数インストールされている場合は、各バイナリーと対象ドメインを対応づけます。Nginx・Apacheの接続先ソケットやFPMの実行設定も、権限のある担当者が確認します。構成ファイルやログには秘密情報があるため、そのまま公開フォームへ貼り付けないでください。

3. 更新前に、バックアップと復旧方法を確認する

• ファイル、アップロード済みデータ、データベース、PHP・Webサーバー設定、現在のパッケージやイメージを記録する。
• バックアップの保管先は公開ディレクトリの外に置き、アクセス権限を制限する。復元テストの結果と担当者を確認する。
• 予約・注文など、作業中に増えるデータの扱いを決める。VMスナップショットだけではデータベースの整合性を保証できない場合がある。
• 保守時間、停止の連絡、コンソールへのアクセス、復旧の判断基準を用意する。パッケージ更新中にサービスが自動再起動される場合も想定する。

PHPの設定ファイルだけのコピーは、サイト全体のバックアップではありません。復旧方法が不明な場合や、決済・予約の整合性を判断できない場合は、ここで作業を止めてください。

4. Ubuntu・Debian：インストール済みパッケージを確認する

dpkg-query -W -f='${binary:Package}\t${Version}\t${db:Status-Status}\n' 'php*' 'libapache2-mod-php*'
apt-mark showhold

php*には複数の系列や拡張モジュールが含まれます。未導入パッケージについて「見つからない」と表示されることもあります。保留中のパッケージを、理由を調べずに解除しないでください。PPAや第三者配布元のパッケージには、その提供元の修正確認が必要です。

以下はUbuntu 24.04の標準PHP 8.3・FPM・CLIを使う場合の例です。USN-8948-1では、8.3.6-0ubuntu0.24.04.13が修正版として案内されています。番号の先頭が8.3.6でも、配布元の修正が含まれる例です。最新版の案内とリポジトリの候補を照合してください。

5. APT：候補と変更予定を見てから更新する

次の例はパッケージ一覧を更新し、インストールをシミュレーションします。まだPHPパッケージを入れ替える操作ではありません。対象名を実環境に合わせ、利用中の拡張モジュールや別系列も別途確認してください。

sudo apt-get update &&
apt-cache policy php8.3-common php8.3-fpm php8.3-cli &&
sudo apt-get -s install --only-upgrade php8.3-common php8.3-fpm php8.3-cli

候補に修正版がない、依存関係の変更が不明、削除や想定外の系列変更が提案された場合は、先へ進まず調査します。新しい配布元の追加、強制更新、パッケージ削除を場当たり的に行わないでください。

sudo apt-get install --only-upgrade php8.3-common php8.3-fpm php8.3-cli

この3パッケージだけですべての環境を網羅するものではありません。CGI、Apacheモジュール、ほかのPHP系列などが使われていれば、その実体も対象です。更新中に設定ファイルの確認が出た場合は、独自設定を確認せず置き換えないでください。

apt-cache policy php8.4-common php8.4-fpm php8.4-cli &&
sudo apt-get -s install --only-upgrade php8.4-common php8.4-fpm php8.4-cli

Debianの例では、先にsudo apt-get updateを正常に完了させ、修正の入ったパッケージを確認します。Debian 12などで異なる系列を使う場合は、その版のセキュリティ案内を参照してください。Ubuntu用のパッケージをDebianへ混在させてはいけません。

6. PHP-FPM：設定確認後、対象ワーカーを入れ替える

これはPHP 8.3のバージョン付きFPMコマンドを使う例です。DebianのPHP 8.4なら、実際のバイナリーとサービス名を確認して読み替えます。設定検証が失敗したら、再起動へ進まないでください。

sudo php-fpm8.3 -t

更新後も古いPHPを読み込んだプロセスが残る可能性があります。対象ノードをドレインし、保守時間内に正しいFPMサービスを再起動します。単にreloadと表示されたことだけで、古いワーカーがすべて入れ替わったとは判断しません。

sudo systemctl restart php8.3-fpm &&
systemctl is-active php8.3-fpm &&
sudo journalctl -u php8.3-fpm --since '10 minutes ago' --no-pager

NginxがPHP-FPMへ接続している場合、PHPの更新だけを理由にNginxも再起動する必要があるとは限りません。接続先や構成に変更がある場合は、その変更の検証を別途行います。ログの表示には機密情報が含まれる場合があります。

7. Apache mod_php：Apache側のPHPを更新する

Apacheを使っていても、mod_phpとは限りません。apache2ctl -Mなどで方式を確認します。proxy_fcgi経由なら、実際のFPMを更新・再起動する経路です。以下はUbuntu系のmod_php 8.3が既に導入されている場合の例です。

sudo apache2ctl -M
sudo apache2ctl configtest
apt-cache policy libapache2-mod-php8.3
sudo apt-get -s install --only-upgrade libapache2-mod-php8.3 php8.3-common

sudo apt-get install --only-upgrade libapache2-mod-php8.3 php8.3-common &&
sudo apache2ctl configtest

ここで設定検証に成功したことを確認してから、次の再起動を別途実行します。複数サイトで共有するApacheでは、そのすべてに影響する可能性があります。

sudo systemctl restart apache2 &&
systemctl is-active apache2

8. RHEL系：提供元と更新対象を確認する

RHEL・Rocky Linux・AlmaLinuxなどでは、それぞれの配布元の案内と有効なリポジトリを確認します。同じRPM系列でも修正の提供時期や保守条件が同じとは限りません。モジュールストリームや第三者配布元を使っている場合は、その構成も確認してください。

rpm -qa 'php*'
dnf repolist --enabled
dnf updateinfo list --security
dnf list --upgrades 'php*'
sudo dnf upgrade --assumeno 'php*'

「更新なし」や空の一覧は、修正済みの証明ではありません。メタデータ、契約・保守対象、配布元、パッケージ名を確認します。remi-php83-phpなど別の名前・サービスを使う環境では、以下のphp*の例で対象を網羅できません。

sudo dnf upgrade 'php*' &&
sudo php-fpm -t

設定検証に成功し、標準のphp-fpmサービスが対象であることを確認したあとで再起動します。Apache側にPHPを組み込んでいる別構成では、そのWebサーバーも提供元の手順に従って扱います。

sudo systemctl restart php-fpm &&
systemctl is-active php-fpm &&
sudo journalctl -u php-fpm --since '10 minutes ago' --no-pager

9. Docker：対象サービスとイメージを特定する

以下はComposeのPHPサービス名をphpとした例です。正しいプロジェクトのディレクトリ、Composeファイル、環境を確認してください。サービス名がappやwordpressなら、その実体に合わせます。ホストのPHP更新では、既存コンテナー内のPHPは更新されません。

docker compose config --services
docker compose config --images
docker compose ps
docker compose images php
docker compose exec -T php php -v

compose.yamlのimage、またはDockerfileのFROMで、修正を含むことを確認したタグ・ダイジェストへ変更します。古いダイジェストを固定したままpullしても修正は入りません。OSのパッケージ版PHPを含む独自イメージでは、ビルド手順も確認します。

10. Docker：取得または再ビルド後に再作成する

既製の修正版イメージを使う場合は、先にimage参照を見直してから取得します。pullだけでは、稼働中のコンテナーは入れ替わりません。

docker compose pull php

自分のDockerfileから作る場合は、修正済みのベースを指定したうえで、次のようにビルドし直します。これは前のpullとは別の経路です。--pullでも、固定された古いダイジェスト自体は新しいものに変わりません。

docker compose build --pull --no-cache php

ビルドしたイメージ内のPHP・拡張・アプリを検証し、承認されたデプロイ経路で再作成します。次のCompose例は単一サービスの保守例で、無停止のローリング更新を保証するものではありません。依存サービスや複数レプリカは運用設計に従ってください。

docker compose up -d --no-deps --force-recreate php &&
docker compose ps php &&
docker compose exec -T php php -v &&
docker compose logs --tail=100 php

docker compose restartだけでは、変更後のイメージ参照や構成が反映されません。データを失うおそれのあるdown -v、ボリューム削除、無関係なイメージの一括削除は、この作業の手順に含みません。

11. 更新後：パッケージ・プロセス・Webの3点を確認する

dpkg-query -W -f='${binary:Package}\t${Version}\n' 'php8.3*'
php -v
systemctl show php8.3-fpm -p ActiveState -p MainPID -p ExecMainStartTimestamp

配布元の修正情報に合うパッケージが導入され、対象プロセスが更新後に起動しているかを確認します。そのうえで、実際のWebリクエストがどのPHPを使うかを、認証された管理画面や既存の内部ヘルスチェックで照合してください。phpinfo()を一般公開する必要はありません。

curl --fail --silent --show-error --max-time 15 \
  --output /dev/null --write-out 'HTTP %{http_code}\n' \
  https://example.com/

このcurlは到達性の確認であり、PHPの修正完了の証明ではありません。CDNのキャッシュから200が返る場合もあります。複数台・複数プール・サブドメインを確認し、古い実体が残っていないかを点検します。

12. アプリケーションの動作を確認する

• WordPressやアプリの管理画面へのログイン、記事・検索・画像表示。
• 問い合わせの送信だけでなく受信、予約、承認されたテスト方法での購入・決済。
• ファイルアップロード、画像処理、外部API、定期処理・キューの実行。
• エラー率、FPMの起動失敗・ワーカー再起動、処理時間、CPU・メモリの推移。

更新、プラグイン修正、構成変更を同時に増やしすぎると、原因が切り分けにくくなります。実施した変更と検証結果を記録します。これらの検証は更新の成功を確かめるもので、過去の侵害がなかったと証明するものではありません。

13. エラー・修正版なし・侵害の疑いがある場合

設定検証の失敗、パッケージ更新の失敗、500・502エラー、データの不整合があれば、追加変更を止めて記録します。保守モードや対象ノードの切り離しを検討し、担当者に連絡してください。

古いデータベースへ戻す前に、更新後の注文や予約を確認します。互換性のために未修正のPHPへ戻す判断が必要でも、公開したまま放置せず、提供元や専門家と安全な復旧方法を決めます。

不審なファイルや予期しない管理者、説明できない外部通信などがある場合は、パッチ作業だけで終わらせません。ログ・時刻・対象を保全し、管理者やインシデント対応担当と、隔離、調査、クリーンな環境への復旧、認証情報の扱いを判断します。

14. 作業完了を記録し、不明点は引き継ぐ

• 対象ドメイン、OS・配布元、Web用PHPの実体、修正を裏付ける公式案内。
• 更新前後のパッケージ版またはイメージ・ダイジェスト、再起動したサービスと時刻。
• バックアップ・復旧の情報、検証した機能、未解決事項、次の担当者。

環境の特定から更新後の確認まで、Tsumira Japanへご相談いただけます。公開フォームにはURLと状況だけをお送りください。SSH鍵、rootパスワード、トークン、個人情報を含むログは送らないでください。必要なアクセス方法は、範囲と費用の合意後に個別に調整します。

よくあるご質問

どのコマンドを実行すれば必ず直りますか？

環境に共通する1つのコマンドはありません。Web用PHPの提供元、実行方式、修正版、プロセスの入れ替え、アプリの検証を確認して進めます。

CLIのバージョンだけ上がりました。完了ですか？

完了とは判断できません。Web側のPHPや、稼働中のワーカー・コンテナーが更新されたかを確認します。

経験がありません。コードをコピーして試してもよいですか？

意味や影響、復旧方法が判断できない場合は実行せず、提供元またはTsumira Japanへご相談ください。有料作業は事前に範囲と費用を確認します。

ここにあるコマンドは各OSで実行検証されていますか？

掲載例は公式資料と照合し、構文を確認しています。あらゆる本番構成での実行検証や、個別環境での動作を保証するものではありません。

公式情報・参考資料

• PHP公式：今回の脆弱性と修正版 ↗
• Ubuntu：USN-8948-1 ↗
• Debian：PHP 8.4のセキュリティ更新 ↗
• Debian：apt-getのマニュアル ↗
• Red Hat：セキュリティ更新の確認 ↗
• Docker：Composeでのイメージ取得 ↗
• Docker：Composeでの再ビルド ↗
• Docker：コンテナーの再作成 ↗
• PHP：FPMの構成と注意点 ↗
• WordPress：バックアップ ↗

公式情報や画面構成は変更される場合があります。実際の契約・設定・提供元の最新案内を優先してください。本記事は個別環境の安全性や修正完了を保証するものではありません。