2026年10月21日、PHPのセキュリティ修正版が公開されました。今回は、ソースからインストールしていたPHP 8.3.8を8.3.36へ更新した作業を記録します。実サーバーの名称や構成固有の情報は伏せています。

１、ソースビルド環境は自分で更新する

aptなどのパッケージ管理とは異なり、ソースから入れたPHPは原則として新しいソースの取得、configure、make、make installが必要になります。ただし古いソースを改変する必要はなく、新しいディレクトリで従来のオプションを使ってビルドできます。

cd /usr/local/src
wget https://www.php.net/distributions/php-8.3.36.tar.gz
tar xzf php-8.3.36.tar.gz
cd php-8.3.36

./configure \
  --enable-mbstring \
  --with-openssl \
  --with-apxs2=/usr/bin/apxs2 \
  --enable-zts \
  --with-pdo-pgsql \
  --with-curl

make -j"$(nproc)"
Codecode snippet · MEISEID.JP/TECHNOTE

configureのオプションは環境ごとに違います。以前のconfig.logで元のオプションを確認し、必要な拡張を落とさないようにします。ダウンロードしたソースは公式のチェックサムや署名でも検証します。

２、ビルドとインストールは別

makeが成功しても稼働中のPHPは切り替わりません。実際にこの段階でphp -vを実行すると、従来の8.3.8が表示されました。更新する前にCLI、Apacheモジュール、設定をバックアップし、復旧方法を用意してからインストールします。

php -v
php-config --prefix
php --ini
apache2ctl -M | grep -E "php|mpm"

# バックアップとメンテナンス準備の後
cd /usr/local/src/php-8.3.36
make install
apache2ctl configtest
systemctl restart apache2
Codecode snippet · MEISEID.JP/TECHNOTE
３、Basic認証だけで安心しない

検証用のWebサイトにはBasic認証を設定していました。しかし認証の有無だけでPHP処理系の脆弱性を無視できるとは限りません。攻撃成立条件は公式のアドバイザリで確認し、WebからPHPに到達できる構成では速やかな更新を優先します。

４、CLIだけで使うPHPなら

別の環境ではWeb公開ディレクトリからPHPを除外し、Apacheのmod_phpを無効化していました。外部からPHPのWeb処理系へ到達できないことが確認できれば、Web経由の攻撃面を大きく減らせます。ただしPHP-FPM、CGI、外部入力を処理するジョブなど別経路の確認は必要です。

５、Apache経由でのバージョン確認までが更新

CLIのphp -vが新しいだけではApacheのPHP更新を証明できません。制限された検証用URLでPHP_VERSIONとPHP_SAPIを出力し、8.3.36 apache2handlerを確認しました。次回はこの確認時に遭遇した、PHPソースがそのまま表示される問題を紹介します。

参考：PHP公式ニュース（2026年10月21日）。