PHPが別のRCE経路を公表｜更新後も確認したいセッション進捗設定

PHP開発チームは2026年10月23日、セッションのアップロード進捗機能に関係する新たなリモートコード実行（RCE）の経路について案内しました。CVE-2026-115560として扱われる問題で、特殊な設定とアプリケーションコードの組み合わせが成立条件です。公式は次の通常バグ修正リリースまで、session.upload_progress.enabled=0を設定するよう勧めています。

10月21日に公開された重大脆弱性2件の修正版へ更新した環境でも、今回の設定条件を別に確認する必要があります。一方、その際の緩和策として進捗機能を無効化し、反映済みなら、その設定を維持すれば今回の問題について追加作業は不要と公式は説明しています。更新済みだから無条件に完了とも、全サイトを再び緊急停止すべきとも判断せず、成立条件と実際の設定を照合する続報です。

本稿は2026年10月24日朝（日本時間）にPHP公式告知、配布ページ、マニュアルとCERT-EUの更新を確認して作成しました。以下では公表された事実と、本サイトが提案する確認手順を分けて説明します。攻撃を再現した実験記事ではありません。

今回増えた新事実と前回の修正を分ける

PHP公式の2026年ニュースアーカイブに掲載された10月23日の「Informational advisory: Session upload progress」は、CVE-2026-115560の詳細なアドバイザリを次のリリースで公表するとしています。実際には起きにくい構成と評価し、臨時の修正版ではなく通常のリリースサイクルで扱う方針です。

確認時点の公式ダウンロードにはPHP 8.5.12、8.4.27、8.3.36、8.2.35が掲載されています。これらはCVE-2026-109618とCVE-2026-109619を直した版であり、新たなCVE-2026-115560の修正版として読み替えてはいけません。今回の詳細な影響版一覧、CVSS、修正版番号、正確な公開時刻は確認した告知に示されていないため、本稿では補いません。

前回の2件と更新対象は、PHPが重大RCEの修正版を公開した際の記事で整理しています。同記事は10月21日の修正を扱ったもので、今回の新しいCVEに対する修正完了を示す記事ではありません。前回の修正を未適用なら、その更新も引き続き必要です。

影響条件は設定値だけでなく実行時の切り替え

PHP公式が示す条件は、次の組み合わせです。三つを別々の一般的な危険設定として列挙するのではなく、同じアプリケーションの処理として成立するかを確認します。

• 設定上のsession.serialize_handlerがphp_binaryまたはphp_serializeである。
• アプリケーションがsession_start()を呼ぶ前に、ini_set()でシリアライズ方式をphpへ切り替える。
• session.upload_progress.enabledが有効なままである。

シリアライズ方式を実行時に切り替えないアプリケーションは、アップロード進捗機能を有効のままにできると公式は説明しています。したがって「PHPでセッションを使う」「アップロードフォームがある」という情報だけで今回の成立条件に一致すると決めつけないでください。逆に、管理画面で初期値を見ただけでは、アプリケーション側の切り替えを見落とします。

本サイトでは、実行環境の初期設定と、セッションを開始するコードの呼び出し順をセットで調べることを提案します。フレームワークの起動処理、共通ライブラリー、古い互換処理、複数アプリで共有する初期化ファイルも対象にします。設定名の検索は入口になりますが、動的に組み立てた設定名やラッパー関数を含む処理まで、文字列検索だけで不存在を証明できるわけではありません。

まず判断を三つに分ける

確認した状態	今回の対応	残す記録
進捗機能を無効化し全ワーカーへ反映済み	設定を維持する	適用先と確認日時
進捗機能が有効で実行時切り替えの条件に一致	無効化して全ワーカーを再起動する	設定元と再起動結果
コードや設定の条件を確定できない	無効化を検討し提供元へ条件と反映方法を確認する	未確認点と担当者

この表は本サイトの運用提案です。公式に条件が限定されているからこそ、未確認を「対象外」と同じ欄へ入れないことが重要です。確認できた条件と保留事項を分ければ、不要な一斉変更を減らしながら、確認漏れも追跡できます。

緩和策は入力解析より前に効かせる

設定例は次のとおりです。php.iniなど、Webリクエストの解析前に適用される管理対象の設定へ置きます。

; php.iniでの設定例
session.upload_progress.enabled = 0

PHP-FPMのプール設定を管理できる場合は、対象プールへ次のように設定する方法があります。配置先や読み込み順は配布元ごとに違うため、実際の構成と照合してください。

; FPMプール設定内の例
php_admin_value[session.upload_progress.enabled] = 0

PHP公式のFPM設定マニュアルは、php_admin_valueやphp_admin_flagで設定した値をini_set()から上書きできないことを説明しています。設定ファイルへ追記しただけで終えず、対象サービスの設定検査を行い、全ワーカーを再起動して反映を確認します。

