CVE-2026-109619 · GHSA-6wmf-4rv5-p3rp

CVE-2026-109619: リクエストをまたいで残るグローバル状態による RCE

PHP2Shell の「リクエストをまたぐ」側：致命的エラーの後、PHP はすでに解放したメモリを指すグローバルポインタを残します。同じワーカーの次のリクエストがそれを使い、メモリが漏れたり、攻撃者がコードを実行できたりします。

最終確認 2026-10-22

深刻度

Critical · CVSS 4.0 9.2

認証

不要

修正版

8.5.12 · 8.4.27 · 8.3.36 · 8.2.35

所属

PHP2Shell（CVE-2026-109618 とともに）

概要

致命的エラー（OOM を含む）によってリクエストごとのリセットが飛ばされ、エラー・セッション・オブジェクト・拡張機能のグローバル状態が、リクエスト終了時に解放されたメモリを指したままになることがあります。同じワーカーの次のリクエストが、通常の初期化より前にその解放済みメモリを使ってしまいます。

影響： use-after-free により、ワーカーのメモリ漏えいやコード実行につながります。 実証： WordPress と Drupal で認証前 RCE を実証。アプリケーションに依存しないリモートのメモリ漏えいも実証。

原因

PHP は状態の一部をリクエスト単位のグローバル変数に保持しています——エラー、セッション、オブジェクト、拡張機能の状態です。通常はリクエストの終わりごとにリセットされます。しかし致命的エラー（メモリ枯渇を含む）でそのリセットが飛ばされることがあり、終了処理中の警告によって、消去後のエラー状態が再び書き込まれることもあります。

それらのグローバル変数が指すメモリは、リクエスト終了時に解放されます。同じワーカーがその後、通常のリクエスト初期化の前にコード（INI の診断処理やセッションのアップロード進捗処理）を実行すると、解放済みのメモリを使ってしまいます。多数のリクエストを連続して処理するワーカー（PHP-FPM、mod_php の子プロセス）があるからこそ、この問題に到達できます。

既知の攻撃経路

致命的エラーのバックトレースにおける use-after-free

EG(last_fatal_error_backtrace) は、リクエストのヒープを破棄する OOM の後も残ります。次のリクエストの初期段階の診断処理が、この宙に浮いたポインタをたどります。最も確実な実証例：fatal_error_backtraces を有効にした PHP 8.5 で、mod_php 上の RCE。

セッションのアップロード進捗のライフサイクル

中断されたリクエストから残ったセッション状態を、次のリクエストのアップロード進捗処理が使ってしまいます。mod_php と PHP-FPM の両方で RCE を確認済み。

OPcache 共有メモリにおける型の取り違え

CG(map_ptr_last) を進めてから共有領域の境界を公開するまでの間にメモリ確保が失敗すると、ワーカー間で認識が食い違うスロットが残り、あるワーカーがそのスロットを別の型のオブジェクトに再利用できてしまいます。

その他のリクエスト単位の状態

オブジェクトや拡張機能の状態は、条件次第で悪用可能とアドバイザリに記載されています。修正はこれらの経路だけでなく、パターン全体を対象としています。

PHP のアドバイザリと Wiz の記事では、一部の経路の分類が異なります。パッチは共通の不具合パターンを修正するため、分類の違いでやるべきことは変わりません。

影響を受けるバージョンと修正版

ブランチ脆弱修正版
8.5< 8.5.128.5.12
8.4< 8.4.278.4.27
8.3< 8.3.368.3.36
8.2< 8.2.358.2.35
8.1 · 8.0 · 7.4すべてソースのバックポートのみ
5.4 – 7.3すべて修正なし

サーバー構成別の影響

