WEBサイトPHP公式は、次の通常のリリースまで、セッションのアップロード進捗を0にするよう勧めた ── 設定の値・切り替えるコード・修正版に上げたあとの戻りを確かめる13項目（2026年10月時点）
PHP公式は、次の通常のリリースまで、セッションのアップロード進捗を0にするよう勧めた ── 設定の値・切り替えるコード・修正版に上げたあとの戻りを確かめる13項目（2026年10月時点）
目次
01 何が書いてあるか — PHP公式は、次の通常のリリースまで、セッションのアップロード進捗を0にするよう勧めた
引用について
この記事の「" "」で囲んだ英語の文は、PHP公式サイトのニュースと設定のマニュアル、PHPの脆弱性情報（GitHubのアドバイザリ）、Cloudflareのブログからの引用で、日本語訳は記事の筆者が付けたものである。原文は各出典のページで確かめられる。各ページは2026年10月26日に開いて、本文を取り直して確かめた。
2026年10月23日の告知は、1つの設定を0にするよう勧める
PHPの公式サイトは、2026年10月23日に「Informational advisory: Session upload progress（訳: 情報提供の注意: セッションのアップロード進捗）」という告知を出した。10月21日に出た重大な脆弱性2件（CVE-2026-109618とCVE-2026-109619）の修正版とは別の話で、CVE-2026-115560という別の番号が付いている。10月21日の件は、ブログPHPの重大な脆弱性「php2shell」を、初心者から上級者まで1本で ── 自分のサイトは関係あるか、更新の順番、更新の後に確かめること、攻撃を受けたかの調べ方、当サイトとチームの記録に書いた。この記事は、10月23日の告知だけを扱う。告知の最初の文は、次のとおりである。
"We suggest you set session.upload_progress.enabled=0 until the next regular bugfix release, to fully protect from an unlikely RCE vector."
（訳: 次の通常のバグ修正版が出るまで、session.upload_progress.enabled=0 にするよう勧める。起こりにくい遠隔コード実行の経路から、完全に守るために。）
「RCE」は、外から送った命令を、サーバーで実行されてしまう問題（遠隔コード実行）の略である。公式は、この件を「unlikely（起こりにくい）」と書きながら、設定を0にするよう勧めている。
起きるのは、条件が3つ重なったときだけ
告知は、起きる場合を次のように書いた。
"The issue can only occur under an unusual combination of configuration and application code."
（訳: この問題は、設定とアプリケーションのコードの、普通ではない組み合わせのもとでしか起きない。）
その「組み合わせ」の中身は、続く文にある。
"An application must set session.serialize_handler to php_binary or php_serialize in its configuration and then switch it to php at runtime with ini_set() before calling session_start(). Session upload progress must also still be enabled."
（訳: アプリケーションが、設定で session.serialize_handler を php_binary か php_serialize にしたうえで、session_start() を呼ぶ前に、実行中に ini_set() で php に切り替えている必要がある。セッションのアップロード進捗も、まだ有効のままでなければならない。）
これを3つに分ける。条件1は、設定で保存形式が php_binary か php_serialize になっていること。条件2は、コードが、実行中に ini_set() で保存形式を php に切り替え、そのあとで session_start() を呼ぶこと。条件3は、アップロード進捗が有効のままであること。
10月21日に設定済みなら、そのままでよい
告知には、すでに0にしたサイトへの案内もある。
"If you applied it then, keep it in place and no further action is needed."
（訳: そのとき設定したなら、そのままにしておけばよく、これ以上の対応は要らない。）
「そのとき」は、10月21日の脆弱性情報で、同じ設定が暫定の対策として挙がっていたことを指す。この記事の確認が役に立つのは、まだ0にしていないサイト、0にしたか記録が残っていないサイト、そして、修正版に上げたときに、暫定の設定を元に戻したかもしれないサイトである。
「次の通常のリリース」の日付は、告知に書かれていない
公式は、この問題の扱いを、こう書いた。
"Since this setup is unlikely in practice, we are handling it in the regular release cycle and will publish a full advisory for CVE-2026-115560 with the next release."
（訳: この構成は実際には起こりにくいので、通常のリリースの周期で扱い、次のリリースで、CVE-2026-115560の完全なアドバイザリを公開する。）
2026年10月26日に開いた告知のページには、「次のリリース」の日付は書かれていなかった。この記事では、日付を書かず、「次のリリースで直る」とも書かない。Cloudflareのブログは、この件が「fully patched PHP releases, including 8.5.12（訳: 修正が全部入ったPHPの版、8.5.12を含む）」に影響すると書いた。10月21日の修正版に上げただけでは、この件は消えない。
既存の記事との分担
10月21日の件には、すでに記事がある。担当サイトのPHPの版を台帳にしたPHPの修正版が出た日に「どのサイトが当たるか」を数分で答えるには、担当サイトの一覧が要る ── 台帳の8列を埋めて確かめる13項目（2026年10月時点）、ログの数え方を扱ったPHPの脆弱性の「痕跡」は、ログに無いこともある ── 圧縮されたログ・エラーの出る先・回転の直後を落とさずに、件数で数える13項目（2026年10月時点）などである（末尾に並べた）。この記事は、設定の値と、コードの中の切り替えを確かめるところに絞る。台帳の列には「PHPの版」はあるが、「upload_progress の値」はない。その列を足すのが、出口である。
02 なぜ・背景 — 設定は「どこで決まるか」が複数あり、1か所を見ても答えが出ない
同じ設定でも、変えられる場所が違う
PHPマニュアルの「Where a configuration setting may be set（訳: 設定を変えられる場所）」のページは、4つの区分を挙げる。そのうち、この記事に関係する2つは、次のように書かれている。
"Entry can be set in php.ini, .htaccess, httpd.conf or .user.ini"
（訳: php.ini、.htaccess、httpd.conf、.user.ini で設定できる。）
これは、INI_PERDIRという区分の説明である。もう1つのINI_ALLは、「Entry can be set anywhere（訳: どこでも設定できる）」と書かれている。PHPマニュアルの設定一覧で、session.upload_progress.enabledはINI_PERDIR、session.serialize_handlerはINI_ALLになっている。INI_PERDIRは、ini_set()では設定できない区分である。
保存形式（serialize_handler）は、コードの中でも切り替えられるが、アップロード進捗の有効・無効は、コードの中からは切り替えられない。だから、条件2は「コードを読まないと分からない」。条件3は「設定を読めば分かる」。
公式が頼るなと書いた場所がある
10月21日のPHP公式の告知は、暫定の対策として設定を0にするとき、どこで設定するかを書いている。
"Set session.upload_progress.enabled=0 and restart every worker. Use php.ini, an FPM pool or server configuration that applies before request parsing. Do not rely on ini_set() or FPM .user.ini."
（訳: session.upload_progress.enabled=0 にして、すべてのワーカーを再起動する。php.ini、FPMのプール、または、要求を読み取る前に適用されるサーバーの設定を使う。ini_set() や、FPMの .user.ini には頼らない。）
「ワーカー」は、PHPが要求を処理するプロセスのことである。PHPマニュアルは、サーバーのモジュール版のPHPは、php.iniを「only once when the web server is started（訳: Webサーバーの起動時に1回だけ）」読むと書く。設定ファイルを直しても、再起動するまでは、動いているPHPの値は変わらない。
Webを動かすPHPと、コマンドのPHPは、別に設定を読む
手元のコマンドでphp -iを打つと表示される値は、コマンドで動くPHPの値である。Webの要求を処理しているPHPの値とは、限らない。マニュアルは、設定ファイルの探し方を、次のように書く。
"PHP then looks for php-SAPI.ini in that search path, and if that is not found, for php.ini. The SAPI name can be determined with php_sapi_name()."
（訳: そのあと、PHPは探す場所で php-SAPI.ini を探し、見つからなければ php.ini を探す。SAPIの名前は php_sapi_name() で分かる。）
「SAPI」は、PHPがどんな形で動いているか（コマンド、PHP-FPM、Apacheのモジュールなど）の名前である。コマンドとWebで、読まれるファイルが違うことがある。さらに、PHP-FPMでは、プールごとに値が上書きされることがある。FPMのマニュアルは、設定例の中でphp_admin_value[memory_limit] = 32Mのような行を示し、「Settings defined with php_admin_value and php_admin_flag cannot be overridden with ini_set().（訳: php_admin_value と php_admin_flag で決めた設定は、ini_set() では上書きできない。）」と書く。
03 この記事に出てくる用語
セッション
ログインしている人を、要求のあいだで覚えておく仕組みである。サーバー側にその人の情報を入れる箱を作る。PHPでは、session_start()を呼ぶと、この仕組みが動き始める。
セッションのアップロード進捗（session upload progress）
ファイルの送信中の進み具合を、セッションの箱に書き込む機能である。設定名はsession.upload_progress.enabled。1が有効、0が無効で、既定値は1である。
保存形式（serialize_handler）
セッションの箱に入れる情報を、文字列に直す書き方の名前である。php、php_binary、php_serializeの3つがある。PHPマニュアルの設定一覧では、session.serialize_handlerの既定値はphpである。
ini_set()
PHPのコードの中から、設定を実行中に書き換える関数である。
プール（FPMのプール）
PHP-FPMで、サイトごとに分けた、ワーカーの組と設定の単位である。プールごとに、設定の値が違うことがある。
04 型別 — 3つの条件を、サイトごとに「ある・ない・分からない」で台帳に書く
🅰 この作業が当てはまる人
PHPで動くサイトを担当している人は、全員が当てはまる。事業者に任せているサイトは、確認は「聞く」ことになる。自分でサーバーを持つサイトは、設定ファイルとコードの置き場を、自分で開く。
🅱 この作業が測っていないこと
この記事の手順は、次のことを確かめない。
- 攻撃を受けたかどうか — 設定とコードの状態を見るだけである
- 公式が書いた3つ以外の経路 — 10月21日の脆弱性情報は、設定を0にしても「blocks the confirmed session paths but not other variants（訳: 確認された、セッションの経路は塞ぐが、ほかの変種は塞がない）」と書く。設定を0にしても、完全に安全にはならない
- 修正版が入っているか — 版の確認は、01章で挙げた台帳の記事で行う
🅲 手順: 値を読み、コードを探し、台帳に書く
手順1: Webを動かすPHPが、どの形で動いているかを書く
PHP-FPM、Apacheのモジュール（mod_php）、そのほか。形によって、設定を変える場所が変わる。分からなければ「不明」と書く。
手順2: Webの要求を処理するPHPで、upload_progress の値を読む
読み方は、3つある。管理画面から値が読めないサイトは、事業者に、「Webを処理するPHPの値」と書いて聞く。コマンドの値を答えられることがあるからである。
| 読み方 | 何が分かるか | 注意 |
|---|---|---|
| phpinfo() の画面 | 設定ごとに、Local Value と Master Value が並ぶ。筆者は、前者を、いま動いている要求での値、後者を、php.ini の値と読む（この読み方は筆者のもの） | サーバーの情報が大量に出る。見終わったら、すぐ消す |
| ini_get() で値を出す小さなページ | Webの要求を処理しているPHPの、いまの値。ini_get('session.upload_progress.enabled') の戻り値は、有効なら "1"、無効なら "0" か空の文字列 | 確認が終わったら消す。置く権限が無いサイトでは使えない |
| php -i と php --ini | コマンドで動くPHPの値と、読み込んだ設定ファイルの一覧 | Webの値とは限らない |
PHPマニュアルは、phpinfo()を「master and local values of configuration options（訳: 設定の、マスター値とローカル値）」を出す関数と説明する。マニュアルが書いているのは、ここまでである。2つの値が違うときの読み方は、マニュアルの文ではなく、筆者の読みである。筆者は、2つが違うとき、php.ini 以外の場所（FPMのプール設定、サーバーの設定、.user.ini など）で上書きされている可能性があると読む。同じ処理の中で ini_set() を使って値を変えた場合も、2つは違う値になる。違う理由が分からないときは、台帳に「不明」と書く。
確認用のページの中身は、次の1行で足りる。2つの設定の値が、「アップロード進捗 / 保存形式」の順で出る。
<?php echo ini_get('session.upload_progress.enabled'), ' / ', ini_get('session.serialize_handler');
確認用のページは、消す
phpinfo()の画面や、ini_get()の値を出すページは、確認が終わったらすぐに消す。公開の場所に残すと、サーバーの中身を、外の人に見せることになる。置く前に、見られる人を限る場所（認証のあるフォルダなど）に置けるかを確かめる。確認のために置いた控えやページを公開の場所に積もらせない考え方は、ブログ控えファイルを外から確かめた日 ── 当サイトで読めたのは25本。「403でも置かない」理由と、次から積もらない手順にも書いた。
手順3: 保存形式（serialize_handler）の値を、同じ方法で読む
同じ画面で、session.serialize_handlerの行を読む。php、php_binary、php_serializeのどれかを、台帳に書く。phpのままなら、公式が書く条件1は、設定の面では当てはまらない。
手順4: コードの中で、保存形式を切り替えている所を探す
条件2は、コードを読まないと分からない。探す範囲は、サイトのコードの置き場全体である。WordPressなら、テーマ、プラグイン、設定ファイル、自分で足したコードを含む。プラグインの提供元が書いたコードも、探す範囲に入れる。
まず、次の1つの文字列で探す。
session.serialize_handler
この文字列で検索して、見つかったファイルを数える。コードの検索は、エディタの「フォルダ内を検索」でもよいし、サーバーに入れる人はgrep -rnでもよい。見つかったファイルを1つずつ開いて、次の3つのどれかを書く。ini_setの引数として書かれている／コメントや説明の文字列の中にある／設定ファイルの値として書かれている。条件2に当たるのは、1番目だけである。
文字の検索では、見つからない書き方がある
設定の名前を、変数で渡す書き方は、文字の検索では見つからない。たとえば、フレームワークがセッションの設定をまとめて ini_set() に渡す書き方である。コードの検索で0件でも、「条件2は無い」とは言えない。
決め手は、動いているPHPの値である。Webから動くPHPの phpinfo() などで、session.serialize_handlerとsession.upload_progress.enabledの2つを読む。保存形式が php のままなら条件1が、進捗が 0 なら条件3が、当てはまらない。この2つは、検索の結果に左右されない。値では分からないのは、条件2だけで、分からないときは台帳にそう書き、事業者に聞く（手順7）。
実務のヒント
検索の語は、1語に絞る。「ini_set」で検索すると、件数が多すぎて終わらない。見つからなければ、「見つからない」と日付と探した範囲を台帳に書く。探した数を書かない「0件」の危うさは、ブログ「0件」に、探した数を書いていなかった ── 9種類で確かめた5日後、73種類で確かめ直したに、使っていないと見えたコードが実は動いていた例は、ブログ「使われていないコード」は証明できない ── 指定した場所は死んでいて、指定しなかった場所が生きていたに書いた。
手順5: 設定ファイルにも、同じ設定が書かれていないか探す
コードのほかに、設定ファイルが設定を上書きしていることがある。.htaccess、サーバーの設定、FPMのプールの設定、.user.ini の4種類を、session.upload_progressの語で検索し、値を書いた行の場所を書き留める。
手順6: 条件を、台帳に「ある・ない・分からない」で書く
書き方の見本を、次の表に示す。
| 条件1: 保存形式の設定 | 条件2: 切り替えるコード | 条件3: 進捗 | 台帳に書く読み方と対応 |
|---|---|---|---|
| php_binary か php_serialize | 見つかった | 有効（1） | 3つがそろう。0にする。設定を変える権限が無ければ、事業者に頼む |
| php_binary か php_serialize | 見つかった | 0 | 条件3が無い。0のまま保つ。修正版に上げたときに戻っていないか、見直す日を決める |
| php_binary か php_serialize | 見つからない（範囲を書く） | 有効（1） | 公式は、実行中に切り替えなければ有効のままでよいと書く。0にする勧めも同じ告知にあるので、止めるかを、権限のある人と決める |
| php（既定値） | 見つかった・見つからない | 有効（1） | 条件1の「設定で php_binary か php_serialize」が当てはまらない。切り替えるコードや設定が増えていないか、見直す日を決める |
| 読めない | 探していない | 読めない | 「分からない」と書く。事業者への質問を、手順7で作る |
表を埋めたら、台帳の一番下に、サイトの数、3つの条件がそろったサイトの数、「分からない」を含む行の数を、行を数えて書く。
3つの条件ごとの、確かめ方・止め方・限界
3つの条件は、確かめる方法も、止める方法も違う。次の整理は、本文で挙げた手順を、条件ごとにまとめ直したもので、筆者の整理である。
- 条件1（保存形式の設定） — 確かめ方は、動いているPHPの値を読むこと（手順3）。公式の告知が勧めるのは条件3を0にすることだけである
- 条件2（実行中の切り替え） — 確かめ方は、コードの検索（手順4）。限界は、設定の名前を変数で渡す書き方が、検索で見つからないこと
- 条件3（進捗が有効のまま） — 確かめ方は、動いているPHPの値を読むこと（手順2）。止め方は、php.ini、FPMのプール、要求を読み取る前に適用されるサーバーの設定のどれかで0にして、全ワーカーを再起動すること（公式の書き方）。限界は、進捗の棒を出しているサイトで、棒が動かなくなること
手順7: 事業者・制作会社への聞き方を、あらかじめ書く
聞く前に、台帳の「分からない」の行をサイトごとに集め、1通にまとめて送る（筆者の進め方）。答えが、Webを処理しているPHPの値か、コマンドで読んだ値かも答えてもらい、答えを受けた日と答えた人を、台帳の同じ行へ書く。答えが来ないときは、月に1回の見直し日に、もう一度聞く。
聞く文の見本
「PHP公式が2026年10月23日に出した注意（CVE-2026-115560）について、ご確認をお願いします。(1) Webの要求を処理しているPHPで、session.upload_progress.enabled の値はいくつですか。(2) 0 でない場合、php.ini かプールの設定で 0 にできますか。変更後に再起動は要りますか。(3) 当方のサイトのコードで、実行中に session.serialize_handler を切り替えている所の調査は、そちらで行えますか。難しい場合は、当方で調べる範囲を教えてください。」
05 明日、自社のサイトで確認できることチェックリスト
以下は、担当サイトのPHPで、セッションのアップロード進捗と保存形式の設定を確かめる13項目である。1〜3番目は動かし方と値を読む準備、4〜6番目は値を読む、7〜9番目はコードと設定ファイルを探す、10〜13番目は書き残す・変える・戻りを見直す、の確認である。1項目は5分以内を目安にする。チェックの状態はブラウザに保存され、サーバーには送られない。
- 担当サイトを書き出し、Webを動かすPHPの形（PHP-FPM・mod_php・不明）を台帳へ書く
- 値を読む方法を、サイトごとに1つ選ぶ（管理画面・確認用のページ・事業者への問い合わせ）。確認用のページなら、消す日を書く
- 確認用のページを置いたサイトで、確認後すぐに消し、そのURLを外から開いて、ページが出ないことを確かめる
- Webを処理するPHPで session.upload_progress.enabled の値を読み、1・0・空のどれかを台帳へ書き写す
- Local Value と Master Value が違うサイトに印を付け、違う理由を1行で書く（分からなければ「不明」）
- 同じ画面で session.serialize_handler の値を読み、php・php_binary・php_serialize のどれかを台帳へ書き写す
- コードの置き場全体（テーマ・プラグイン・自作のコードを含む）を session.serialize_handler の語で検索し、見つかったファイルの数を台帳へ書く（0件でも「条件2は無い」とは書かず、「検索では見つからない」と書く）
- 見つかったファイルを1つずつ開き、ini_set の引数か、コメントか、設定ファイルの値かを書き分け、「ini_set で切り替えている」数を書く
- .htaccess・サーバー設定・FPMのプール設定・.user.ini の4種類を session.upload_progress の語で検索し、値を書いた行の場所を台帳へ書く
- サイトごとに、条件1・条件2・条件3を「ある・ない・分からない」で台帳へ書き、「分からない」の行に、事業者へ聞く文を書く
- 0 にする場合の変更場所（php.ini・プール設定のどちらか）を決め、その設定を変えられる人の名前を、台帳の同じ行へ書く
- 0 にしたあとに再起動した日時と、読み直した値を、台帳へ書く（済んでいない行は「未再起動」と書く）
- PHPを修正版に上げた日の変更記録を開き、upload_progress を 1 に戻した行が無いかを確かめ、月に1回の見直し日をカレンダーへ入れる
4番目と6番目の設定の値は、サイトの中でしか読めない。外から見える範囲は、当サイトの無料ツールの1つ、🔧 WEBサイトの外からできるセキュリティ対策監査ツールで確かめられる。設定の値そのものは見えないので、確認用のページは、消したあとにそのURLを、ブラウザで開いて確かめる。13番目の見直し日には、アクセスログも1回通しておくとよい。🔧 IPA提供 攻撃兆候検出ツール iLogScanner で簡単ログ分析ツールは、アクセスログから攻撃の兆候を調べる、会員限定のツールである。
06 代替・他の選択肢 — 止める方法は、1つではない
サイトの預け方ごとの、動き方
自分でサーバーを持つ人は、読むのも変えるのも自分で、0にしたら再起動の日時を台帳へ書く。事業者の共有サーバーを借りる人は、管理画面に項目があるかを見て、無ければ依頼する。制作会社が運用している人は、手順7の聞く文を送る（筆者の整理）。
止める場所は、公式が3つ挙げて、2つに頼るなと書いた
公式が使うよう書いたのは、php.ini、FPMのプール、要求の読み取り前に適用されるサーバーの設定である。頼るなと書いたのは、ini_set()と、FPMの.user.iniである。方法ごとの向き・不向きを、次の表に整理する。
| 方法 | 公式の書き方 | 向く人 | 限界 |
|---|---|---|---|
| php.ini | 使うよう書いた | サーバーの設定ファイルを触れる人 | 再起動するまで値は変わらない。同じサーバーの全サイトに効く |
| FPMのプール設定 | 使うよう書いた | サイトごとにプールを分けている人 | プールを分けていなければ、全サイトに効く |
| サーバーの設定 | 「要求を読み取る前に適用される」ものを使うよう書いた | Apacheなどの設定を触れる人 | 書き場所で、効くのが読み取りの前か後かが変わる。事業者に聞く |
| 事業者の管理画面 | 書いていない | 管理画面に項目がある人 | 項目が無い事業者がある。無ければ依頼する |
| .user.ini と ini_set() | 頼らないよう書いた | （向く人はいない） | ini_set() は、この設定をそもそも変えられない（INI_PERDIR） |
修正版に上げたあとも、0を保つ公式の勧めがある
10月21日のGitHubの脆弱性情報には、修正版に上げたあとの扱いが書かれている。
"It might be prudent to set session.upload_progress.enabled=0 if you don't need this feature even after applying the patch, as more attackers try to find flaws in this hardly-used and hardly-tested feature."
（訳: この機能が要らないなら、修正を適用したあとでも、session.upload_progress.enabled=0 にしておくのが賢明かもしれない。ほとんど使われず、ほとんど試験もされていないこの機能の欠陥を探す攻撃者が、増えているからである。）
これは、10月23日の件とは別の脆弱性情報の文である。修正版に上げたあとも、使っていなければ0のままにするという考え方は、確認の13番目に直結する。
「使っているか」を、先に確かめる
0にすると、進捗の棒を出しているサイトでは、棒が動かなくなる。0にする前に、「送信中の進み具合が出る画面」があるかを、制作会社か、画面を開いて確かめる。棒が無いサイトなら、止めても、利用者から見える変化は無い。
07 当サイトで確かめたこと — この記事の根拠にした公式のページと、確かめていないこと
2026年10月26日に取り直して照らしたページ
この記事の引用は、2026年10月26日に、PHP公式サイトのニュース、PHPマニュアルの設定のページ、GitHubのPHPの脆弱性情報、Cloudflareのブログを開いて、本文を取り直して確かめた。引用した英文は、本文の英文と照らして、一致を確かめてある。
確かめていないこと
- 修正が入ったかを、版の番号以外で確かめる方法 — PHPマニュアルの設定一覧では、見つけられなかった
- 「次の通常のリリース」の日付と版 — 公式の告知のページに書かれていなかった。日付は書かない
- 実際のサーバーでの動作 — この記事の手順を、複数の事業者の環境で試したわけではない
- 各CMSやプラグインの、保存形式を切り替えるコードの有無 — 調べていない
当サイトのサーバーの対応
当サイト自身のサーバーの対応は、ブログPHPの重大な脆弱性「php2shell」を、初心者から上級者まで1本で ── 自分のサイトは関係あるか、更新の順番、更新の後に確かめること、攻撃を受けたかの調べ方、当サイトとチームの記録に書いてある。サーバーの設定の中身は、攻撃の材料になるので、この記事には書かない。この記事は、2026年10月26日の時点のものである。完全なアドバイザリが公開されたときは、日付つきで追記する。
08 このテーマは、ここまで
2026年10月21日 — 重大な脆弱性2件の修正版と、暫定の対策
PHP公式が、修正版を出し、暫定の対策として、session.upload_progress.enabled=0と、全ワーカーの再起動が挙がった。
2026年10月23日 — 情報提供の注意（CVE-2026-115560）
PHP公式が、設定を0にするよう勧め、完全なアドバイザリは次のリリースで出すと書いた。同日、Cloudflareがブログに追記した。
現在の貴方のIPアドレス
このサイトで書いている人
