CVE-2026-109618 · GHSA-w8hw-w9fx-j79w

CVE-2026-109618: メモリ枯渇（OOM）時の破損による RCE

PHP2Shell の「メモリ枯渇」側：攻撃者がリクエスト解析中の PHP をメモリ枯渇に追い込むと、初期化途中のデータが残り、PHP は後でそれを信用してしまいます。その結果、認証なしで Web サーバーユーザーとしてコードが実行されます。

最終確認 2026-10-22

深刻度

Critical · CVSS 4.0 9.2

認証

不要

修正版

8.5.12 · 8.4.27 · 8.3.36 · 8.2.35

所属

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

概要

PHP はメモリが枯渇すると longjmp() で現在のコンテキストを中断します。それがリクエスト用メモリの初期化途中に起きると、後のリクエスト終了処理で無効なデータを読んだり、それに基づいて分岐したりします。複数の multipart 解析経路で、通常の制限内でも PHP を OOM に追い込めます。しかもアプリケーションコードが動く前の段階です。

影響： 認証なしで、PHP の Web ワーカーユーザーとしてコードを実行できます。 実証： WordPress、Drupal、Joomla（mod_php、デフォルト制限）で認証前 RCE を実証。

原因

PHP はメモリが足りなくなると致命的エラーを発生させ、longjmp() で現在のコードパスから抜け出します。その瞬間に作りかけだったものは、作りかけのまま残ります。

リクエスト用メモリが確保済みでまだ初期化されていなかった場合、リクエストの終了処理が後でその無効なデータを読んだり、それに基づいて分岐したりします。multipart（ファイルアップロードフォーム）の解析経路の複数が、通常の制限内で PHP をメモリ枯渇に追い込めます。そのためアプリケーションコードが関与する必要はありません。

PHP が挙げる弱点：use-after-free（CWE-416）、例外的な状況の不適切な処理（CWE-755）、未初期化ポインタへのアクセス（CWE-824）、および状態管理に関連する CWE。

既知の攻撃経路

アップロード進捗のアンシリアライザにおける use-after-free

アップロード進捗の処理は、リクエストの初期化が終わる前にセッションデータをデコードします。メモリ確保に失敗するとリクエストのヒープは解放されますが、アンシリアライザのグローバルな管理情報は残ったままになります。同じワーカーの次のリクエストは、攻撃者が再利用したメモリを有効な状態として扱います。

PHPSESSID 経由のリモートメモリ漏えい

OOM による中断の後、セッション ID のポインタが宙に浮いた状態になります。その後の multipart リクエストが、ポインタが今指しているメモリを URL エンコードしてレスポンスの PHPSESSID Cookie に書き込みます——アプリがセッションを開始していなくても起こります。

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すべて修正なし

サーバー構成別の影響

構成…109618補足
Apache + mod_phpRCE 確認済み両 CVE ともデフォルト制限で RCE まで確認済み。最もリスクの高い構成です。
PHP-FPM（nginx、Apache、Caddy など）影響ありセッションのライフサイクル経由の 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 は次の部分的な対策を挙げています：

  • アプリケーションから上書きできない方法で memory_limit = -1 を設定（FPM プールや Apache 設定の php_admin_value）し、コンテナまたは cgroup のメモリ上限と組み合わせる。
  • post_max_size を低く：ファイルアップロードなしなら 8M、ありなら 32M。upload_max_filesize はそれより小さく。
  • Web サーバーやプロキシでリクエストの上限を強制：デコード後のサイズ、項目数、multipart のパート数、ヘッダー数、ネストの深さ。
  • RLIMIT_AS / RLIMIT_DATA（ulimit -v、systemd の LimitAS=）は使わない——同じ脆弱なメモリ確保失敗を引き起こします。

参考情報

よくある質問

CVE-2026-109618 はログインなしで悪用できますか？+

できます。PHP が受信したリクエストを解析している段階で到達するため、アプリケーションコード、ルーティング、認証のいずれよりも前です。

session.upload_progress を無効にすれば CVE-2026-109618 は直りますか？+

いいえ。その設定は CVE-2026-109619 の確認済み経路が対象です。CVE-2026-109618 に対する主要な設定上の対策は、管理者レベルで設定した memory_limit = -1 と cgroup のメモリ上限の組み合わせですが、それでも完全ではありません。

CVE-2026-109618 を修正したバージョンは？+

2026 年 10 月 21 日公開の PHP 8.5.12、8.4.27、8.3.36、8.2.35 です。7.4、8.0、8.1 にはソースのバックポートがあり、各ディストリは独自の修正済みパッケージを提供しています。

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

アドバイザリはソース解析に基づき FPM を影響ありと評価しており、PHP Foundation はアプリケーション層のコードパス経由で FPM 上の RCE が確認されたとしています。最も直接的に実証されたのは、デフォルト制限の Apache + mod_php です。

関連ページ