PHP 8.4.27への更新手順：UbuntuでCLIとWebの両方を確かめる

PHPを更新したあと、ターミナルでは新しいバージョンになっていても、Web側が古いPHPのまま動いていることがあります。実行ファイルの置き場所、Webサーバーとの接続先、起動中のプロセスを、それぞれ確認する必要があるためです。

この記事では、PHP 8.4.27への更新を題材に、Ubuntuでの確認・バックアップ・パッケージ更新・再起動・動作確認を順に説明します。接続先やアプリの配置先は説明用の値です。各自の環境に置き換えて進めてください。

想定する構成は Ubuntu 24.04＋Apache＋PHP-FPM 8.4 です。Apacheのmod_phpを使う場合は、再起動するサービスが異なります。その手順も併記します。

この手順の対象

• PHP 8.4がAPTパッケージでインストールされているサーバー。
• SSHでログインでき、sudoで管理者権限を使えること。
• PHP 8.4.11など、同じ8.4系列からのパッチ更新。

検証環境がある場合は、先に同じPHP・拡張構成で更新し、アプリの主要な操作を確認してから本番へ反映します。

PHP 8.4.27は、2026年10月21日に公開されたセキュリティリリースです。認証なしのリモートコード実行につながる可能性がある2件の脆弱性（CVE-2026-109618、CVE-2026-109619）への修正を含みます。PHP公式のセキュリティ告知

また、10月23日には、セッションアップロード進捗機能について追加告知が出ています。session.serialize_handlerを設定でphp_binaryまたはphp_serializeにし、session_start()の前にini_set()でphpへ変更していて、進捗機能も有効、という限定的な組み合わせに関するものです。公式は次の通常のバグ修正版まで session.upload_progress.enabled=0 にすることを提案していますが、実行時に方式を変更しないアプリは有効のまま利用できると説明しています。更新時は、この追加条件も含めて 10月23日付の公式告知を確認してください。

手順と公式情報は2026年10月25日時点で確認しています。掲載するAPTコマンドは、有効な配布元の候補版へ更新する方式です。実行時に8.4.27より新しい修正版が提供されていれば、候補版と変更内容を確認してください。

PHP 8.3から8.4への系列変更や、Docker・Homebrewで管理しているPHPの更新は、導入・切り替え方法が異なります。

先に知っておく用語

CLIとWeb側は、別のPHPや設定ファイルを使っている場合があります。 php -v の確認に加え、Web経由の実行環境も確認するのがポイントです。

1. サーバーへ接続する

手元のPCの端末で実行します。user と server.example.com を、自分のSSHユーザー名と接続先に置き換えてください。

ssh [email protected]

ここから先は、接続先サーバーのBashシェルで実行します。

sudo -v

パスワードを求められたら、sudoで使うパスワードを端末に入力します。SSHの鍵認証とsudoの認証は別の仕組みです。

2. PHPのバージョンとWeb側の構成を確認する

cat /etc/os-release
command -v php
readlink -f "$(command -v php)"
php -v
php --ini
php -m

Web側も確認します。PHP-FPMでは、Apacheが接続するソケットやポートが FPMのlisten設定と対応しているかを調べます。

systemctl is-active apache2 php8.4-fpm

