2026-10-21 の PHP 緊急セキュリティリリース：認証なしで遠隔コード実行に至る 2 件の脆弱性

文書: life / research / technology / 2026-10-22 ｜ 対象: PHP 8.5.12・8.4.27・8.3.36・8.2.35（と 8.6.0 RC4） ｜ 一次情報の確認: 2026-10-22 08:15〜08:20 JST（php.net、GitHub php/php-src のセキュリティ勧告、CVE.org API、NVD API、CISA KEV フィード）

shika さんの依頼は「10/21 に修正パッチが公開された PHP の脆弱性が、どういうものだったか」です。php.net の告知では、2026-10-21（14:00 UTC、日本時間 21 日 23:00）に、サポート中の 4 系統すべてに対する修正版が出ています。直す脆弱性は 2 件で、どちらも「認証なしで、Web サーバーの PHP プロセス権限で任意のコードを実行されうる」という最も重い部類です。日付は依頼と一致しています。

どのリリースか（日付の確認）

出典: php.net: Security advisory（2026-10-21）、php.net: Upcoming Critical PHP Security Release（2026-10-20）、php.net トップのニュース欄（いずれも 2026-10-22 08:15 JST に取得）

脆弱性 1：メモリ不足時の処理で内部状態が壊れる（CVE-2026-109618）

何が起きるか

PHP は、メモリ上限（memory_limit）に達するとその場で処理を打ち切ります。この打ち切りは C 言語の longjmp() で途中の処理を飛び越える方式で、確保途中・初期化途中のデータが「途中のまま」残ることがあります。その後、リクエストの後片付けがそのデータを読んだり、その値で分岐したりするため、メモリが壊れます。メモリ不足を起こしたきっかけの確保と、壊れるデータは無関係でよいのが厄介な点です。

攻撃者は「わざとメモリ不足を起こす」ことができます。勧告が挙げる方法は、multipart/form-data（ファイルアップロードのフォーム形式）の解析の性質を使うもので、Content-Length が無いリクエスト、パートごとのヘッダー数に上限が無いこと、空のファイル欄が max_file_uploads に数えられないこと、などにより、見かけ上は制限内のリクエストでメモリ上限に達するとされています。アプリ固有の重い処理でも起こせます。

実行環境（SAPI）ごとの影響

どう直したか

メモリ不足時の longjmp() をやめ、次の安全な地点で穏やかに止める「ソフトなメモリ不足」と、さらに高い閾値で プロセスを即終了（_exit()）する「ハードなメモリ不足」の 2 段にしています。挙動の変化なので、メモリ上限ぎりぎりで動いている処理は、更新後に止まり方が変わる可能性があります（勧告からの推論。実測は未確認）。

出典: GitHub: GHSA-w8hw-w9fx-j79w（2026-10-22 08:30 JST 再取得）

補足：GC があるのに、なぜ防げないのか

PHP にも GC はあります（変数の値は参照カウントで管理し、循環参照は循環回収で拾う。リクエスト中のメモリはリクエストの終わりにまとめて捨てる）。ただし GC が扱うのは「もう使われていない値を、いつ解放するか」です。今回は「解放していないのに中身が半端」「解放済みなのに参照が残っている」という状態の食い違いで、GC は書かれている情報を正しいと信じて動きます。壊れた状態を渡されると、むしろそれをたどって被害を広げる側に回ります。そもそも壊れるのは Zend エンジンの C 言語レベルの内部データで、GC の管轄外です。

食い違いのイメージ（実際のコードではなく例え）：①配列を作る → ②「要素は 3 個」と件数を書き込む → ③要素を入れる場所を確保しようとして上限を超え、longjmp() で脱出 → ④後片付けが「3 個あるはず」と、設定されていないポインタを 3 回解放しにいく。

補足：内部状態の食い違いが、なぜ遠隔コード実行になるのか

