2026.10.21

システム開発アプリケーション開発

PHP緊急脆弱性「php2shell」深掘り調査｜CVE-2026-109618 / CVE-2026-109619 修正版公開前にわかっていること

PHP本体に、CVSS v4.0で9.2という深刻度「Critical」の脆弱性が2件見つかり、PHP開発チームが日本時間の今夜（2026年10月21日）23:00にセキュリティリリースを予定しています。通称「php2shell」、CVE番号は CVE-2026-109618 / CVE-2026-109619 として扱われています。

PHP側は影響バージョンや技術的な詳細を修正版の公開まで伏せており、ネット上には「PHP 5以降はすべて影響」「この設定を変えれば防げる」といった情報が飛び交っています。この記事では、PHP公式・CERT-EU・IPA・GMO Flatt Security・独立研究者の公開情報を突き合わせ、確定していること／有力だがまだ断定できないこと／今夜までにやっておくべきことを分けて整理します。

調査時点：2026年10月21日 18:10ごろ（日本時間）
PHP公式の修正版公開予定：2026年10月21日 23:00 JST（14:00 UTC）

記事の内容は調査時点の情報にもとづいています。修正版の公開後に評価が変わる可能性がある点にご注意ください。

この記事で参照した主な情報源

PHP Security Team によるセキュリティリリースの事前通知（2026年10月20日）
PHP 公式マニュアル（Session Upload Progress、session.upload_progress.* の設定、INI_PERDIR、.user.ini）
PHP 公式サイト（サポート中の系列とサポート期限）
CERT-EU Security Advisory 2026-018
IPA「PHPの脆弱性（CVE-2026-109618、CVE-2026-109619）に関する事前注意喚起」 https://www.ipa.go.jp/security/security-alert/2026/pre-alert20261021.html
GMO Flatt Security による解説（10月21日14時更新分を含む）
Ahmed Sultan 氏による Session Upload Progress の Use-After-Free 検証ラボ
Nginx 公式ドキュメント（fastcgi_request_buffering）

現時点の結論

今回の「php2shell」は、よくあるWordPressプラグインやLaravelアプリケーションの脆弱性とは性質がかなり異なります。

PHP開発チームが公式に認めているのは、PHP本体にCVSS v4.0 9.2のCritical脆弱性が2件あり、10月21日23:00 JSTにセキュリティリリースを出す、というところまでです。影響バージョン、技術詳細、修正版のバージョン番号は、意図的にパッチ公開時まで伏せられています。

一方で、CERT-EU、GMO Flatt Security、脆弱性研究者の公開情報を突き合わせると、少なくとも一つの有力な攻撃経路として、次の構造が浮かび上がっています。

PHPコアの multipart/form-data 処理
  → Session Upload Progress
  → セッション内部のメモリ管理
  → Use-After-Free（解放済みメモリの参照）
  → メモリ破壊
  → 条件を整えるとリモートコード実行（RCE）

独立研究者のAhmed Sultan氏が公開した検証環境（ラボ）では、Session Upload Progressの処理中に古いHashTable内のポインタが残ったままセッションが再初期化され、その古いポインタを通じて解放済みの領域へ書き込む――というUse-After-Freeに到達できることが再現されています。ただし、この公開PoC自体はクラッシュやRCEまでは達成しておらず、脆弱なコード経路に到達できることを示すものです。

また、GMO Flatt Securityが紹介している別の研究者のデモでは、Ubuntu 26.04上のPHP 8.5.4＋Apache mod_php環境で、PHPヒープや zval_ptr_dtor、zend_call_function などに関連するアドレスを漏えいさせたうえで、最終的に www-data 権限でコードを実行したとする画面が確認されています。GMO Flatt Securityは、公開されている情報と同社の独自調査が同一の脆弱性を指しているなら、実用的なRCEにつながるメモリ破壊脆弱性である可能性が高いと分析しています。

「Session Upload ProgressをOFFにすれば解決」ではない

ここが非常に重要です。

