PHP 8.5.10 Released
PHP.netによると、PHP開発チームは2026年8月27日、PHP 8.5系のバグ修正版「PHP 8.5.10」を公開しました。今回のリリースで修正されたのは、深くネストされた配列を比較したときに発生するスタックオーバーフローのクラッシュ、そしてpreloading処理中のクラッシュの2点です。LaravelやWordPressのプロジェクトをDocker Composeで動かしている個人開発者の方にとっては、ベースイメージのタグをひとつ書き換えるだけで済む「地味な日常メンテ」にあたるリリースですが、再現性の低いバグは運用フェーズでじわじわ効いてくるため、見逃せないアップデートです。
8.5.10で何が直ったのか
公式のリリースノートによると、今回のバージョンで対処されたのは大きく2つの不具合になります。
1つ目は、配列の比較演算子が極端に深い入れ子構造のデータに遭遇したとき、スタック領域を使い果たしてプロセスが落ちるというものです。LaravelのEloquentでリレーションを何階層も辿った結果を比較したり、WordPressのwp_optionsに格納された複雑な配列をunserializeしたりと、表面的には意識しにくい場面で、表面化していなかったケースに該当する可能性があります。配列の比較そのものは何気ない処理なので、エラーログだけを見ると原因の切り分けに時間がかかってしまうタイプのバグです。
2つ目は、OPcacheのpreloading機能を利用している環境で、特定の条件下でプロセスがクラッシュするという報告への対応です。preloadingは本番環境では有効化、開発環境では無効という方も多いのではないでしょうか。今回のように「特定条件下で落ちる」系のバグは、開発環境では気づかずに本番で初めて再現するという厄介なパターンが定番です。コンテナイメージに焼き込んで運用していると、まさに今回のようなケースで「コンテナごと落ちる」という形で顕在化します。preloadingを設定しているかどうかは、phpinfoやopcache_get_configurationの結果からすぐに確認できますので、心当たりのある方は一度見てみてください。
いずれもバージョン番号のひと桁を上げるだけで済む反面、放置すると「ローカルでは動かないが再現できない」現象に悩まされ続けることになりかねません。
Docker Compose環境でバージョンを揃える具体的な手順
個人開発の現場で多いdocker-compose.ymlでは、php:8.5やphp:8.5-cliのようなタグでベースイメージを指定しているはずです。8.5.10はバグ修正版なので、メジャーバージョンアップのような互換性破壊は基本的にありません。ただし、Dockerfile内でapt-get install php8.5-cliのようにバージョンを明示固定しているケースでは、イメージの再ビルドだけでは反映されないため注意が必要です。Multi-stage buildでベースイメージに固定バージョンを書き込んでいると、知らぬ間に古いリリースにロックされたまま、ということも起こり得ます。
切り替えの基本的な流れは、まずコンテナを停止し、イメージをpullし直して、コンテナを作り直す、というシンプルなものです。ここで私が声を大にして言いたいのは、「開発環境と本番環境で同じPHPマイナーバージョンを使う」原則を守ってほしいということです。たとえばローカルでは8.5.9、VPSの本番だけ8.5.10といったズレが起きると、再現性が崩れてトラブルシューティングの現場で必ず混乱します。「8.5.10に揃える」か、「意図的に8.5.9に固定する」かのどちらかに決めて、READMEにも明記しておくと、後から参加した方や半年後の自分自身を助けることになります。
具体的なコマンドとしては、次の流れになります。
1. docker compose downでコンテナを停止
2. docker compose pullでイメージを更新
3. docker compose up -d --buildで再起動
4. php -vでコンテナ内のバージョンを確認
また、もしLaravel Octaneのような常駐プロセスを採用しているなら、preloading周りの挙動変化はとくに注視したいところです。コンテナ再起動後にワーカープロセスの起動状態とメモリ使用量を一度確認しておくと、後の運用がぐっと楽になりますよ。
同時期に動いていたPHPエコシステム周辺のアップデート
PHP本体だけでなく、PHPエコシステムの上流ツールでも動きがありましたので、あわせてお伝えしておきます。Composerは同8月27日に2.10.3と2.2.30 (LTS)を公開しており、パッケージのbinパスに関するパストラバーサルの脆弱性 CVE-2026-59944 を含むセキュリティ修正が含まれていると報じられています。Laravelプロジェクトでcomposer installをCIやDockerfileの中で回している方は、依存パッケージの更新と合わせてComposer本体もバージョンを見直しておくと安心です。長らく2.x系に留まっていた方も、LTS版の2.2.30が案内されていますので、プロジェクトのPHPサポート期間と相談しながら乗り換える選択肢が見えてきました。
また、Docker周りでは、Synology NAS向けのDocker Engineパッケージが24.0.2-1706にアップデートされ、互換性の修正とパフォーマンス改善が含まれていると報じられています。NASを自宅サーバー代わりにしている方は、DSMのパッケージセンターからの更新という形で適用できますので、こちらもチェックしてみてください。個人開発の検証環境としてNASを使っている場合、コンテナエンジン自体の更新は盲点になりがちなので、こうしたアナウンスはありがたいですね。
PHP本体、Composer、Docker Engine、この3つは「個人開発のコンテナ環境を支える土台」と呼んで差し支えないくらい密接に絡み合っています。今回のリリースは派手さがありませんが、地味に積み重なると運用の再現性をじわじわ蝕む領域です。今週末にでも、ターミナルでphp -vとcomposer --versionを叩いてみるくらいの軽い気持ちで確認してみてくださいね。次のDockerfileを見直すきっかけになれば嬉しいです。