前提：未初期化のメモリは空っぽではない。C で確保したばかりのメモリには、直前にそこを使っていたデータがそのまま残っています。PHP は同じリクエストの中でメモリを使い回すため、攻撃者が送った POST 本文の断片が、ちょうど使い回される場所に残っている状況を作れます。上の例えの「設定されていないポインタ」は、どこでもない値ではなく、攻撃者が仕込んだアドレスになりえます。

そこから乗っ取りまでの一般的な型は次のとおりです。

1. 好きな場所を「解放」させる：後片付けが、攻撃者の仕込んだアドレスを解放します。メモリ管理の側は「そこは空いた」と記録します
2. 大事なデータと重ねる：次の確保でその場所が渡され、PHP 内部の大事なデータと、攻撃者が中身を書ける文字列などが同じ場所に重なります
3. 関数ポインタを書き換える：PHP の内部データには「この操作ではこの関数を呼べ」という関数のアドレスを持つものがあります。重なった場所への書き込みで、それを system() のような関数に差し替えます
4. PHP が自分で呼ぶ：後片付けなどでその関数ポインタが呼ばれると、攻撃者の選んだ処理が、攻撃者の選んだ引数で実行されます。これが遠隔コード実行です

ひとことで言うと「解放したと嘘をつかせる → 空いた場所を二重に使わせる → 呼び出し先のアドレスを書き換える」です。コードを送り込む必要はなく、PHP が元々持っている関数を、間違った引数で呼ばせるだけで足ります。解放後使用（CWE-416）からコード実行に至る、よく知られた型です。

それでも「攻撃条件が複雑」と評価されている理由（推測）：PHP 側の評価は AC:H（攻撃条件が複雑）・AT:P（前提条件あり）です。理由は勧告に書かれていませんが、関数のアドレスは ASLR（起動ごとのアドレスのランダム化）で毎回変わるため、知るか当てる必要があるからだと考えられます。一方、勧告が検証に使った「prefork の mod_php」は、同じ親プロセスから複製したワーカーが親と同じアドレス配置を引き継ぎます。失敗してワーカーが落ちても同じ配置で何度でもやり直せるので、総当たりが現実的になる構成です（ここも一般的な仕組みからの推測）。

出典: GitHub: GHSA-w8hw-w9fx-j79w、CVE.org レコード（API）、NVD: CVE-2026-109618（2026-10-22 08:16 JST 取得）

脆弱性 2：前のリクエストの状態が、解放後も残る（CVE-2026-109619）

何が起きるか

PHP-FPM や mod_php のワーカーは、1 つのプロセスで多数のリクエストを順に処理します。PHP には「今のリクエストのメモリを指しているグローバルな状態」があり、本来はリクエストのメモリを解放する前にリセットされます。ところが、

1. 仕込み役のリクエスト：致命的エラー（メモリ不足や Maximum execution time exceeded を含む）でリセット前に中断される、または終了処理中に警告が出て状態が詰め直される → 解放済みメモリを指す状態がプロセスに残る
2. 発火役のリクエスト：同じワーカーが次に処理するリクエストで、通常の初期化がリセットするより前にその状態が使われる → 解放済みメモリの使用

同じワーカーに当たる必要があるため、ワーカー数が多い・定期的に入れ替わる構成では成功率は下がりますが、無くなりはしないと勧告は書いています。

確認された「発火役」の経路

• セッションのアップロード進捗（session.upload_progress）：標準で有効。通常のセッション初期化より前に、残ったセッション状態に触れる。mod_php と PHP-FPM の両方で遠隔コード実行を検証済み
• リクエスト初期化前の INI 設定の警告：リクエストごとに適用される設定（mod_php のディレクトリ単位の php_value・.htaccess、FPM なら前段から送る PHP_VALUE）が警告・非推奨通知を出すと発火する。error_reporting を下げても、@ を付けても、表示やログを切っても防げない
• PHP 8.5 の fatal_error_backtraces：最も強く確認された経路として、mod_php での遠隔コード実行が示されている