PHP開発チームは、まだ「Session Upload ProgressがCVE-2026-109618/109619の原因である」と公式には認めていません。
脆弱性は2件あります。
GMO Flatt Security自身も10月21日14時の更新で、当初推奨していた次の設定について見解を改めています。

session.upload_progress.enabled = 0

更新後の見解は「役に立つ可能性はあるが、攻撃は依然として可能」「根本的にはパッチが必要」というものです。したがって、「php2shell＝Session Upload ProgressをOFFにすれば解決」という理解は、現時点では誤りです。

現状の整理（10月21日18時時点）

項目	評価
Critical脆弱性が2件存在	PHP公式が確定
両方ともCVSS v4.0 9.2	PHP公式が確定
23:00 JSTに修正版を公開予定	PHP公式が確定
CVE-2026-109618 / CVE-2026-109619	CERT-EU等が使用。PHP公式の詳細は公開待ち
認証なしのRCEになり得る	CERT-EU・研究者の情報。PHP公式の詳細は公開待ち
メモリ破壊型	研究者のデモとGMO Flatt Securityの分析で強く示唆
Session Upload Progressが関係	独立研究にかなり強い証拠。ただしPHP公式は未確認
enabled=0 で完全に防げる	否定的。GMO Flatt Securityが「不十分」と更新
WordPress/Laravel/Symfony固有のバグ	そう考えるべきではない
実際の攻撃がすでに観測されている	IPAは現時点で確認していない
悪用可能と称するコードが流通	GMO Flatt Securityが確認・報告
正確な影響バージョン	未確定
修正版のバージョン番号	未発表

IPAも同日、「現時点でIPAが悪用した攻撃を確認しているわけではない」と明記しています。「exploitと称するコードがインターネット上にある」ことと、「実際に大規模な侵害が始まっている」ことは分けて考える必要があります。

確定情報と、海外情報から見える全体像

PHP Security Teamの事前通知

PHP Security Teamが10月20日に出した事前通知は、異例なほど簡潔です。公式に開示されたのは次の4点だけでした。

Criticalの脆弱性が2件ある
どちらもCVSS 9.2
10月21日14:00 UTCに修正版を出す
すべてのPHPユーザーは、ただちにアップグレードできるよう準備すること

詳細や実際の悪用が公になった場合は、予定より早くリリースする可能性もあるとしています。そして full details（詳細）／affected versions（影響バージョン）／fixed versions（修正版）はリリース時に公開する という方針です。

つまり、いまネット上にある「PHP 5以降は全部」「このバージョンなら安全」「この設定なら完全に防げる」といった情報は、少なくとも18時時点ではPHP Security Teamによる正式な影響判定ではありません。

CERT-EUとIPAの見解

欧州連合の機関向けCSIRTであるCERT-EUは、Security Advisory 2026-018でこの2件を CVE-2026-109618 / CVE-2026-109619 として扱っています。CERT-EUによれば、公開前に漏れた情報から、認証なしのリモートコード実行（unauthenticated remote code execution） につながる可能性があり、「PHP 5以降」が影響を受ける可能性があるとしています。ただしCERT-EU自身も、技術的な詳細はまだ公開されていないと明記しており、「PHP 5以降」という範囲も外部情報にもとづくものです。

IPAの注意喚起もこの点をかなり慎重に書いています。CERT-EUの「PHP 5以降」という情報を紹介しつつ、IPAとしては詳細な影響バージョンをまだ確認できていない、という立場です。

「PHP 5以降」という範囲との食い違い

ここには興味深い矛盾があります。

公開されている研究の中心にある Session Upload Progressは、PHP 5.4で導入された機能です。PHPの古いバグトラッカーにも、PHP 5.4で「new session.upload_progress.* directives」が追加されたと記録されています。つまり、「PHP 5.0以降すべてが影響」というリーク情報を、Session Upload ProgressのUse-After-Freeだけで説明することはできません。

ここから考えられるのは、次のいずれか、またはその組み合わせです。

2件のうち一方だけがSession Upload Progressに関係している
もう一方には別の攻撃経路がある
同じ根本原因でも、Session Upload Progress以外の経路から到達できる
「PHP 5以降」という事前リークの範囲自体が大まかである