アップロード進捗の情報は、アプリケーションのスクリプト実行前にセッションへ書かれます。この順序はPHP公式のSession Upload Progressマニュアルにも明記されています。アプリケーション冒頭でini_set()を呼ぶ方法に頼らず、PHP公式の緩和策に従い、解析前に効くphp.ini、FPMプール、サーバー設定を使います。FPMの.user.iniへ記載する方法にも頼らないでください。

一台のCLIではWeb全体を確認できない

SSHから実行するphpは、Webを処理するPHP-FPMやApacheモジュールと別の設定ファイルを読むことがあります。php --iniで場所を調べても、それはCLI側の結果です。Web側のSAPI、プール、仮想ホスト、コンテナ、ノードに対応する設定を管理情報から確定します。

既存の認証済み運用ツールや管理経路で値を取得する場合は、今回に必要な項目へ絞ります。次は出力内容を示す例であり、そのまま公開URLへ置くための診断ページではありません。公開ディレクトリへphpinfo()を設置して環境情報を広く見せる方法は避けます。

<?php
// 認証済みの内部管理経路でのみ実行する例
echo json_encode([
    'sapi' => PHP_SAPI,
    'upload_progress' => ini_get('session.upload_progress.enabled'),
    'serialize_handler' => ini_get('session.serialize_handler'),
], JSON_UNESCAPED_UNICODE | JSON_PRETTY_PRINT);

この結果は、そのコードを実行した経路の、その時点の値です。serialize_handlerがphpと表示されても、それ以前にphp_serializeから切り替えられた結果なら、初期設定がphpだった証明にはなりません。初期設定は設定ファイルで、切り替えはコードの呼び出し順で調べ、二つの確認を突き合わせます。

全ワーカーと再作成元に反映する

CERT-EUの10月23日更新も、今回のCVEに対して進捗機能を無効化し、すべてのワーカーを再起動するよう案内しています。複数台構成では一台だけを確認しても完了になりません。ロードバランサーの背後の全系統、別プール、別リージョン、管理画面専用の実行環境まで分母を持たせます。

コンテナの中だけで設定を変えると、再作成や自動増設で元へ戻る場合があります。イメージやマウント設定、構成管理など再現元へ変更を反映し、再デプロイした実体で確認します。ロールバック用の構成も、今回の無効化設定を失わないか点検します。

再起動方法のコマンドは、サービス名や構成によって違うため、本稿では一律のものを指定しません。更新時刻、プロセスの入れ替わり、正常性試験を対象ごとに記録します。古い長時間リクエストが残る構成では、終了を待つ時間と公開継続の判断も運用担当者が決めてください。

進捗機能を止めた後に試すこと

session.upload_progressは、PHPがアップロード状況をセッションへ記録する仕組みです。無効化はfile_uploads自体を無効にする設定とは異なります。一方、この仕組みを参照する画面では、進捗率の更新や中断機能が変わる可能性があります。ファイルを送れるかだけでなく、利用者が完了を判断できるかまで試します。

• 小さいファイルと通常利用する大きさのファイルを送信し、保存結果まで確認する。
• 進捗表示、キャンセル、複数ファイル、失敗時の再操作を確認する。
• ログイン状態や既存セッションを使う主要操作に異常がないか確認する。
• 全系統の設定値とプロセス切り替えを記録し、再作成後も無効化が維持されるか確認する。

影響確認のためにシリアライズ方式を本番で行き来させたり、攻撃リクエストを送ったりする必要はありません。既存セッションとの互換性に関わるため、設定値を一律にphpへ変更することも、本稿の緩和策としては提案しません。今回の公式案内が勧める進捗機能の無効化を軸に、業務影響を検証します。

次のリリースまで何を保留するか

確認した公式資料では、今回のCVEの実環境での悪用状況やCVSS値は示されていません。前回の2件の深刻度や攻撃観測を今回へ引き継いだり、AIによる悪用と呼んだりはできません。公開予定日も補わず、次回の正式アドバイザリで影響版、修正版、対処方法を確認します。

緩和策を外すときも、通常リリースが出たという理由だけで戻さず、当該CVEへの修正を配布元の情報で確認し、稼働実体への適用後に判断します。進捗機能が不要なら、そのまま無効化を維持する選択肢もあります。担当者と再確認条件を残し、設定がいつの間にか元へ戻らないようにしましょう。

今回の要点は、前回の修正版の適用記録に、新しいCVEへの設定確認を追加することです。すでに無効化済みの環境は維持を確認し、条件に合う環境は解析前の設定と全ワーカーへの反映を進めます。未確認の環境は提供元へ確認し、既知の更新作業と新しい緩和策をそれぞれ完了できる状態にします。