PHPプロジェクトは、メモリ不足（OOM）時に発生する重大なメモリ破壊の脆弱性（CVE-2026-109618）を修正しました。この脆弱性を突かれると、認証されていないリモートの攻撃者に、脆弱なWebサーバー上でコードを実行されるおそれがあります。
セキュリティアドバイザリ「GHSA-w8hw-w9fx-j79w」は2026年10月21日に公開されました。CVSS v4では9.2（Critical）と評価されています。
GitHubで公開されたセキュリティアドバイザリによると、PHPはメモリ不足に陥ると、longjmp()で現在のコンテキストを抜け出してリクエストを中断します。ただし、コンテキストによっては、リクエスト用メモリが完全に初期化される前に参照可能な状態になっています。
この段階でメモリ割り当てが失敗すると、PHPは早期終了を考慮せず、リクエスト用メモリを不正な状態のまま放置します。失敗した割り当てが、破損したメモリと関係している必要はありません。
その後のリクエスト終了処理がこの不正な状態を読み取ったり、それに基づいて分岐したりします。アドバイザリによると、複数のOOM誘発手法でこの状態を確実に引き起こすことができ、リモートコード実行につながります。
対象となる脆弱性の種類（CWE）は、CWE-416（解放後メモリの使用）、CWE-755、CWE-824（未初期化ポインタ）、CWE-1325、CWE-1419です。
アドバイザリは、PHPの制限を守っているように見えながら、リクエストをOOMに追い込むマルチパート解析の問題を複数挙げています。まず、有効なコンテンツ長が宣言されていないマルチパートリクエストは、最初のpost_max_sizeチェックをすり抜け、デコード済みのボディデータを送り続けられます。
また、マルチパートの各パートには無制限の数のヘッダーを付けられます。ヘッダーはメモリ上では通信時のサイズよりはるかに大きくなるため、post_max_size以内のリクエストでもmemory_limitを使い果たせます。
さらに、空のファイルコントロールはmax_file_uploadsにカウントされないものの、ファイルのメタデータ配列は作成されます。フィールド名を入れ子にすると、この処理が増幅されます。アプリケーション固有の入力が大規模な割り当てや繰り返しの割り当てを引き起こし、OOMに達する場合もあります。
最も影響を受けやすいのはApacheのmod_phpです。mod_phpは起動に失敗しても必ずリクエスト終了処理を実行します。そのため、アプリケーションコードが動く前にボディの解析でメモリを使い果たし、不正な状態を残すことが可能です。
研究者らは、デフォルトの入力制限とメモリ制限、標準的なpreforkの構成のmod_phpに対し、HTTP経由で認証なしのRCEが完全に成立することを確認しました。ワーカーの追加や無関係なトラフィックは、必要な試行回数を増やすだけです。
FPMは起動に失敗すると子プロセスを終了するため、起動時の経路は塞がれます。ただし、通常の起動後にOOMが発生する可能性は残ります。影響は、Webワーカーのアカウント権限でのコード実行です。成功率はPHPのビルド、拡張機能、フロントエンドの挙動、アロケータのレイアウトによって異なります。
CVSS v4のベクターは、AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:Hです。ネットワークから到達可能で、権限も利用者の操作も不要ですが、攻撃の複雑さは高いことを意味します。github
パッチはOOM時のlongjmp()を廃止しました。代わりに、次のVMセーフポイントで実行する遅延型のソフトOOMによる正常終了を追加しています。使用量が2つ目のより高いしきい値に達した場合は、_exit()による即時のハードOOMで終了します。これにより、終了処理が不正な状態を参照することはなくなります。
完全な対策はアップデートのみです。まだ更新できないサーバー向けに、アドバイザリは暫定策を挙げています。memory_limit=-1の強制、全ワーカーの再起動、プール・ディレクトリ・アプリケーションの設定で有限の制限値が復活していないかの確認などです。ただし、mmap()の失敗によってlongjmp()が呼ばれる可能性は残るため、完全な対策ではありません。
管理者は、post_max_sizeを控えめな値に保ち、デコード後のリクエストサイズをフロントエンドで制限してください。あわせて、max_input_nesting_levelを下げ、入力変数、マルチパートのパート数、パートごとのヘッダー数、アップロード数に上限を設けることも必要です。
アプリケーションがマルチパートリクエストを使わないなら、フロントエンドでブロックすることも有効です。RLIMIT_ASやRLIMIT_DATAは、mmap()を失敗させて脆弱な経路を誘発するため、使用を避けてください。また、コンテナやcgroupのmemory.max制限は部分的な代替策にすぎません。cgroupが強制終了されると、マスタープロセスと全ワーカーが停止するおそれがあるためです。
管理者は、関連するアドバイザリGHSA-6wmf-4rv5-p3rpの対処方法にも従ってください。このアドバイザリには、4人の報告者と4人の修正担当開発者の名前が記載されています。
