CVE-2026-109619：古いグローバル状態による PHP のリモートコード実行

何が起きるのか（ベンダーが公表した範囲で）

PHP Foundation によると、悪いタイミングの致命的エラーにより、内部状態が前のリクエストのメモリを指したまま残ることがあります。同じワーカーの後続リクエストがその解放済みメモリを使う可能性があります。Foundation は解放後使用とワーカーのクラッシュが確認され、報告者が mod_php の Apache 上で動く実在のアプリケーションに対してリモートコード実行を実証したとしています。英国 NCSC の説明も php.net と同じです。

トロント大学の勧告は、デフォルトで有効なセッションのアップロード進捗機能を確認済みの経路の一つとして挙げています。PHP の暫定ガイダンスでは、session.upload_progress.enabled=0 にすると確認済みのセッション経路は塞げますが、他の変種は塞げません。この設定の無効化は緩和策であり、修正ではありません。リクエストが致命的エラーの瞬間に到達する方法は説明しません。

mod_php と PHP-FPM

Expel は PHP の説明として、アプリケーション自身のコードを致命的エラーに追い込めるケースで、PHP がこの CVE を PHP-FPM に対して実証したとしています。FPM の露出はアプリケーションと構成に依存しますが、PHP は FPM のインストールもリスクありとしています。PHP プロジェクトが最もリスクが高いとするのは引き続き mod_php です。カナダ サイバーセンターも同じ評価で、mod_php では実証済みのエクスプロイトにより、アプリケーションコードの実行前に認証なしのリクエストで脆弱性を引き起こせるとしています。

修正

個別のパッチはありません。10 月 21 日のリリースをインストールし、すべてのワーカーを再起動してください。PHP 8.5 では、確認済みの致命的エラーのバックトレース経路だけを塞ぐ暫定策として fatal_error_backtraces=0 も挙げられています。php.net の勧告によれば、error_reporting、display_errors、@ 演算子で診断を隠しても効果はありません。Google Cloud は両 CVE の脆弱なバージョンを 5.4〜8.5.11 としています。PHP が実際に修正版を出したブランチとの関係はバージョンのページを参照してください。