これは現時点では推論ですが、GMO Flatt Securityが14時に「Session Upload ProgressをOFFにしても攻撃可能らしい」と見解を修正した事実とも整合します。

したがって、今回の2件を「CVE-2026-109618＝Upload ProgressのUAF」「CVE-2026-109619＝その同じ問題」と確定扱いするのは早すぎます。どちらのCVEがどのコード修正に対応するのかは、23時のPHP公式アドバイザリを見て判断する必要があります。

技術的に何が起きていると考えられるのか

Session Upload Progressとは

PHPには、ブラウザが大きなファイルをアップロードしている途中に「43%アップロード済み」のような進捗を、別のリクエストから取得できる Session Upload Progress というコア機能があります。

PHP公式マニュアルによると、既定の設定は次のとおりです。

session.upload_progress.enabled = 1
session.upload_progress.cleanup = 1
session.upload_progress.name = PHP_SESSION_UPLOAD_PROGRESS
session.upload_progress.freq = 1%
session.upload_progress.min_freq = 1

つまり、enabled は既定でONです。

クライアントがmultipartのPOST中に、既定名 PHP_SESSION_UPLOAD_PROGRESS のフィールドを含めると、PHP自身がアップロードの進捗をセッション内の配列に記録します。そこには処理済みのバイト数、ファイル名、フィールド名、一時ファイルの情報などが入ります。

アプリケーションより「前」に動く

この仕組みの重要な特徴は、WebアプリケーションのPHPスクリプトより先に動くことです。PHP公式マニュアルは、アップロードの進捗情報が「PHPスクリプトが実行される前にセッションへ書き込まれる」ことを明記しています。そのため、アプリ側で session_set_save_handler() を設定する前にも処理されます。

概念的には、次のような順序になります。

インターネット
     │
     ▼
Apache / Nginx
     │
     ▼
PHP multipart parser
     │
     ├─ RFC1867 ファイルアップロード処理
     │
     ├─ Session Upload Progress    ← 疑われている場所
     │
     └─ セッション内部処理
     │
     ▼
PHPアプリケーション開始
     │
     ├─ WordPress
     ├─ Laravel
     ├─ Symfony
     └─ 独自PHP

WordPressのログイン処理、Laravelのmiddleware、Symfonyのcontroller、アプリ内のCSRFチェックなどより前のPHPコア層で異常が起き得る、というのがポイントです。

公開されている研究が正しければ、WordPressやLaravelを最新版にするだけでは、PHP本体の問題は修正されません。逆に、WordPressなどを使っていなくても、PHPでmultipartリクエストを受けられる構成なら調査対象になります（PHP公式の実行順序とGMO Flatt Securityの分析を組み合わせた推論です）。

Use-After-Freeとは

Ahmed Sultan氏の独立ラボでは、より具体的な仮説が示されています。

multipartのPOSTを一度に全部送らず、次のように時間を空けて送ると、Session Upload Progressの更新処理が複数回発生します。

multipart開始
   ↓
ファイルデータの一部
   ↓
一定時間停止
   ↓
残りのファイルデータ

最初の処理で、セッションのHashTable内部を指す zval* のようなポインタがキャッシュされます。その後のセッション再初期化で元のHashTableが解放されても、キャッシュされたポインタは残ったままで、後続の処理がその解放済みメモリを参照・書き込みしてしまう――という分析です。

模式的に表すと、次のようになります。

① session HashTable A を作る

       cached pointer ───────┐
              │              │
              ▼              │
       HashTable A           │
       [progress data]       │
                             │
② セッション再初期化         │
                             │
       HashTable A ← free    │
                             │
       HashTable B           │
       [new data]            │
                             │
③ cached pointer は依然 ─────┘
   解放済みの A を指している

④ 後続データの処理
       ↓
   解放済みメモリへ書き込み
       ↓
   Use-After-Free

UAFがRCEになるまで

Use-After-Free（UAF）そのものと、RCEは同じ意味ではありません。

