php2shell対策にsession.upload_progressを切っておく
目次
TL;DR
公式 2026年10月21日23時（日本時間）に重大な脆弱性2件（CVSS v4.0 9.2）の修正版を公開予定。場所・影響バージョンは未発表
外部の推定 通称php2shell。少なくとも1件はsession.upload_progressの処理にあるメモリ破壊とされる（公式未確認）
暫定策 session.upload_progress.enabledを0に。進捗バーを使っていなければアップロードはそのまま通る。全部は防げない可能性があり、修正版が出たら更新
PHPのセキュリティチームが、2026年10月21日23時（日本時間）に緊急のセキュリティリリースを出すと予告した。
公式の告知には、重大な脆弱性が2件あることと、深刻度のスコアしか書かれていない。
一方でXや海外のセキュリティ企業のブログでは、php2shellという通称でCVE番号やコードの場所まで出回っていて、少なくとも1件はデフォルトで有効なsession.upload_progressの処理が原因とされている。
この処理は session.upload_progress.enabled という設定で止められるので、修正版を待つ間に切っておける。
ただし、防げるのは2件のうち1件だけという研究者の主張もある。
内容は日本時間10月21日13時時点のもので、修正版の公開後に変わる可能性がある。
session.upload_progress.enabledを切る手順
Session Upload Progressは、ファイルのアップロード中に進み具合をセッション（サーバーがユーザーごとの状態を覚えておく仕組み）の $_SESSION へ書き込む機能で、別のリクエストから進捗を読み出して進捗バーを出すのに使う。
PHPマニュアル では、session.upload_progress.enabled のデフォルト値は 1（有効）になっている。
この設定が有効で、POSTに session.upload_progress.name で指定した名前（デフォルトは PHP_SESSION_UPLOAD_PROGRESS）のフィールドが含まれていると、進捗が記録される。
このフィールドはリクエストを送る側が付けるので、アプリに進捗バーを実装していなくても、設定が有効なら処理は実行される。
マニュアルは以前から、進捗バーを使わないアプリではこの設定を無効にするよう勧めていて、理由として、送られたファイル名とフィールド名が検証されずにセッションへ書き込まれ、別のファイル読み込みの脆弱性と組み合わせると悪用しやすくなる点を挙げている。
この設定で止まるのは進捗の記録だけなので、影響が出るのはアップロード中に進捗バーを出しているアプリで、その場合も進捗表示が出なくなるだけでアップロード自体は通る。
この設定はPHPのコード中の ini_set() では変えられず（マニュアル上の区分は INI_PERDIR）、php.iniかディレクトリ単位の設定ファイルに書く必要がある。
どこに書くかは環境によって違う。
| 環境 | 書く場所 | 書き方 | 反映 |
|---|---|---|---|
| レンタルサーバー（さくら、エックスサーバーなど） | 管理画面のphp.ini設定 | session.upload_progress.enabled = 0 | 各社の仕様による |
| サーバーを自分で管理している | php.ini | session.upload_progress.enabled = 0 | PHP-FPMならプロセスを、mod_phpならApacheを再起動 |
| php.iniを編集できず、PHPがApacheモジュール（mod_php）で動いている | .htaccess | php_flag session.upload_progress.enabled off | Apache側で AllowOverride Options か All が許可されている環境だけ |
| php.iniを編集できず、PHPがCGI/FastCGI（PHP-FPMなど）で動いている | .user.ini | session.upload_progress.enabled = 0 | 再読み込みの間隔 user_ini.cache_ttl がデフォルト300秒なので、最大5分かかる |
mod_php、PHP-FPM、CGI/FastCGIは、WebサーバーからPHPを動かす方式の名前だ。
自分の環境がどれかは、phpinfo() の表示の「Server API」欄で分かり、Apache 2.0 Handler ならmod_php、FPM/FastCGI や CGI/FastCGI ならそれ以外になる。
さくらのレンタルサーバは、サーバコントロールパネルの「スクリプト設定」から「php.ini設定」を開いて追記する（さくらのサポート）。
ここに書いた内容は /www 配下に適用される。
PHP 8以降はさくらの既定の設定に追加されるが、PHP 8より前は既定の設定が無視されて書いた設定だけが反映されるので、この1行だけを書くとほかの項目はさくらの既定値ではなくなる。
フォルダにphp.iniを置いて上書きする方法も古くから使われているが、公式ヘルプには載っていないので、使う場合は値が変わったかを phpinfo() で確かめる。
エックスサーバーは、サーバーパネルの「php.ini設定」でドメインごとに設定する（エックスサーバーのマニュアル）。
.user.ini はCGI/FastCGIでしか読み込まれず、Apacheモジュールでは無視される（PHPマニュアル）。
逆に .htaccess の php_flag はApacheモジュールのときだけ使える（PHPマニュアル）。
それ以外の環境の .htaccess に書くと、サイト全体が500エラーになることがあるので、書いたらすぐにページが表示されるかを確かめ、エラーが出たらその行を消して戻す。
反映したかどうかは、<?php phpinfo(); とだけ書いたファイルを公開ディレクトリに置き、ブラウザで開いて session.upload_progress.enabled の値が 0（Off）になっているかで確かめる。
phpinfo() はサーバーの設定や環境情報をまとめて表示するので、確認が終わったらこのファイルは必ず消す。
コマンドラインの php -i で表示されるのはCLI用の設定で、Webサーバー側の値とは別になる。
設定を切っても防げない可能性
GMO Flatt Securityの解説 は、修正版が出るまでの暫定策としてこの無効化を挙げているが、今回の件に100%効果があるとは言い切れず、一定の確率で役に立つと書いている。
Xで再現を報告した研究者J4ck3LSyNは、自身の解説 で、無効化で防げるのは2件のうち1件だけだと書いている。
もう1件はこの設定と関係なく、マルチパート（ファイル送信に使うPOSTの形式）を解析する処理で起きると主張している。
EUの機関向けにセキュリティ情報を出しているCERT-EUの注意喚起（アドバイザリ）は、すぐにパッチを当てられない場合の暫定策としてインターネットに公開しているアプリの隔離を挙げていて、設定の無効化は挙げていない（CERT-EUのアドバイザリ）。
| 対策 | 挙げている情報源 | 注意点 |
|---|---|---|
| 修正版への更新 | PHP公式、CERT-EU、Huntressほか | 修正版の番号は23時の公開待ち |
session.upload_progress.enabled = 0 | Flatt Security、J4ck3LSyN | 防げるのは2件のうち1件だけという主張あり |
| インターネットからの切り離し、VPNの内側やWAF（Webアプリへの攻撃を手前で止める仕組み）の背後へ置く | CERT-EU、Huntress | 修正版が出ないサポート切れのPHPでも必要になる |
PHP公式の告知
告知は2026年10月20日付で php.netのニュース に掲載された。
| 項目 | 公式告知の内容 |
|---|---|
| 公開予定 | 2026年10月21日 14:00 UTC（日本時間23時） |
| 件数 | 重大な脆弱性2件 |
| 深刻度 | どちらもCVSS v4.0で9.2 |
| CVE番号 | 記載なし |
| 影響バージョン・修正バージョン | リリース時に公開 |
| 前倒し | どちらかの詳細が公になるか、実際の悪用が確認された場合は早める可能性あり |
CVSSは脆弱性の深刻度を0〜10で表す共通の指標で、9.0以上が最上位の「Critical」に当たる。
告知は全PHPユーザーに、修正版が出たらすぐ更新できるよう準備を呼びかけているが、脆弱性の場所や攻撃の条件は書いていない。
リークで先に広まった経緯
Huntressの解説 によると、10月20日の午前（米国時間）にHacker Newsへ、重大なPHP脆弱性2件が近く公開されるという投稿があった。
投稿はすぐ削除されたがスクリーンショットがSNSに広まり、数時間後にはセキュリティ企業のwatchTowrが脆弱性は実在すると確認し、CVE-2026-109618を再現したと発表している。
PHPのリリースは、当初の予定より1日早い10月21日になった。
Huntressは記事を出した時点で、自社が監視している顧客の環境では実際の悪用を確認していない。
攻撃の様子を写した短い動画が一度投稿され、その後削除されたとも書いている。
php2shellについて外部で言われていること
Use-After-Free（UAF）は、解放したメモリを後から使ってしまうバグで、解放済みの領域に攻撃者が用意したデータを書き込めると、プログラムの実行を乗っ取られて任意のコード実行につながることがある。
外部ではphp2shellのうち少なくとも1件がこのUAFで、外部から任意のコードを実行されるリモートコード実行（RCE）につながるとされている。
| 情報源 | 主張 | 確認の度合い |
|---|---|---|
| CERT-EU アドバイザリ2026-018 | CVE-2026-109618とCVE-2026-109619。認証なしのRCEの可能性 | 公式発表ではなくリーク情報に基づくと明記 |
| J4ck3LSyNの解説 | ext/session/session.c の php_session_rfc1867_callback() にヒープ（実行中に確保するメモリ領域）のUAF。Xの投稿ではUAF 2件とし、解説ではもう1件をマルチパートの解析処理としている | 本人の検証による主張。根本原因の分析が正しいかは公式発表後に確かめると本人が書いている |
| GMO Flatt Securityの解説 | メモリ破壊は ext/session のSession Upload Progress機能に関わるもの | 同社の独自調査とphp2shellの情報が一致する部分からの推定。不正確な情報を含む可能性を断っている |
Flatt Securityの記事は、ある研究者が投稿した動画のログも引用している。
ログには、Ubuntu 26.04のPHP 8.5.4パッケージとApache prefork/mod_phpの環境で、Webサーバーの実行ユーザー www-data（uid=33）としてコマンドが実行された結果が写っている。
Flatt Security自身の再現結果は、記事には載っていない。
J4ck3LSyNのほうは、PHP 8.4.4と8.2.34のソースで検証したとしている。
公式告知とリーク情報では件数とCVSSが一致し、CVE番号は複数の組織が同じものを挙げ、脆弱なコードの場所もFlatt SecurityとJ4ck3LSyNで同じ機能を指している。
ただし、公式はまだ2件の内容を明かしていない。
影響バージョンの情報
CERT-EUのアドバイザリは、SNSの投稿を出典に、PHP 5以降の全バージョンが影響を受けうると書いている。
Huntressは、修正はサポート中のPHP 8系だけに出るという見方を紹介したうえで、5系、7系、8.0、8.1を使っている環境では更新か隔離が必要になると書いている。
J4ck3LSyNの解説は更新先として8.5.12、8.4.27、8.3.36、8.2.35を挙げているが、本人の予想した番号で、公式の修正版の番号は23時の公開待ちだ。
10月21日23時の公開で確かめること
次の項目は、いずれも公式がまだ明かしていない。
| 確認項目 | 外部での現時点の情報 |
|---|---|
| CVE番号と2件の内容 | CVE-2026-109618/109619。少なくとも1件はsession.upload_progressのUAFとされる |
| 影響バージョンと修正バージョン | PHP 5以降すべてという未確認の主張あり |
| 影響する動かし方（mod_php、PHP-FPMなど） | Flatt Securityが引用した研究者の投稿は、mod_phpやphp-fpmなど複数の構成で再現したとしている |
| 認証なしで攻撃できるか | CERT-EUは認証なしのRCEの可能性ありとする |
| session.upload_progress.enabled=0で防げるか | Flatt Securityは一定の効果があるとし、J4ck3LSyNは2件のうち1件だけと主張 |