CVE-2026-109618：メモリ不足時の破損による PHP のリモートコード実行

何が起きるのか（ベンダーが公表した範囲で）

Jakub Zelenka は oss-security で、PHP はメモリ不足エラー時に longjmp() でリクエスト処理を中断すること、メモリ確保の失敗が不完全なリクエスト状態に到達可能なまま初期化を中断し得ること、そしてリクエスト終了処理がその無効な状態にアクセスしてリモートコード実行につながり得ることを説明しました。PHP Foundation の説明も同じで、悪いタイミングで memory_limit に達すると、初期化途中の内部データが残り、後で有効なものとして扱われる可能性があるとしています。

本サイトが掲載するのはこの仕組みの説明までです。メモリ確保の失敗を強制する方法は説明しません。

実証されていること

• oss-security：Apache mod_php に対し、アプリケーションコードの実行前に HTTP 経由で認証不要のリモートコード実行が実証されました。ソース分析は FPM も影響を受けることを示していますが、FPM に対する完全なエクスプロイトは実証されていません。
• PHP Foundation：デフォルト設定の Apache mod_php で、アプリケーションコードの実行前に完全なリモートコード実行が実証されました。PHP-FPM でもアプリケーションレベルのコード経路を通じて RCE が確認されたとしています。
• Expel（PHP の説明として）：この CVE の mod_php での実証は、PHP のデフォルトの入力・メモリ制限のままで成功しました。
• トロント大学の勧告は、PHP の見かけ上の制限内に収まる細工した multipart リクエストで攻撃者がこの状態を引き起こせるとしています。本サイトはこれを手順として詳しく説明しません。

影響

悪用に成功した場合、PHP ワーカーの OS アカウント権限で認証不要のリモートコード実行が可能になります。Wiz と Cloudflare はクラッシュとプロセスメモリの漏えいも挙げています。影響範囲はビルド、拡張機能、サーバー構成によって異なり、トロント大学の勧告はエクスプロイトの信頼性はさまざまで、PHP は完全な RCE を検証済みだとしています。確認した情報源に「どこでも動く」という信頼できる主張はなく、それを待ってからパッチを当てる理由もありません。

修正

8.2.35、8.3.36、8.4.27、8.5.12 以降へアップデートし、トラフィックを処理するワーカーを再起動してください。oss-security の投稿は、アップデートが唯一の完全な緩和策だとしています。memory_limit=-1 や小さな post_max_size など PHP が公開した暫定設定は不完全で、制御可能なメモリ制限を外しても、根本的なメモリ確保の失敗が脆弱な経路に到達し得るとしています。Tanium によると NVD のレコードは 2026 年 10 月 21 日に公開され「Undergoing Analysis（分析中）」とされていました。NVD の記載が追いついていない場合は PHP の勧告を運用上の情報源としてください。