UAFを安定した任意コード実行にするには、ふつう次のような工程が必要になります。

解放された領域に、攻撃者が制御する別のオブジェクトを配置する（heap grooming）
メモリ配置を予測する
ASLRなどを突破するための情報漏えい
最終的に、制御可能な関数ポインタやPHP内部構造へ誘導する

実際、Sultan氏の公開PoCは「脆弱なコード経路に到達はできるが、クラッシュもコード実行も達成しない」と明記しており、RCE化にはヒープ配置の操作やビルド固有の情報が追加で必要だとしています。

一方、GMO Flatt Securityが解析した別の研究者のデモには、次のような出力がありました。

main_heap
stale_reference
zval_ptr_dtor
zend_call_function
...
EXECUTED -> uid=33(www-data)

Ubuntu 26.04 / PHP 8.5.4 / Apache prefork・mod_php の構成で、最終的にWebサーバーのユーザーである www-data としてコード実行に成功したと主張するものです。これが本物で、かつ同じ脆弱性であれば、研究者側ではUAFを実用的なRCEチェーンにまで発展させている可能性があります。

RCEが成立すると何が起きるか

RCEが成立した場合、攻撃者のコードは「PHPプロセスが持っているOS権限」で動きます。典型的にはrootそのものではなく www-data やPHP-FPMのpoolユーザーですが、それでも次のような情報にアクセスされる可能性があります。

PHP RCE
  │
  ├─ Webアプリの設定
  ├─ DBの接続情報
  ├─ APIキー
  ├─ 環境変数
  ├─ ファイルシステム
  └─ クラウドのIAM資格情報
           │
           ▼
      他サーバー / DB / ストレージ

被害がここまで広がり得るため、「Webサイトを書き換えられるだけ」の問題とは考えない方が安全です。GMO Flatt Securityが、パッチ適用前の対策として「サーバー内データの最小化」「IAMロールやサービスアカウントの権限の最小化」を強く勧めているのは、RCE後の横展開と情報窃取を抑えるためです。

どの環境が危ないのか

「PHP 8.xだから安全」「最新版だから安全」とは言えない

PHP公式が影響バージョンを公開していない以上、「PHP 8.xだから安全」「最新の8.5だから安全」と判断する材料はありません。

むしろ、GMO Flatt Securityが参照した研究者のデモではUbuntu 26.04のPHP 8.5.4が標的になっており、別の独立ラボではPHP 8.4.4 FPMで、疑われているUAFの経路が再現されています。「古いPHPだけの脆弱性」と見る根拠はありません。

調査時点で、PHP公式サイトに掲載されている各系列の最新版は次のとおりです。

PHP系列	調査時点の公式最新版
PHP 8.5	8.5.11
PHP 8.4	8.4.26
PHP 8.3	8.3.35
PHP 8.2	8.2.34

しかしPHP公式自身が「全PHPユーザーは次のセキュリティリリースへすぐ更新できるよう準備せよ」としているため、これらの最新版であっても、23時の修正版が出るまでは安全な版とは見なせません。

サポート終了（EOL）系列は特に深刻

現在PHP本家がサポートしているのは8.2〜8.5の各系列です。

PHP系列	セキュリティサポート終了予定
PHP 8.2	2026年12月31日
PHP 8.3	2027年末
PHP 8.4	2028年末
PHP 8.5	2029年末

PHP公式は、EOLの系列について「未修正のセキュリティ脆弱性にさらされ得るため、アップグレードすべき」としています。

これは PHP 7.x、PHP 8.0/8.1、PHP 5.x を運用している組織にとって特に重大です。もしそれらもphp2shellの影響対象だった場合、PHP本家からEOL系列向けの修正版が提供されるとは期待できません。OSディストリビューターが独自にバックポートするケースは別ですが、PHP本家という観点ではサポート対象外です。

WordPress・Laravel・Symfonyだから危ない、という意味ではない

GMO Flatt Securityが紹介している研究者の情報では、mod_php / php-fpm、WordPress / Laravel / Symfony など複数の構成で再現するとされています。ただしこれは、WordPressなどに同じ脆弱性がある、という意味ではありません。

