- PHP 公式は 2026年10月23日、php2shell とは別の脆弱性 CVE-2026-115560 について「Informational advisory: Session upload progress」を出しました。修正は次の定例のバグ修正リリースに入る予定です［php.net］。
- 起きるのは、珍しい設定とアプリのコードの組み合わせのときだけです。設定で
session.serialize_handlerをphp_binaryかphp_serializeにし、アプリがsession_start()の前にini_set()でphpに切り替え、さらに Session Upload Progress が有効な場合です。 - 修正版が出るまでの対策は
session.upload_progress.enabled=0です。10月21日の php2shell（CVE-2026-109619）の緩和策としてすでに入れていれば、追加の作業は要りません。 - 次の定例リリースの日付は、公式からはまだ発表されていません。リリースが出たら、レンタルサーバーやWebサービスがもう一度メンテナンスに入る可能性があります。
何が問題か
10月21日、PHP 本体の緊急の脆弱性「php2shell」（CVE-2026-109618 / CVE-2026-109619）を直した修正版 PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 が公開されました。概要はphp2shell の解説記事にまとめています。
その2日後の10月23日、PHP 公式はもう1件、CVE-2026-115560 の告知を出しました。公式はこれを「起こりにくい、遠隔からのコード実行（RCE）の経路」と書いています。条件がそろうと、外部からサーバー上でプログラムを動かされるおそれがあるということです［php.net］。
起きる条件
公式によると、問題が起きるのは次の3つがすべてそろったときです［php.net］。
- 設定（php.ini など）で、
session.serialize_handlerをphp_binaryかphp_serializeにしている - アプリのコードが、
session_start()を呼ぶ前にini_set()でsession.serialize_handlerをphpに切り替えている - Session Upload Progress（
session.upload_progress.enabled）が有効のまま
session.serialize_handler は、セッションの中身をどんな形式で保存するかを決める設定です。Session Upload Progress は、ファイルのアップロードの進み具合を PHP がセッションに書き込む機能で、初期設定では有効です。くわしくは「php2shell は WAF や php.ini の設定で防げる？」で説明しています。
公式は「設定とアプリのコードの珍しい組み合わせでしか起きない」「実際にはありそうにない構成」としています。実行中に serialize_handler を切り替えないアプリなら、この機能を有効のままにしてよいとも書いています。そのため、緊急のリリースではなく、通常のリリースの流れで直し、次のリリースのときに CVE-2026-115560 の詳しいアドバイザリを出すとしています［php.net］。
JPCERT/CC も10月26日に注意喚起を更新し、この脆弱性と、開発元が通常のリリースサイクルで直す方針であること、修正版が出るまで緩和策の設定を勧めていることを追記しています［JPCERT/CC］。
CVE-2026-115560 の修正は次の定例リリースに入る予定です。公式が「次の定例リリースまで」設定を勧めていることから、21日の修正版（8.5.12 / 8.4.27 / 8.3.36 / 8.2.35）にはこの修正は入っていないと読めます。php2shell の更新が済んだサイトも、下の確認はしておきましょう。
自分のサイトが当てはまるか
当てはまるかは、サーバーの設定とアプリのコードの両方で決まります。順番に見ていきます。
1. session.upload_progress.enabled を見る
これが Off（0）なら、公式の説明では条件の3つめがそろわないので、この問題は起きません。
- VPS・自社サーバー：コマンドで確かめます。
ただし、コマンドで動く PHP（CLI）と、Web で動いている PHP（PHP-FPM や mod_php）は設定ファイルが別のことがあります。Web 側の値は、次の phpinfo で確かめるのが確実です。php -i | grep -E "session.upload_progress.enabled|session.serialize_handler" - phpinfo で見る：
<?php phpinfo();だけを書いたファイルを置いてブラウザで開き、「session」の欄のsession.upload_progress.enabledとsession.serialize_handlerを見ます。phpinfo はサーバーの情報を多く表示するので、確認が済んだらすぐに消してください。 - レンタルサーバー：管理画面の php.ini 設定で値を見られることがあります。見られない場合は phpinfo を使うか、サーバー会社に問い合わせます。
2. session.serialize_handler の設定を見る
phpinfo や php -i の session.serialize_handler の値（Master Value）が php（初期設定）なら、条件の1つめに当てはまりません。php_binary か php_serialize になっている場合は、次のアプリのコードの確認に進みます。
3. アプリが実行中に切り替えていないか見る
アプリのコードの中で ini_set() を使って session.serialize_handler を変えているかを探します。サーバーにログインできる場合は、サイトのフォルダで次のように検索できます。
grep -rn "serialize_handler" /サイトのフォルダ見つかった場合は、その行で何に切り替えているかを見ます。WordPress のプラグインなど、自分たちで書いていないコードの中にあることもあります。判断がつかないときは、アプリやプラグインの開発元に問い合わせてください。
アプリのコードを全部確かめるのは手間がかかります。ファイルのアップロードの進捗バーを PHP のこの機能で作っていないなら、次の節の設定変更をしてしまうほうが確実です。
今やること
設定を変える：session.upload_progress.enabled=0
PHP 公式が勧めている対策は、次の定例リリースまで session.upload_progress.enabled=0 にしておくことです。21日の CVE-2026-109619 のアドバイザリでも緩和策として挙がっていた設定で、そのときに入れたのなら、そのままにしておけば追加の作業は要らないとしています［php.net］。
設定のしかたは、21日のアドバイザリに書かれています［php.net］。
- php.ini、PHP-FPM のプール設定、またはリクエストの解析より前に効くサーバーの設定で入れる
ini_set()や PHP-FPM の.user.iniには頼らない- 設定したら、すべてのワーカーを再起動する（PHP-FPM や Web サーバーの再起動）
再起動したら、phpinfo でもう一度 session.upload_progress.enabled が Off になったかを確かめます。
止まるのは、PHP のこの機能を使ったアップロードの進捗表示です。進捗表示を使っていないサイトなら、影響はほとんどありません。
WAF は代わりにならない
CVE-2026-115560 について、PHP 公式も JPCERT/CC も、WAF での対策は挙げていません。挙がっている対策は上の設定だけです。WAF を入れていても、設定の変更はしておきましょう。WAF の考え方と限界は「php2shell は WAF や php.ini の設定で防げる？」にまとめています。
レンタルサーバーなら、サーバー会社に確かめる
共用のレンタルサーバーでは、PHP-FPM のプール設定やワーカーの再起動を利用者が行えないことがあります。管理画面で php.ini の値を変えられても、それが公式のいう「リクエストの解析より前に効く設定」として反映されるかは、サーバー会社に確かめる必要があります。
サーバー会社がサーバー全体でこの設定を入れているかどうかも、告知かサポートで確かめておくと安心です。php2shell のときの各社の告知は「レンタルサーバー各社の対応状況まとめ」に一覧にしています。
次の定例リリースで起きそうなこと
リリースの日付は未発表
10月28日時点で、php.net のニュースに、次の定例のバグ修正リリースの日付は載っていません。公式が書いているのは「通常のリリースサイクルで扱う」「次のリリースで CVE-2026-115560 の詳しいアドバイザリを出す」ということだけです［php.net］。日付が出たら、この記事でもお知らせします。
もう一度メンテナンスが入る可能性
次のリリースが出たら、PHP をもう一度更新することになります。php2shell のときは、多くのレンタルサーバーやWebサービスが緊急メンテナンスや一時停止をしました。その様子は「停止・メンテナンス中の国内サービス一覧」と「レンタルサーバー各社の対応状況まとめ」にまとめています。
今回は公式が「起こりにくい構成」としているので、前回ほどの規模になるとは限りません。それでも、サーバー会社やサービスが、PHP の更新のために改めてメンテナンスを予定する可能性はあります。また、詳しいアドバイザリが出たあとは、技術的な情報が広まる可能性があります。
今のうちに準備しておくこと
- 21日の修正版を当てたか確かめる：まだなら、こちらが先です。Linux での手順は「VPS・自社サーバーのPHPを修正版に更新する手順」にあります。
- 更新の手順を残しておく：21日に行った更新や再起動、動作確認の手順をメモしておけば、次はそのまま使えます。
- サーバー会社の告知の見方を決めておく：お知らせのページや障害情報のページ、メールの受け取り先を確かめておきます。
- PHP 8.2 を使っているなら移行も考える：PHP 8.2 のセキュリティサポートは 2026年12月31日で終わり、その後は修正が出ません［php.net］。次の定例リリースに 8.2 が含まれるかどうかは、まだ発表されていません。
- リリース後は、修正版に更新してから設定を戻すか決める：
session.upload_progress.enabled=0は、PHP 公式が「次の定例リリースまで」として勧めた設定です。進捗表示を使っていないなら、そのまま無効にしておいても困ることはあまりありません。
よくある質問
CVE-2026-115560 は php2shell と同じものですか？
別の番号の脆弱性です。php2shell は CVE-2026-109618 と CVE-2026-109619 で、10月21日の修正版で直りました。CVE-2026-115560 は10月23日に公表され、修正は次の定例リリースに入る予定です。対策の設定（session.upload_progress.enabled=0）は、CVE-2026-109619 の緩和策と同じです。
21日の修正版に更新しました。まだ何か必要ですか？
この問題の修正は次の定例リリースに入る予定なので、上の「自分のサイトが当てはまるか」を確かめてください。分からない場合は、session.upload_progress.enabled=0 にしておくのが簡単です。
どれくらい危ないですか？
PHP 公式は、起きるのは珍しい組み合わせのときだけで、実際にはありそうにないとしています。そのため緊急のリリースではなく、通常のリリースで直すとしています。ただし、当てはまるサイトでは遠隔からのコード実行につながるおそれがあるので、確認と設定はしておきましょう。
次のリリースはいつですか？
10月28日時点で、日付は発表されていません。php.net のニュースや、ご利用のサーバー会社の告知を確かめてください。
設定を変えるとサイトに影響はありますか？
止まるのは、PHP の Session Upload Progress を使ったアップロードの進捗表示です。この機能を使っていなければ、影響はほとんどありません。
phpinfo や php.ini・PHP-FPM の設定の確認、アプリのコードの確認、修正版への更新と動作確認、サポート中の PHP への切り替えまでお手伝いします。無料相談はこちら
参考にした情報
- php.net「Informational advisory: Session upload progress」（2026年10月23日）
- php.net「Security advisory: Critical remote code execution vulnerabilities, update now」（2026年10月21日） / サポート中のバージョン
- GitHub（php-src）のセキュリティアドバイザリ：GHSA-6wmf-4rv5-p3rp（CVE-2026-109619）
- JPCERT/CC「PHPにおける複数の脆弱性（CVE-2026-109618、CVE-2026-109619）に関する注意喚起」（2026年10月22日公開、10月26日更新）
- PHP マニュアル「Session Upload Progress」 / 「Runtime Configuration（セッション）」