grep -nE 'ServerName|DocumentRoot|SetHandler|proxy:unix' \
  /etc/apache2/sites-enabled/* /etc/apache2/conf-enabled/*

grep -n 'LoadModule' /etc/apache2/mods-enabled/php*.load 2>/dev/null

• PHP-FPM構成：php8.4-fpm が稼働し、Apacheの設定に /run/php/php8.4-fpm.sock などの接続先があります。
• mod_php構成：有効なApacheのモジュール設定に、libphp8.4.so を読み込む指定があります。

使っていないサービスは inactive や「存在しない」と表示されることがあります。複数サイトが同じPHP-FPMを使っている場合、更新と再起動はそれらのサイトにも反映されます。

3. 設定と更新前の状態を保存する

まず、ホームディレクトリにバックアップ先を作成します。backup という変数には、その保存先が入ります。後続の手順も同じSSH接続で進めてください。

backup=$(mktemp -d "$HOME/php-upgrade-backup.XXXXXXXX")
printf 'バックアップ先: %s\n' "$backup"

php -v > "$backup/php-version.before.txt"
php --ini > "$backup/php-ini.before.txt"
php -m > "$backup/php-modules.before.txt"

dpkg-query -W -f='${binary:Package}\t${Version}\n' \
  > "$backup/packages.before.tsv"

sudo tar -C / -czf "$backup/config.before.tar.gz" \
  etc/php etc/apache2 etc/apt/sources.list.d

PHP、Apache、APT配布元の設定と、パッケージ・拡張の情報を保存しています。設定アーカイブから戻せるのは設定です。PHP本体も戻せるようにするには、旧パッケージやサーバーのスナップショットを別途確保します。

続いて、次の3つを自分の環境に合わせて設定します。

app_dir=/var/www/example-app
web_root=/var/www/example-app/public
site_host=app.example.com

以下はHTTPSを利用するサイトの確認例です。HTTPで提供している環境では、URLのスキームを実際の構成に合わせてください。

curl -sS --connect-timeout 5 --max-time 30 \
  --output /dev/null --write-out '更新前のトップ: %{http_code}\n' \
  "https://$site_host/"

トップ、ログイン画面、ヘルスチェックなどの応答を記録します。正常時にリダイレクトするページもあるため、すべて200が正解とは限りません。既存のエラーも、更新前の状態として記録しておきます。

4. 更新候補を確認する

sudo apt-get update -o APT::Update::Error-Mode=any &&
LC_ALL=C apt-cache policy php8.4-cli php8.4-fpm php8.4-common

apt-get update はパッケージ一覧を取得する操作です。この時点ではPHP本体を更新しません。LC_ALL=C は出力言語を固定する指定です。

出力の読み方は次のとおりです。

候補が8.4.27なら、たとえば次のように表示されます。後ろのパッケージ情報は配布元によって異なります。

Candidate: 8.4.27-1+...

配布元の取得に失敗した場合や、候補が必要な修正版に届かない場合は、更新実行前に 配布元で問題が起きた場合 を確認します。

OSベンダーが修正をバックポートしている場合は、PHPの表示バージョンだけでなく、ベンダー告知とパッケージの完全なバージョンも照合します。Ubuntuのセキュリティ更新方針

5. 導入済みのPHPと拡張を更新する

PHP 8.4関連のインストール済みパッケージを集め、php_packages という配列に入れます。

mapfile -t php_packages < <(
  dpkg-query -W -f='${db:Status-Abbrev} ${binary:Package}\n' \
    'php8.4*' 'libapache2-mod-php8.4' 2>/dev/null |
    awk '$1 == "ii" {print $2}'
)

printf '%s\n' "${php_packages[@]}"

php8.4-cli、php8.4-fpm、php8.4-mbstring などが表示されます。DB接続用の拡張など、現在利用しているものが対象に含まれていることを確認します。手動導入した拡張は、別途その更新方法を確認してください。

一覧が空の場合は、ここで止めてPHPの系列と管理方法を確認します。HerdやDocker内のPHPは、このAPT更新とは管理対象が異なります。

更新計画を確認する

(( ${#php_packages[@]} > 0 )) &&
sudo apt-get -s --only-upgrade --no-install-recommends --no-remove \
  install "${php_packages[@]}"

先頭の条件は、対象が1件以上あることを確認します。配列が空ならAPTを実行しません。-s はシミュレーションなので、パッケージは変更されません。

表示された更新対象と依存関係を確認してから、実際の更新を行います。

(( ${#php_packages[@]} > 0 )) &&
sudo apt-get --only-upgrade --no-install-recommends --no-remove \
  install "${php_packages[@]}"

必要な依存関係の追加・更新も計画に表示されます。設定ファイルの変更確認が出たら、新旧の差分を確認して判断します。APT公式マニュアル

6. 設定を検証し、PHPを再起動する

パッケージの更新後は、新しいPHPでサービスを動かすために再起動します。構成に対応する方を実行してください。

Apache＋PHP-FPM

sudo php-fpm8.4 -t &&
sudo apache2ctl configtest &&
sudo systemctl restart php8.4-fpm &&
sudo systemctl reload apache2 &&
systemctl is-active php8.4-fpm apache2

FPMの設定検証が成功し、Apacheの検証で Syntax OK と表示されてから再起動します。最後に両方が active と表示されれば、サービスは稼働しています。

&& は「直前のコマンドが成功した場合だけ次へ進む」という意味です。設定検証が失敗した場合、後続の再起動は実行されません。

Apache＋mod_php

sudo apache2ctl configtest &&
sudo systemctl restart apache2 &&
systemctl is-active apache2

mod_phpではApache内部でPHPが動くため、Apacheを再起動します。キューワーカーなど別のPHP常駐プロセスがある場合は、その管理方法に従って再起動します。

7. 更新後のCLI・Web・アプリを確認する

CLIと拡張

php -v
php --ini
php -m

PHP 8.4.27へ更新した場合、バージョン表示は PHP 8.4.27 になります。設定ファイルと拡張一覧も更新前の保存結果と比較します。

Web経由のバージョン

CLIとWeb側の両方が更新されていることを確認します。既存の管理機能がなければ、バージョンと実行方式だけを返す一時ファイルを利用できます。

以下は、Webルートへファイルを配置できるユーザーで実行する例です。HTTPSのホスト名と証明書検証を維持しながら、サーバー自身のApacheへ接続します。

(
  set -euo pipefail
  probe=$(mktemp "$web_root/php-version-check-XXXXXXXX.php")
  trap 'rm -f -- "$probe"' EXIT

  cat > "$probe" <<'PHP'
<?php
if (! in_array($_SERVER['REMOTE_ADDR'] ?? '', ['127.0.0.1', '::1'], true)) {
    http_response_code(404);
    exit;
}
header('Content-Type: application/json');
echo json_encode(['php_version' => PHP_VERSION, 'sapi' => PHP_SAPI]);
PHP
  chmod 644 "$probe"
  curl -fsS --resolve "$site_host:443:127.0.0.1" \
    --connect-timeout 5 --max-time 30 \
    "https://$site_host/$(basename "$probe")"
  printf '\n'
)

この一時ファイルはlocalhostからの要求だけに応答し、確認処理の終了時に削除されます。Apacheがlocalhostの443番で受け付けている構成を想定しています。

PHP-FPMでの期待する出力例：

{"php_version":"8.4.27","sapi":"fpm-fcgi"}

mod_phpの場合は、sapi が apache2handler になります。

アプリと依存パッケージ

Composerを使うアプリでは、アプリを管理するユーザーで実行します。

cd "$app_dir" &&
composer check-platform-reqs --no-dev --no-interaction

このコマンドは、導入済みライブラリが要求するPHPと拡張を検査します。config.platformの仮想的な値ではなく、コマンドを動かしているPHPの実環境を確認するため、移行先のPHPが選択されている状態で実行します。開発環境では --no-dev を外し、開発用ライブラリの要件も確認します。Composer公式資料

PHP本体の更新と composer update は別の操作です。ライブラリ側の変更が必要になった場合は、その変更を検証環境で確認してから反映します。

主要ページとパッケージの状態も確認します。

curl -sS --connect-timeout 5 --max-time 30 \
  --output /dev/null --write-out '更新後のトップ: %{http_code}\n' \
  "https://$site_host/"

sudo apt-get check
dpkg --audit

トップ、ログイン、DBを使う機能などを更新前と比較し、新しいエラーがログに出ていないか確認します。アプリの自動テストは、本番DBから分離したテスト環境で実行してください。

配布元で問題が起きた場合

候補版が古い場合は、次を調べます。

• apt-get update が成功しているか。
• パッケージがholdされていないか。apt-mark showhold で確認できます。
• 使用中の配布元が、Ubuntu 24.04向けの修正版を提供しているか。
• 配布元が移行案内を出しているか。

Ondřej SurýのLaunchpad PPAを利用している環境では、保守元の PPA説明と packages.sury.orgの導入手順を確認します。2026年10月の更新事例では、旧PPAの取得エラーと8.4.26の候補に対し、同じ保守元の新配布元で8.4.27を取得できました。

配布元を変更するときは、対象OS・コードネーム・署名鍵を確認し、既存設定をバックアップしてから変更します。すでに同じ配布元を登録している場合は、重複登録を避けます。署名検証のエラーは、鍵や配布元設定を確認して解消します。

よくあるつまずき

作業結果の記録例

次のように、自分の環境で確認した値を残します。下表は記入例です。