公開研究のとおりPHPコアのmultipart/セッション処理が原因なら、WordPress、Laravel、Symfony、Drupal、独自CMS、自社のPHP API、単純な index.php に至るまで、それらの「下」にあるPHPランタイムそのものが問題です。

したがって「WordPress本体と全プラグインを最新版にしたので安全」とは判断できません。必要なのはPHPランタイム自体の修正です。

Nginx + PHP-FPMでは少し事情が違う可能性がある

防御の観点で興味深い点があります。

PHP公式マニュアルはSession Upload Progressについて、Webサーバー側でリクエストがバッファリングされていると、PHPはアップロード完了後に初めてリクエスト全体を見ることになるため、進捗機能が正常に働かない場合があると説明しています。特にNginxは大きなリクエストをバッファリングすることで知られています。

Nginx公式ドキュメントによれば、次の設定が既定値です。

fastcgi_request_buffering on;

この場合、Nginxはクライアントのリクエストボディをすべて読み込んでからFastCGIサーバーへ渡します。off の場合は、受信しながらPHP-FPMへストリーミングします。

独立研究者のUAFラボでも、時間差を利用したストリーミングをPHP-FPMまで届けるために、明示的に fastcgi_request_buffering off; を使っています。同研究者は on を維持することを多層防御（defense in depth）として挙げています。

したがって、公開されている「一度送り、1秒以上止め、続きを送る」という特定のUAF経路については、Nginxの既定のバッファリングが成立条件を崩す可能性があります。

ただし、これも完全な防御とは見なせません。脆弱性が2件あること、GMO Flatt Securityが session.upload_progress.enabled=0 でも攻撃可能と判断していること、PHP公式がまだ根本原因を開示していないことがその理由です。Nginxのバッファリングは、あくまで特定の公開仮説に対する多層防御として扱うべきです。

今夜23時までに実施する対策

修正版の公開までにやるべきことは、「一つの設定で治す」ことではありません。攻撃面を縮小し、RCEされた場合の被害範囲を小さくし、23時に即座に更新できる状態を作ることです。CERT-EUも、すぐに修正できない場合はインターネットに公開しているアプリケーションを公共ネットワークから隔離することを検討するよう勧告しています。

優先度順に整理します。

1. 最優先：インターネットに公開しているPHPを棚卸しする

まず、インターネットから到達できるPHPを把握します。

Internet
   │
   ├─ WordPress
   ├─ EC / CMS
   ├─ PHP API
   ├─ 社内システムの公開画面
   ├─ phpMyAdmin など
   └─ 製品・アプライアンス内のPHP

IPAも、Webサイトだけでなく、ソフトウェア製品やネットワーク機器の内部にPHPが組み込まれている場合があるとして、把握できる範囲での棚卸しを呼びかけています。

特に確認すべき項目は次のとおりです。

PHPの実際のバージョン
SAPI（FPM / mod_php / CGI など）
Webサーバー（nginx / Apache など）
インターネットから直接到達できるか
リバースプロキシ / CDN / WAF の背後にあるか
オリジンサーバーへ直接アクセスできてしまわないか
multipart / ファイルアップロードを受け付けるか
PHPが持っているDB / IAM / APIの権限

2. session.upload_progress.enabled=0 は実施価値あり。ただしこれで終わりにしない

使っていないのであれば、次の設定は現時点でも合理的な緩和策です。

session.upload_progress.enabled = 0

ただし、前述のとおり完全な対策ではありません。GMO Flatt Securityの14時の更新は「この設定変更だけでは攻撃は依然として可能と見られる。根本的にはパッチが必要」という明確な結論です。

設定するうえでの注意点もあります。

この設定は INI_PERDIR のため、アプリケーション中の ini_set(...) では変更できません。php.ini、.htaccess、httpd.conf、.user.ini などで設定する必要があります。
PHP-FPM / CGIで .user.ini を使う場合、既定で300秒キャッシュされるため、書き換えた直後にすべてのリクエストへ反映されるとは限りません。
CLIのPHPとWebサーバーが別の php.ini を読んでいる構成もあります。CLIで確認しただけで終わらせず、実際のWeb SAPI側で値が0になったことを確認してください。