実行環境別では、mod_php が確認済み、PHP-FPM は前段から PHP_VALUE を送る構成で条件付き（プール設定や .user.ini は同じ早さで効かない）、セッション経路は FPM でも検証済み、LiteSpeed は条件付きの候補、FrankenPHP は標準構成では早期の発火経路が見つかっていない、とされています。遠隔コード実行にはヒープの配置を狙って整える必要があります。

出典: GitHub: GHSA-6wmf-4rv5-p3rp、CVE.org レコード（API）、NVD: CVE-2026-109619（2026-10-22 08:16 JST 取得）

深刻度（出典ごと）

差の理由：PHP 側は「攻撃の複雑さ：高い（AC:H）」「攻撃に前提条件あり（AT:P）」としています（メモリ配置やワーカーの一致に左右されるため）。NVD は v3.1 で「複雑さ：低い（AC:L）」と付けています。どちらでも Critical で、ネットワーク越し・認証なし・利用者の操作なし、の 3 点は一致しています。

悪用の状況：CISA の「既知の悪用済み脆弱性（KEV）」には 2026-10-22 08:16 JST の時点で載っていません（KEV の JSON フィードを取得して確認、NVD レコードにも KEV の記載なし）。実際の攻撃が観測されたかどうかは、一次情報では未確認です。ただし事前予告には「詳細が漏れたり悪用が見つかったら前倒しする」とあり、当日出ているので、少なくとも予告時点で前倒しの理由は無かったと読めます（推論）。

出典: NVD API（CVE-2026-109618）、NVD API（CVE-2026-109619）、CISA KEV（2026-10-22 08:16 JST 取得）

影響する版と修正版

CVE レコードと GitHub 勧告の「影響する版」は 8.2〜8.5 の 4 系統だけで、8.1 以前が影響を受けるかは明記されていません。ただし 7.4〜8.1 向けにパッチを用意している以上、古い版も影響を受ける前提で扱うべきです（推論）。

配布元について、告知は次も書いています。

• Linux ディストリと延長サポート業者には事前にパッチが渡っているので、各配布元の更新パッケージを確認する
• 有志運営の rpms.remirepo.net（Remi リポジトリ）は当日は更新が出ない。ディストリのパッケージに切り替えるか、ソースからビルドすることを勧める

出典: php.net: Security advisory、php.net: ChangeLog 8、各 GHSA の Affected / Patched versions（2026-10-22 08:15〜08:17 JST 取得）

すぐ更新できないときの回避策（どれも完全ではない）

メモリ不足の脆弱性（CVE-2026-109618）に対して

• memory_limit=-1（上限なし）にし、アプリが上書きできない方法（FPM プールや Apache 設定の php_admin_value）で固定する。プール・ディレクトリ・アプリのどこかで有限の値に戻されていないか確認する。これでも OS 側のメモリ確保失敗からは到達しうる
• post_max_size を低くする。アップロード不要なら 8M、必要なら 32M。upload_max_filesize はそれより小さく
• Web サーバー／プロキシ側で、展開後の本文サイズ・入力欄の数・multipart のパート数・ヘッダー数・入れ子の深さを制限する。Content-Length の無いリクエストにも効くようにする
• アプリが multipart を使わないなら、前段で multipart のリクエストを遮断する
• コンテナや cgroup のメモリ上限を「可用性の境界」として使う（そのワーカーだけ落ちる方針が望ましい）。RLIMIT_AS・RLIMIT_DATA は逆効果（確保失敗を起こして脆弱な経路に入る）

前リクエストの状態が残る脆弱性（CVE-2026-109619）に対して

• session.upload_progress.enabled=0 にして全ワーカーを再起動。php.ini・FPM プール・サーバー設定など、リクエスト解析より前に効く場所で。ini_set() や FPM の .user.ini では効かない。確認済みのセッション経路は塞げるが、他の変種は塞げない。勧告は不要なら更新後も切っておくことを勧めている
• PHP 8.5 なら fatal_error_backtraces=0 にして全ワーカーを再起動
• リクエストごとに適用している設定のうち、無効・非推奨で警告を出すものを取り除く（警告を隠しても効かない）
• 攻撃者が起こせる致命的エラーと実行時間切れを潰す（コールバック、アップロードや取り込み処理、後片付けを含む）。予測できるタイムアウトを避ける
• pm.max_requests=1（1 リクエストごとにワーカーを入れ替える）も検討に挙がっている。性能は大きく落ちる（一般論、未計測）
• E_ALL でログを監査する。ただしログだけでは安全の証明にならない

