PHPのCVE-2026-109618・109619——対象版と今やること

公開日：2026年10月30日文：クリスタルメソッド編集部監修：河合継（代表取締役）

CVE-2026-109618とは何か：確認されたリスクの全容

2026年10月21日、PHP Groupは自身が開発するPHP本体に深刻な脆弱性2件（CVE-2026-109618・CVE-2026-109619）を公開した。両CVEはCVSS 4.0スコア9.2（CRITICAL）と評価され、2026年10月26日には米国サイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）のKnown Exploited Vulnerabilities（KEV）カタログに掲載された。KEV掲載は「実際の攻撃への悪用が確認された」ことを意味する（CISA KEVカタログ）。

本稿が主に扱うCVE-2026-109618の核心は、PHPがメモリ不足（OOM）エラーを処理する際の構造的な欠陥にある。PHPはOOMエラー発生時にlongjmp()で現在のコンテキストから脱出してリクエスト処理を中断するが、リクエストメモリが完全に初期化される前に一時的に到達可能な状態になる一部のコンテキストでこの問題が顕在化する。メモリ割り当てが失敗した時点でPHPは早期終了を正しく処理できず、リクエストメモリを無効な状態のまま残す。その後のリクエストシャットダウン処理がこの無効メモリを読み取るか、それに基づいて分岐する可能性がある。弱点の種類はCWE-416（Use after free）、CWE-824（Access of uninitialized pointer）などとして分類されている（CVE公式記録）。

攻撃者はマルチパートパース処理の複数の問題を組み合わせることで、見かけ上PHPの制限内に収まりながらOOM状態を誘発できる。具体的には、post_max_sizeチェックを通過するリクエスト、ヘッダーのメモリ使用量がワイヤー表現より大きくなる挙動、空のファイルコントロールがmax_file_uploadsに加算されない挙動、ネストしたフィールド名で配列処理が増幅する挙動などが組み合わされる。CVEの公式記録によれば、完全なリモートコード実行が、デフォルトのPHP入力・メモリ制限と通常のprefork構成（複数ワーカー）のApache mod_phpに対してHTTP経由で検証済みとされている。

EPSSスコアは0.999990（パーセンタイル0.999980、2026年10月29日時点）と算出されている。EPSSは統計的な推定であり、特定環境での悪用を確定するものではない（FIRST EPSS）。

CVE-2026-109618における攻撃の流れ。攻撃者が細工したマルチパートリクエストでOOM状態を誘発し、PHPのlongjmp()による早期脱出後に残存した無効メモリをシャットダウン処理が参照することで未認証RCEに至る経路を示す。mod_phpのprefork構成で検証済み。

PHP 脆弱性 CVE-2026-109618が影響するバージョンと実行環境

影響を受けるPHPのバージョンは以下のとおりで、CVE公式記録（採番元CNA：php）に基づく（cve.org）。

PHP 8.2系：8.2.35未満
PHP 8.3系：8.3.36未満
PHP 8.4系：8.4.27未満
PHP 8.5系：8.5.12未満

修正済みバージョンは8.2.35、8.3.36、8.4.27、8.5.12である。なお、ディストリビューションパッケージの修正状況は各ディストリビューションのベンダー告知を参照する必要があり、上流のバージョン番号との直接比較は正確ではない。

実行環境別の影響度は、CVEの説明に基づけば以下のとおり整理される。

CVE-2026-109618・CVE-2026-109619の実行環境別影響度
実行環境	CVE-2026-109618の状況	CVE-2026-109619の状況	備考
Apache mod_php（prefork構成）	完全なRCEが検証済み	悪用が確認済み	最優先で対処が必要
FrankenPHP	高確率で影響（ソース解析上）	既定設定では早期consumerは未確認だが他経路で露出しうる	mod_phpと同様のシャットダウン処理の構造
PHP-FPM	完全なエクスプロイトは未実証。起動後OOM到達時は影響の可能性	nginx/mod_proxy_fcgiがPHP_VALUE等を送る構成では条件付きで露出	起動失敗時は子プロセス終了により一部防御
LSAPI	アプリケーション固有のエクスプロイトは可能性が高いが未検証	特定の環境INI値を早期適用できる場合に条件付きで候補	FPMと同様のモデル

Apache mod_phpはリクエスト起動が失敗した場合でもシャットダウン処理を無条件に呼び出す設計であるため、CVE-2026-109618の影響を最も受けやすい。PHP-FPMはリクエスト起動の失敗時に子プロセスを終了させるため、無効状態の消費を防ぐ側面があるが、正常な起動後にOOMに到達した場合はシャットダウン時に無効状態が処理される可能性があり、ソース解析上は影響ありとされている。

自社が対象か判断がつかない場合は、お使いの製品と版の情報をお送りいただければ、公式情報をもとに対象かどうかの目安をお伝えします（無料相談）。

次に読む：Linuxカーネル Fragnesiaの対処手順は？

CVE-2026-46300 LinuxカーネルFragnesiaがKEVに追加——今すぐ確認すべき対処手順

PHP 脆弱性 CVE-2026-109618への対処：優先順位と具体的な手順

CVEの説明およびベンダー告知は、脆弱性を修正したPHPリリースへの更新が唯一の完全な対策であると明示している。以下は、対処を判断・実行するための実務的な手順である。