3. 不要なmultipartアップロードをPHPへ届けない

これは公式の修正ではなく防御上の推論ですが、現在疑われているコード経路はmultipartアップロードの処理です。ファイルアップロードをまったく必要としないWebサービスであれば、リバースプロキシやWAFのレベルで不要なmultipartリクエストをPHPまで渡さないことが、攻撃面の縮小になります。

重要なのは、PHPアプリの中で拒否するのではなく、PHPより手前で止めることです。

Internet
   │
   ▼
WAF / リバースプロキシ
   │
   ├─ 不要な multipart → DROP / 403
   │
   ▼
PHP

Upload Progressの処理はスクリプト実行前に行われるため、Laravelのmiddlewareや WordPressのプラグインなど、PHPコードが動き始めてから拒否しても、疑われている低レイヤーの処理はすでに通過している可能性があります。

もちろん、ECサイトの画像アップロードやCMS、APIなど、multipartを正当に必要とするサービスで一律に遮断すれば障害になります。サービスの要件と照らし合わせて適用すべき緊急措置です。

4. Nginx + PHP-FPMなら、リクエストバッファリングを意図せずOFFにしていないか確認する

Nginxでは fastcgi_request_buffering on; が既定値です。公開されているUAFラボの攻撃条件では off が必要だったため、特に理由なく off にしている環境なら、on に戻すことには多層防御としての意味があります。

ただし繰り返しになりますが、fastcgi_request_buffering on を「php2shell対策済み」の証拠にはしないでください。 2件のうちもう一方がこの条件を必要とする保証はなく、PHP公式もまだ攻撃条件を公開していません。

5. 外部公開を一時的に止められる重要システムは隔離を検討する

CERT-EUは、すぐに修正できない場合について「インターネットに公開しているアプリケーションを公共ネットワークから隔離することを検討する」と明示しています。

重要な管理画面や社内向けPHPシステムがインターネットから直接到達できるなら、一時的に次のように変更することは、未知の認証前RCEに対して非常に強い緩和策になります。

変更前： Internet → PHP

変更後： Internet ×
                  │
          VPN / ZTNA / IP許可リスト
                  │
                  ▼
                 PHP

6. PHPプロセスの権限を減らす

パッチ適用前は「侵入されない」と断言できないため、侵入された後に何を取られるかも減らしておくべきです。GMO Flatt Securityが特に挙げているのは次の4点です。

サーバー内の機密データの最小化
IAMロール / サービスアカウントの権限の最小化
ログの記録と外部への保全
緊急停止・切断手順の確認

たとえばEC2 / ECS / Kubernetes / Compute EngineなどでPHPからクラウドのAPIにアクセスしている場合、Webサーバーの侵害がそのまま広いクラウド権限につながらないよう、今のうちに不要な権限を外しておく価値があります。

検知とインシデント対応で見るべきポイント

現在、PHP Security Teamから正式なIoC（侵害の痕跡）は公開されていません。IPAも18時時点では実際の悪用を確認していません。以下はphp2shellの確定IoCではなく、公開されている攻撃仮説から導ける暫定的な監視項目として扱ってください。

Web / リバースプロキシのログ

公開研究で疑われている経路ではmultipartのPOSTとUpload Progressが重要なので、WAFやリバースプロキシでボディのメタデータまで取得できる場合は、次の項目を調査候補にできます。

multipart/form-data
PHP_SESSION_UPLOAD_PROGRESS
異常に長時間続くアップロード
繰り返される大きなmultipartリクエスト
通常はアップロードを受け付けないURLへのmultipart POST

ただし、PHP_SESSION_UPLOAD_PROGRESS という文字列はPHP公式仕様の既定名で、正規のUpload Progress実装でも使われます。この文字列があるだけでは攻撃とは判定できません。

PHP-FPM / Apache / OSのログ

