session.upload_progress を無効にすると何が防げますか？
PHP 公式によると、session.upload_progress.enabled を 0 にすると、確認されているセッション関連の攻撃経路の一部を止められます。ただし、すべての経路を止めるものではありません。
注意点が三つあります。
- リクエストを読み込む前に有効になっている必要があります。
ini_set()で途中から変えたり、PHP-FPM で.user.iniに書いたりする方法では足りません。php.ini など、PHP の起動時に読み込まれる設定で行います。 - すべてのワーカーの再起動が必要です。再起動しないと、古い設定のワーカーが動き続けます。
- アップロードの進捗表示が使えなくなる場合があります。この機能を使っているサイトは動作を確認してください。
レンタルサーバーの利用者は、この設定を自分で正しく反映できないことが多いため、サーバー会社の対応を待つのが現実的です。
PHP 8.5 で使える追加の設定はありますか？
PHP 8.5 では、fatal_error_backtraces を 0 にすると、確認されている fatal backtrace の経路を止められます。ほかの経路は残り、エラー調査のための情報が減ります。これも修正の代わりにはなりません。
CVE-2026-109618 向けの memory_limit と post_max_size の暫定対策とは？
PHP 公式は CVE-2026-109618 の暫定対策として、次の二つを案内しています。
memory_limitを-1（上限なし）にする：PHP のメモリ上限による失敗はなくなりますが、より下のレベルでメモリ確保に失敗すると、脆弱な経路に届く可能性は残ります。アプリが上書きできない形で設定する必要があり、サーバーのメモリを使い切らないよう注意が必要です。RLIMIT_ASやRLIMIT_DATAでの代用はできません。post_max_sizeを小さくする：メモリ不足の経路にさらされる機会を減らします。アップロードがないサイトは 8M、アップロードが必要なら 32M が目安です。それより大きなアップロードは失敗するようになります。
どちらも修正の代わりにはなりません。メモリの上限を外す設定は、ほかの利用者と共有しているサーバーでは使えないことが多く、サーバーの担当者が判断してください。
Cloudflare などの WAF で防げますか？
一部は防げます。Cloudflare は WAF の利用者向けに既定の防御ルールを導入したと発表しています。ただし、WAF は既知の攻撃パターンを止めるもので、サーバーの PHP を直すわけではありません。新しい攻撃方法や、WAF を通らない経路は残ります。
メンテナンスモードのプラグインで止められますか？
止められません。WordPress のメンテナンスモードは、PHP が動いた後に画面を切り替えるものです。この脆弱性は、アプリの処理より前の段階で起きる経路があるため、プラグインでは防げません。
サイトを一時停止するべきですか？
修正をすぐに適用できない場合は、検討する価値があります。個人情報や決済情報を扱うサイトならなおさらです。国家サイバー統括室（NCO）も、修正を速やかに適用できない場合はWeb サイトの一時停止もリスクを下げる有効策の一つだとしています。停止する場合は、PHP に届く前の段階（Web サーバーやロードバランサー）で止めてください。
回避策を入れたら判定は「修正済み」になりますか？
なりません。PHP2Shell チェッカーでは、回避策は別の情報として表示し、判定は PHP のバージョンだけで行います。回避策はあくまで、修正版への更新までのつなぎです。
情報源
このページの主要な事実（修正版、CVE の内容、配布元のパッケージ、公的機関の呼びかけ）は公式の情報源にもとづいています。研究者の報告、報道、コミュニティの投稿はそれぞれ区別して表示しています。
- Security advisory: Critical remote code execution vulnerabilities, update now公式 The PHP Group
- RCE via stale global state公式 The PHP Group
- Cloudflare deploys protections against php2shell vulnerabilityCDN 事業者 Cloudflare
- 修正を速やかに適用できない場合、サイトの一時停止も有効策（X）公式 国家サイバー統括室（NCO）