ステップ1：影響範囲の特定

自組織で稼働しているPHPのバージョンを洗い出し、上記の影響バージョン（各系統の修正版未満）に該当するものを特定する。インターネットに公開しているサーバーと内部サーバーを区別し、公開サーバーを優先する。実行環境（mod_php、FPM、FrankenPHPなど）も合わせて確認する。

ステップ2：修正版への更新

修正済みバージョン（8.2.35、8.3.36、8.4.27、8.5.12）への更新を実施する。ディストリビューションパッケージを使用している場合は、各ディストリビューションのベンダー告知を確認し、そのパッケージの修正状況に従う。更新後はすべてのPHPワーカーを再起動し、どのプール・ディレクトリ・アプリケーション設定も有限のPHPメモリ制限を復元していないことを確認する。

ステップ3：更新できない環境の暫定措置

何らかの理由で即時更新が困難な場合、CVEの説明ではmemory_limit=-1を管理上設定・強制することが主な設定上の緩和策として挙げられている。ただしこれは完全な対策ではない。mmap()などの割り当て失敗時には依然としてlongjmp()が使われうる。

CVEの説明が示す追加の緩和策（パッチ適用後もハードOOMやDoSリスクを減らすが、更新の代替にはならない）として以下が挙げられている。

post_max_sizeを保守的に設定し、フロントエンドで復号後のリクエストサイズを独立して強制する
max_input_nesting_levelを削減する
入力変数・マルチパートのパート数・パート内ヘッダー数・アップロード数を制限する
アプリケーションがmultipart form dataを使用しない場合は、PHPに到達する前にフロントエンドでそのようなリクエストをブロックする

なお、RLIMIT_ASやRLIMIT_DATAは使用しないよう明示されている。mmap()失敗を招き、脆弱なlongjmp()経路を誘発するためである。コンテナ・cgroupのメモリ制限（memory.max）についても、PHPのmemory_limitの代替になる可能性はあるが制限があり、完全な対策ではないとされている（GitHub Security Advisory GHSA-w8hw-w9fx-j79w）。

CISAの対処要件について

CISAが定めた対処期限（2026年10月29日）は米国連邦機関向けの義務であり、日本企業への法的拘束力はない。ただしKEV掲載は実際の悪用が確認されたことを意味するため、日本の企業・組織においても更新の優先度を高める判断の根拠となる。

CVE-2026-109619との関係：2件の脆弱性を同時に対処する理由

同時公開されたCVE-2026-109619は、CVE-2026-109618と影響バージョン・修正バージョン・CVSSスコア（9.2 CRITICAL）がすべて一致する別の脆弱性である。こちらはPHPのグローバル状態（エラー・セッション・オブジェクト・拡張モジュールなど）の管理における欠陥を突く。あるリクエストが所有するメモリをワーカーが保持し続け、次のリクエストの通常の初期化より前に実行される操作がその古い状態にアクセスすることでuse after freeが発生する。攻撃者がヒープレイアウトを作り込むことで完全なRCEにつながる可能性がある（CVE-2026-109619公式記録）。

mod_phpでの悪用が確認済みであり、CVEの説明では関連するGHSA-6wmf-4rv5-p3rpの対策も併せて実施するよう求めている（GHSA-6wmf-4rv5-p3rp）。2件は修正版が共通のため、いずれか一方だけを対処するという選択肢はなく、8.2.35・8.3.36・8.4.27・8.5.12への更新が両CVEを同時に解消する。

CVE公式記録とCISA KEVには、この2件がAIに関係することを示す記載はない。

Linuxカーネルの脆弱性との連鎖

CISA KEVは、2026年10月28日にKEVへ追加されたLinuxカーネルのCVE-2026-46300について、CVE-2026-109618・CVE-2026-109619と連鎖させることで、PHPのWebシェルを仕込み、rootとしてコマンドを実行できると説明している（CISA KEVカタログ）。PHPを更新しても、同じサーバーのカーネルが未対応なら、この連鎖の片側が残る。カーネル側の影響範囲と対処は、Linuxカーネルの脆弱性CVE-2026-46300（Fragnesia）の解説で整理している。

日本の企業・運用担当者が今押さえるべき判断軸

Apache mod_php構成でPHPを稼働させている企業・組織では、今回のCVEが認証不要（PRなし）・ネットワーク経由（AV:N）での完全なRCEとして実証されていることを踏まえ、外部公開Webサーバーが対象バージョンのmod_phpを使用しているかどうかを確認することが優先される。

内部システム専用であってもPHPを使用するシステムは影響バージョンを確認する価値がある。CISAのKEV掲載は「攻撃に使われたことが確認された」脆弱性を意味する。ただし自社の環境が必ずしも影響を受けるとは限らず、まず実際のバージョンと実行環境を確認することが出発点である。

更新後の確認事項として、CVEの説明はすべてのPHPワーカーの再起動と、プール・ディレクトリ・アプリケーション設定が有限のPHPメモリ制限を復元していないことの検証を求めている。継続的な管理の観点では、PHPの公式セキュリティリリースをモニタリングする体制（例：GitHub Security Advisoriesのウォッチ）を整備することも、再発予防として有効といえる。

平時からPHP環境を守る運用そのものは、PHP脆弱性へのAIセキュリティ対策の実務ガイドが扱っている。