メモリ破壊が失敗した場合、RCEではなくワーカーのクラッシュなどになる可能性もあります。

PHP-FPMワーカーの異常終了
Apacheの子プロセスのクラッシュ
segfault
core dump
異常なワーカーの再生成

ただし、公開PoCの一つは「UAFに到達するがクラッシュはしない」と明記しているため、クラッシュがない＝安全、ではありません。

アプリケーションのログだけを信用しない

今回特に重要なのがこの点です。Session Upload ProgressはPHPの仕様上、ユーザーのPHPスクリプトが動く前に処理されます。主要な仮説どおりなら、攻撃がアプリケーションのcontrollerまで届かなくても、低レイヤーで問題が起き得ます。

そのため、WordPressやLaravel、Symfonyのアプリケーションログだけでなく、次のログまで保全しておく方が妥当です。

CDN
WAF
ロードバランサー
Nginx / Apache
PHP-FPM
OSの監査ログ / システムログ
EDR
クラウドの監査ログ

RCEの疑いが出た場合は、PHPを更新してサービスを戻すだけでは不十分です。PHPの実行ユーザーから読めた秘密情報、DBのパスワード、APIキー、クラウドの資格情報などが盗まれている可能性を考え、ログの保全と資格情報のローテーションを含む、通常のサーバー侵害対応として扱うのが安全です。

23時のパッチ公開後に必ず確認すべきこと

23時のPHP公式発表で、今回の評価はかなり具体的になるはずです。見るべきなのは、新しいバージョン番号だけではありません。

CVE-2026-109618とCVE-2026-109619が、それぞれ何のバグなのか。 公開されているSession Upload ProgressのUse-After-Freeがどちらに対応するのか、もう一件は何なのか、同じサブシステムの別の欠陥なのか。ここが最大のポイントです。
影響バージョン（affected versions）。 「PHP 5以降」という現在の情報は、CERT-EUが外部情報から引用したもので、PHP Security Teamの正式な判定ではありません。
修正版（fixed versions）と各OSベンダーのパッケージ。 調査時点の公式最新版は8.5.11 / 8.4.26 / 8.3.35 / 8.2.34ですが、これらを「修正版」と誤解しないようにしてください。
PHP公式から回避策が示されるか。 特に session.upload_progress.enabled = 0 が、どちらか一方のCVEを完全に無効化するのか、攻撃の成功率を下げるだけなのか、まったく別の経路があるのか。
サポート外のPHPの扱い。 EOL版を使っている場合は、PHP本家の修正版がない前提で、OSベンダーのバックポートの有無、またはサポート版への更新を確認する必要があります。

総合評価

今回の情報を、信頼度ごとに整理します。

確実に言えることは、PHP本体にCritical 9.2の脆弱性が2件あり、PHP Security Team自身が異例の事前通知を出して、すべてのPHPユーザーに緊急更新の準備を求めていることです。23時までは影響バージョンと修正版を意図的に伏せています。

かなり有力な技術像としては、少なくとも一つの攻撃経路が、PHPコアのSession Upload Progress / multipartアップロード / セッション管理に関係するメモリ破壊、具体的にはUse-After-Freeである、というものです。公開されている独立ラボには脆弱なコード経路の再現があり、別の研究者のデモにはメモリアドレスの漏えいから www-data でのコード実行までを主張する結果があります。

まだ断定してはいけないことは、2件とも同じUAFなのか、本当にPHP 5以降すべてが影響するのか、どの構成なら影響を受けないのか、session.upload_progress.enabled=0 がどの程度防げるのか、という部分です。特にSession Upload ProgressはPHP 5.4からの機能で、CERT-EUが引用する「PHP 5以降」という範囲とは完全には一致しません。

そして、いま一番危険な判断は「Upload ProgressをOFFにしたので対応完了」とすることです。GMO Flatt Securityはすでにその見方を撤回し、OFFは緩和策にすぎず攻撃自体は依然として可能だと判断しています。

現時点でもっとも堅実な防御の流れは次のとおりです。