構成…109619補足
Apache + mod_phpRCE 確認済み両 CVE ともデフォルト制限で RCE まで確認済み。最もリスクの高い構成です。
PHP-FPM（nginx、Apache、Caddy など）RCE 確認済みセッションのライフサイクル経由の RCE が FPM で確認済み。OOM 経路はアプリケーション層のコードパス経由で確認されていますが、汎用的な FPM 向けエクスプロイトは公開されていません。
FrankenPHP / LiteSpeed LSAPI影響の可能性大アドバイザリでは影響の可能性が高いとされています。常駐ワーカーでは、リクエストをまたいだ残留状態の問題がむしろ大きくなります。
CLI（cron、キューワーカー、artisan）対象外アドバイザリでは扱われておらず、通常の使い方では HTTP リクエストから到達できません。ただし同じパッケージなので、いずれにせよ更新してください。

CVSS 4.0 スコア：9.2

ベクトル： CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

指標この脆弱性での意味スコアへの影響

AV:N

Attack Vector: Network（ネットワーク）

通常の HTTP リクエストでインターネット経由で到達できます。スコアを上げる

AC:H

Attack Complexity: High（高）

標的ごとのメモリ配置に合わせてエクスプロイトを調整する必要があり、リクエスト 1 つをコピーすれば済むものではありません。スコアを下げる

AT:P

Attack Requirements: Present（前提条件あり）

成否は攻撃者が制御できない構成条件（SAPI、メモリ制限、ワーカーの再利用）に左右されます。スコアを下げる

PR:N

Privileges Required: None（不要）

アカウントもログインも不要です。スコアを上げる

UI:N

User Interaction: None（不要）

誰も何もクリックする必要がありません。スコアを上げる

VC:H / VI:H / VA:H

脆弱なシステムへの影響：High（高）

PHP サーバーの機密性・完全性・可用性がすべて失われます。スコアを上げる

SC:N / SI:N / SA:N

後続システムへの影響：None（なし）

他システムへの横展開はスコアに含まれませんが、実際には盗まれた認証情報でそれが可能になることが多いです。スコアを下げる

初期の報道が 10.0 としていた理由 →

修正と暫定対策

修正方法は PHP の更新

修正版をインストールし、すべての PHP ワーカーを再起動してください。修正ガイド →

すぐに更新できない場合、php.net は次の部分的な対策を挙げています：

  • php.ini、FPM プール、サーバー設定のいずれかで session.upload_progress.enabled = 0 を設定し、すべてのワーカーを再起動。詳細 →
  • PHP 8.5：fatal_error_backtraces = 0 を設定して再起動。確認済みのバックトレース経路だけを防ぎます。
  • リクエスト単位で適用され、初期化前に診断メッセージを出す無効・非推奨の設定を取り除く。error_reporting、display_errors、@ で隠しても効果はありません。
  • 攻撃者が引き起こせる致命的エラーや実行タイムアウト（コールバック、アップロード・インポート処理、後片付け）を修正する。
  • 性能が許すなら pm.max_requests = 1 を検討する。

参考情報

よくある質問

CVE-2026-109619 はコードを実行せずにデータを漏らせますか？+

はい。リクエストをまたぐ use-after-free により、攻撃者が一度もコードを実行しないまま、他のユーザーのパスワード、API キー、セッショントークンなどワーカーのメモリが漏れる可能性があり、検知が難しくなります。

session.upload_progress.enabled = 0 で CVE-2026-109619 は直りますか？+

部分的にです。確認済みのセッション経路は防げますが、他の亜種は防げません。また php.ini、FPM プール、サーバー設定で指定し（.user.ini や ini_set() では不可）、すべてのワーカーを再起動した場合にのみ有効です。

PHP-FPM は CVE-2026-109619 の影響を受けますか？+

受けます。セッションのライフサイクルを使った RCE は mod_php と PHP-FPM の両方で確認されています。FPM のワーカーは多数のリクエストを連続して処理するため、まさにリクエストをまたぐ残留状態が成立する条件そのものです。

pm.max_requests を下げると効果がありますか？+

破損した状態が残る時間を短くでき、pm.max_requests = 1 ならワーカーの再利用を完全になくせますが、性能面のコストは大きくなります。1 回のリクエストで済む経路には効果がありません。

関連ページ