PHPのCVE-2026-115560は、serialize_handlerを実行中に切り替えるアプリだけが対象

TL;DR

---

php2shellは、10月21日にPHPが修正した未認証RCE2件（CVE-2026-109618、CVE-2026-109619）の通称だ。
その修正版から2日後、PHP公式が新しいCVE番号の付いた告知を出した（PHP公式のお知らせ）。
告知のタイトルは「Informational advisory: Session upload progress」で、日本時間23日19時12分の公開。
CVE-2026-115560はphp2shellの2件とは別の問題で、21日の修正版を当てたサーバーにも残っている（The Hacker News）。

公式は、緊急リリースではなく通常のリリースの周期で直すとしている。
条件がそろうと外部からコードを実行される（RCE）おそれがあるが、条件の組み合わせが珍しく、実際には起こりにくいと書いている。
それまでの対策として、php2shellの修正版が出る前に紹介した session.upload_progress.enabled=0 を勧めている。

対象になる3つの条件

公式の告知では、設定とアプリのコードが次の3つを全部満たす場合にだけ起こる。

条件	内容
設定	php.iniなどの設定で、session.serialize_handler を php_binary か php_serialize にしている
アプリのコード	実行中に ini_set()（スクリプトの実行中に設定を変える関数）で session.serialize_handler を php に切り替え、そのあとで session_start() を呼ぶ
アップロード進捗	session.upload_progress.enabled が有効のまま

session.serialize_handler は、$_SESSION の中身をファイルなどに保存するときの書式を決める設定だ。
PHPマニュアルによると既定値は php で、php_binary はPHP内部の別の書式、php_serialize は serialize() と unserialize() をそのまま使う書式になっている。
設定は既定のままで、アプリ側でも切り替えていないなら、2つ目までの条件に当たらない。

session.upload_progress.enabled はファイルのアップロード中に進み具合をセッションへ書き込む機能で、既定で有効になっている。
公式は、実行中に session.serialize_handler を切り替えないアプリなら、この機能を有効のままにしてよいとしている。
アップロード進捗の記録が書式の切り替えとどう関わって問題になるのかは、告知に書かれていない。

21日に設定を切ったサーバーは何もしなくていい

session.upload_progress.enabled=0 は、21日に公開されたCVE-2026-109619のアドバイザリ（GHSA-6wmf-4rv5-p3rp）でも緩和策に挙がっていた設定だ。
公式は、そのときに入れたならそのままにしておけばよく、ほかの作業はいらないと書いている。

まだ入れていないなら、次の定例リリースが出るまで入れておく。
21日のアドバイザリは、CVE-2026-109619向けにこの設定を入れる場合、php.ini、FPMプール（PHP-FPMのワーカーをまとめる設定の単位）、サーバー設定のどれかに書き、すべてのワーカー（リクエストを処理する常駐プロセス）を再起動するよう求めていた。
ini_set() とFPMの .user.ini には頼らないようにとも書いてある。
23日の告知には設定する場所の注意はない。
21日と同じ場所に書いておけば、CVE-2026-109619の緩和策の条件も満たせる。
レンタルサーバーやphp.iniでの切り方は、修正版が出る前に書いた記事の手順にまとめている。

この設定で止まるのは、アップロード中の進捗をセッションへ記録する処理だ。
アップロードの進捗バーをこの機能で出しているサイトは、進捗が表示されなくなる。
ロリポップは22日の対応で全バージョンの session.upload_progress を無効にしていて（ロリポップのお知らせ）、利用者が自分で設定を変えなくてもこの状態になっている。

自分のアプリが条件に当たるか

設定とコードの両方を調べる。
設定ファイルとアプリのコードを session.serialize_handler で検索すれば、どちらに書かれているかが分かる。

# 設定ファイル（パスは環境に合わせる）
grep -rn "serialize_handler" /etc/php* /etc/httpd /etc/apache2 2>/dev/null

# アプリのコード、.htaccess、.user.ini
grep -rn "serialize_handler" /var/www --include="*.php" --include=".htaccess" --include=".user.ini"

設定側で php_binary か php_serialize を指定していて、コード側に ini_set('session.serialize_handler', 'php') があれば、条件の2つ目までに当たる。
コード側の切り替えは、アプリ本体だけでなく、Composer（PHPのパッケージ管理ツール）で入れたライブラリ（vendor/ の下）にも含まれる場合がある。
ディレクトリごとの設定ファイルである .htaccess（Apache用）の php_value や .user.ini（PHP用）で切り替えている場合が条件に入るかは、告知では触れていない。
公式が挙げているのは ini_set() での切り替えだけだ。

まだ公表されていないこと

23日の告知は情報提供のためのもので、詳しいアドバイザリはCVE-2026-115560の修正と一緒に次のリリースで出すとしている。
The Hacker Newsによると、23日時点で次の項目が出ていない。

項目	23日時点
影響を受けるバージョン	未公表
修正が入るリリース	「次の定例のバグ修正リリース」とだけ書かれている
深刻度のスコア（CVSS。0〜10で表す指標）	未公表
CVE-2026-109619と原因が同じか	未公表
攻撃の観測	報告なし。21日以降の攻撃は、21日に直った2件を狙ったもの

前回取り上げた「修正後も残る」主張との関係

前回の記事では、修正後の8.5.12にも未認証（ログインなし）のRCEが残ると主張する個人のページ（php2shell-zeros）を取り上げた。
そのうち「Zero 1」のA項目は、セッションの書き込みと読み込みで session.serialize_handler が食い違うと、攻撃者が選んだオブジェクトを作らせられるという主張だった。
作られたオブジェクトのクラスに __wakeup() や __destruct() があると、復元時や後片付けの時点でそれが自動で動くので、攻撃者が用意した処理の実行につながるとしている。
食い違いの原因として、ディレクトリごとの php_value、仮想ホストの設定、.htaccess、アプリの ini_set() を挙げている。

公式の3つの条件も、設定とアプリの ini_set() で session.serialize_handler が食い違う形になっていて、主張と似ている。
ただ、公式の告知は報告者や見つかった経緯を書いていないので、同じ問題を指しているのかは分からない。
前回の記事の時点で、Zero 1はPHPへ正式に届け出ていない主張だった。
食い違いの原因の範囲も違い、主張は .htaccess などでの切り替えも含めているのに対し、公式が挙げているのはphp.iniなどの設定と ini_set() の組み合わせだけになっている。