PHPの公開資産を棚卸しする
不要な外部からの到達性やmultipartを、PHPの手前で減らす
Session Upload Progressを、不要ならOFFにする
Nginx + FPMなら、バッファリングの設定を確認する
PHPプロセスのIAM・秘密情報・ネットワーク権限を最小化する
ログを外部に保全する
23:00のPHP公式の修正版を最優先で適用する

単一の暫定設定に賭けるより、PHP公式、IPA、CERT-EU、GMO Flatt Securityの現時点の情報を総合した、もっとも安全側の対応です。

この件で特に大切なのは、「アプリケーションにアップロード機能があるかどうか」だけで判断しないことです。PHPの仕様上、Session Upload Progress自体がPHPスクリプトの実行前に動き、しかも既定でONだからです。今回の独立研究がPHP公式の脆弱性と一致することが23時に確認されれば、これは「WordPressの脆弱性」ではなく、Webアプリより下にあるPHPランタイム層の、アプリケーション実行前のメモリ破壊／RCEと理解するのがもっとも適切です。

今から100分後に修正パッチが公開ということで、実際はどうだったのかを確認をしていきましょう。

Yamamoto Yuya

プロフェッショナルとしての高いスキルと知識を持ち、誠実さと責任感を大切にする。常に向上心を持ち、新たな挑戦にも積極的に取り組む努力家。

PHP緊急脆弱性「php2shell」深掘り調査｜CVE-2026-109618 / CVE-2026-109619 修正版公開前にわかっていること

この記事で参照した主な情報源

現時点の結論

「Session Upload ProgressをOFFにすれば解決」ではない

現状の整理（10月21日18時時点）

確定情報と、海外情報から見える全体像

PHP Security Teamの事前通知

CERT-EUとIPAの見解

「PHP 5以降」という範囲との食い違い

技術的に何が起きていると考えられるのか

Session Upload Progressとは

アプリケーションより「前」に動く

Use-After-Freeとは

UAFがRCEになるまで

RCEが成立すると何が起きるか

どの環境が危ないのか

「PHP 8.xだから安全」「最新版だから安全」とは言えない

サポート終了（EOL）系列は特に深刻

WordPress・Laravel・Symfonyだから危ない、という意味ではない

Nginx + PHP-FPMでは少し事情が違う可能性がある

今夜23時までに実施する対策

1. 最優先：インターネットに公開しているPHPを棚卸しする

2. session.upload_progress.enabled=0 は実施価値あり。ただしこれで終わりにしない

3. 不要なmultipartアップロードをPHPへ届けない

4. Nginx + PHP-FPMなら、リクエストバッファリングを意図せずOFFにしていないか確認する

5. 外部公開を一時的に止められる重要システムは隔離を検討する

6. PHPプロセスの権限を減らす

検知とインシデント対応で見るべきポイント

Web / リバースプロキシのログ

PHP-FPM / Apache / OSのログ

アプリケーションのログだけを信用しない

23時のパッチ公開後に必ず確認すべきこと

総合評価

KEYWORD

TAG

RECENT

PHP緊急脆弱性「php2shell」深掘り調査｜CVE-2026-109618 / CVE-2026-109619 修正版公開前にわかっていること

個人情報はなぜ流出するのか｜言語・フレームワークを問わない攻撃の仕組みと対策

画像のメタデータとAI電子透かしは別物｜メタデータを消すWordPressプラグインを作ってわかったこと

日本酒・地方ブランド牛・アパレルに共通するブランドの育て方｜研究と事例から導く8ステップのアクションプラン

札幌オータムフェスにてマーケティング実践を行いました｜5時間で450杯、来場者と来店の比率を実測

BLOG 事業グロースに関連するブログ

個人情報はなぜ流出するのか｜言語・フレームワークを問わない攻撃の仕組みと対策

乱雑なオブジェクトデータを数学する｜オントロジーと圏論による「意味構造」の統合を、Bedrock と Knowledge Bases で最小実装する

サーバーは「選ぶ」から「作る」へ｜AIと作った自作Webサーバー FIELD-WS 0.1 を公開します

RELATED BUSINESS 関連する事業