出典: php.net: Security advisory、GHSA-w8hw-w9fx-j79w、GHSA-6wmf-4rv5-p3rp

所見：Web アプリ開発者として、どれくらい気にすべきか

• 「自分のアプリにその機能が無いから大丈夫」が通用しない種類です。脆弱性 1 は POST 本文の自動解析、脆弱性 2 は標準で有効なセッションのアップロード進捗という、PHP 本体が全リクエストに対して勝手にやる処理が入口です。WordPress・Laravel・自作のどれでも、PHP を Web で動かしていれば対象と考えるのが妥当です。WordPress 本体やプラグインの更新では直りません。
• 優先度が最も高いのは mod_php 構成（古めのレンタルサーバー、Apache＋mod_php の自前 VPS、昔ながらの Docker イメージ php:*-apache など）。勧告で唯一「アプリのコードより前に、認証なしで RCE」が実証された構成です。php:*-apache イメージが mod_php であることは私の記憶で、一次情報では未確認です。
• PHP-FPM（nginx＋FPM、多くのマネージド環境）も安全ではありません。脆弱性 2 のセッション経路は FPM でも RCE が検証済みです。ただし同じワーカーに 2 回当てる必要があるので、ワーカー数が多い大規模環境ほど成功率は下がります（それでも「下がる」だけ）。
• PHP 8.1 以前のまま残っている案件が一番危ない。公式の修正版が出ません。過去の受託案件や、更新が止まった WordPress サイトがあれば、ホスティング会社の対応状況を確認するか、8.2 以上へ上げる判断が要ります。8.2 も 2026-12-31 で終わるので、上げるなら 8.3 以上が無難です。
• レンタルサーバー・マネージド環境では、自分で PHP を更新できないことが多いので、事業者の告知を確認するのが実務です。確認は phpinfo() や管理画面の PHP 版表示で、8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 以上か、あるいはディストリのパッケージなら配布元のセキュリティ告知で CVE-2026-109618/109619 の修正済み版か、を見ます（ディストリ版は版番号が上流と一致しないため）。
• 更新後の確認：メモリ不足時の止まり方が変わる修正なので、メモリ上限ぎりぎりの重いバッチや画像処理がある案件は、更新後に一度動かして挙動を見ておくと安心です。
• すぐ上げられない間は、効果と副作用のバランスから、session.upload_progress.enabled=0（ほぼ誰も使っていない機能）と、post_max_size を現実的な値まで下げる、の 2 つが手を付けやすいと考えます。memory_limit=-1 は別の資源枯渇の危険を増やすので、コンテナのメモリ上限とセットでのみ。
• 攻撃コードの公開状況・実際の悪用は 2026-10-22 08:16 JST の時点で一次情報からは確認できていません（KEV 未掲載）。ただ、詳細な技術情報が勧告に出ているので、「様子見」ではなく今週中の更新を勧めます。

参考：直前の 2026-09-24 のセキュリティリリース

依頼の対象ではありませんが、日付を取り違えていないかの確認として。1 つ前のセキュリティリリース（8.5.11・8.4.26・8.3.35・8.2.34、2026-09-24）は、FPM の IPv6 アクセス制御のすり抜け（CVE-2026-91768）、OpenSSL の証明書ホスト名検証の不備（CVE-2026-91769、CVE-2026-91767）、Phar の整数オーバーフロー（CVE-2026-6103）、SOAP、mysqlnd などを直したもので、今回とは別物です（ChangeLog 8 で確認。内容の詳細は未調査）。

life / research / technology / 2026-10-22_php-security-release-2026-10-21.html