【緊急】PHP CVE-2026-109618・CVE-2026-109619：8.5.12／8.4.27／8.3.36／8.2.35へ今すぐ更新（CVSS v4.0 9.2が2件）— 認証なしでリモートコード実行

PHPが、認証なしでリモートコード実行（RCE）につながりうる重大な脆弱性2件を修正しました。CVE-2026-109618とCVE-2026-109619で、どちらもCVSS v4.0で9.2です。修正版はPHP 8.5.12・8.4.27・8.3.36・8.2.35で、公式は「すべてのPHP利用者に、直ちに更新することを強く勧める」と書いています。前の記事（事前予告）の続報です。

対象は、Webリクエストを処理しているすべてのPHP環境です（PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedを含む、と公式）。公式は、mod_phpの危険が最も高いとし、「アプリケーションのコードが動き出す前に、認証なしのリクエストだけで攻撃が成立する」実証済みの攻撃コードがある、と書いています。

まず自分のPHPの版を確認し、修正版へ更新してください。自分で更新できない（ホスティングやマネージドサービス）場合は、事業者の対応状況を確認してください。

このスコアの出どころを明記します。9.2は、採番元（CNA）であるPHPグループが付けたCVSS v4.0の値で、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` です（ネットワーク経由・認証不要・ユーザー操作不要・機密性／完全性／可用性への影響がすべて高い。ただし攻撃の難しさが高く、攻撃に前提条件がある、という評価）。CVE ProgramのCVE記録と、GitHubのアドバイザリで確認しました。NVD（NIST）には、2026年10月21日 14:09 UTC（日本時間23:09）の時点で、まだこの2件の記録がありません（公開直後で、取り込まれていないとみられます。NVD独自のスコアはありません）。弱点の種類は、GitHubのアドバイザリが解放後使用（CWE-416）などを挙げています。

今すぐ行う対策

• ✓★自分のPHPの版を確認する。コマンドラインで `php -v`。Webサーバーが使うPHPは別の版のことがあるため、管理画面やphpinfo()でも確認します（当サイトの補足）
• ✓修正版へ更新する。8.5系は8.5.12、8.4系は8.4.27、8.3系は8.3.36、8.2系は8.2.35です。ソースとWindows版は、php.netのダウンロードページにあります（公式）
• ✓Linuxでは、まずOS・ディストリビューションのパッケージを確認する。公式は「ディストリビューションとLTSベンダーには、事前にパッチを渡してある」と書いています。ベンダーの更新パッケージを確認してください
• ✓Remiのリポジトリ（rpms.remirepo.net）を使っている場合は注意。公式は「ボランティア運営で、今日は更新が出ない」とし、ディストリビューションのパッケージか、ソースからのビルドへ切り替えるよう求めています
• ✓更新したら、PHPのワーカー（プロセス）を再起動して、新しい版に入れ替える。古いプロセスが残らないようにするためです（当サイトの補足。公式の緩和策の説明は、設定変更後に全ワーカーの再起動を求めています）
• ✓コンテナを使っている場合は、使っているイメージが修正版に入れ替わったかを自分で確認する。公式の告知には、コンテナイメージの更新状況は書かれていません（当サイトの補足）
• ✓ホスティング／マネージドサービスの場合は、事業者の案内を確認する。自分で更新できないときは、事業者が対応するのを待つことになります（当サイトの補足）
• ✓8.1以前は、PHPプロジェクトからの更新はありません。公式は、ディストリビューションやLTSベンダーのバックポートを使うか、サポート中の版へ上げるよう求めています。ソースからビルドする人向けに、公式がPHP 7.4・8.0・8.1の最小のソースバックポートをGitHubのブランチで出しています（下の「根拠にしたページ」）

すぐに更新できないとき：部分的な緩和策（完全ではない）

公式は、「更新だけが完全な解決策」で、次の対策は特定の攻撃経路への露出を減らすだけで、安全にはならないと書いています。時間を稼ぐための一時的な措置として、公式の記述をそのまま整理します。

• ▸CVE-2026-109618（OOM）：`memory_limit=-1` を、アプリケーションから上書きできない形で設定する（FPMのプールの `php_admin_value`、Apacheの設定など）。どこかの設定が有限の値を戻していないかも確認します。制御できるメモリ不足は避けられますが、基盤のメモリ確保の失敗は残ります
• ▸`post_max_size` を小さくする。php.netの告知は、ファイルのアップロードが不要なら 8M、必要なら 32M にし、`upload_max_filesize` は `post_max_size` より小さくするよう書いています（具体的な数値は告知にあり、GitHubのアドバイザリは「控えめな値に」とだけ書いています）。Webサーバーやプロキシ側でも、展開後のリクエストの大きさ、入力項目数、マルチパートの部品数、ヘッダー数、入れ子の深さを制限します（Content-Lengthが無いリクエストも含めて）
• ▸コンテナやcgroupのメモリ上限は、可用性のための仕切りとして使える。ただし `RLIMIT_AS` や `RLIMIT_DATA` は使わないでください（脆弱な確保失敗を起こすため）
• ▸CVE-2026-109619（古い状態）：`session.upload_progress.enabled=0` にして、全ワーカーを再起動する。`php.ini`、FPMのプール、またはサーバー設定で、リクエストの解析より前に効く形にします。`ini_set()` や `.user.ini` には頼れません。確認された経路は防ぎますが、他の経路は防ぎません
• ▸PHP 8.5：`fatal_error_backtraces=0` にして、全ワーカーを再起動する。確認された致命的エラーのバックトレース経路だけを防ぎます
• ▸リクエストごとに適用される、無効または非推奨の設定を取り除く。初期化前に警告が出る設定が、攻撃の足がかりになりえます。`error_reporting`、`display_errors`、`@` で警告を隠しても防げません
• ▸攻撃者が届く場所の致命的エラーと実行時間超過を直す。コールバック、アップロードや取り込み処理、後始末での失敗を含みます

2件の脆弱性は何か（公式のアドバイザリより）

• ▸CVE-2026-109618「RCE via OOM corruption」：PHPはメモリ不足（OOM）のとき `longjmp()` で処理を抜けます。リクエストのメモリが完全に初期化される前にこれが起きると、PHPは途中終了を考慮せず、メモリを無効な状態のまま残します。リクエストの後始末が、その無効な状態を読んで、リモートコード実行につながります。マルチパートの解析に、宣言された長さが無いリクエストや、ヘッダーが際限なく付けられる部品などでメモリ不足を起こせる問題がある、と書かれています
• ▸CVE-2026-109619「RCE via stale global state」：ワーカーが持つ状態（エラー、セッション、オブジェクト、拡張機能）が、すでに解放されたリクエストのメモリを指したまま残り、同じワーカーが処理する次のリクエストが、初期化の前にそれを使って、解放後使用（use after free）になります。確認された使われ方は、初期化前のINI設定の警告と、セッションのアップロード進捗の2つです
• ▸2件は組み合わせて読む：どちらの記述も、もう一方の助言に従うよう求めています
• ▸影響の確認範囲：認証なしの、Webのワーカー権限でのリモートコード実行。mod_phpでは、既定の入力・メモリ制限と通常のprefork構成で、HTTP越しの完全なRCEが確認されています。CVE-2026-109619は、PHP 8.5の致命的エラーのバックトレース経路と、セッションのアップロード進捗の経路で確認され、後者はFPMでも確認されています（通常の動的プール。アプリケーションの条件に依存）
• ▸FPMについて：起動の失敗でワーカーが終了するため、CVE-2026-109618の一部の経路は防がれますが、起動後の経路はありえます。公式は「完全なFPMの攻撃は、この脆弱性については実証されていない」と書いています。FrankenPHPはmod_phpに似た性質でありうる、LSAPIはFPMに近い、との分析です

対象と修正版（公式より）

• ▸PHP 8.2：8.2.35より前が対象 → 8.2.35
• ▸PHP 8.3：8.3.36より前が対象 → 8.3.36
• ▸PHP 8.4：8.4.27より前が対象 → 8.4.27
• ▸PHP 8.5：8.5.12より前が対象 → 8.5.12
• ▸PHP 8.1以前：公式の影響範囲の表には載っていません。ただし公式が7.4・8.0・8.1向けの最小バックポートを出しているため、これらも同じ問題の影響を受けるとみるのが自然です（当サイトの推論）

何が起きたか（日付つき）

• ▸10月20日 20:32 UTC：PHPのセキュリティチームが、10月21日 14:00 UTC（日本時間23:00）にセキュリティリリースを出すと事前に告知。2件、どちらもCVSS v4.0 9.2
• ▸10月21日 13:34 UTC（日本時間22:34）：GitHubのアドバイザリ2件が公開
• ▸10月21日 13:48／13:54 UTC：CVE ProgramのCVE-2026-109618／CVE-2026-109619が公開（状態PUBLISHED）
• ▸10月21日 14:07 UTC（日本時間23:07）：php.netで修正版4つとセキュリティ告知が公開されているのを確認

確認できなかったこと

• ▸実際の攻撃（野生での悪用）の有無。公式は「実証された攻撃コードがある」とは書いていますが、すでに攻撃されているとは書いていません。CISAのKEV（悪用が確認された脆弱性のカタログ）にも、取得した版（2026年10月20日 19:00 UTC更新）には載っていません
• ▸侵害の痕跡（IoC）と検知の方法。公式は、被害の確認方法を書いていません。ログの見直し（致命的エラー、警告、実行時間超過の繰り返し）は露出を減らす助言として書かれていますが、ログに無いことは安全の証明にならないと公式も書いています
• ▸NVDの記録とスコア。2026年10月21日 14:09 UTCの時点でNVDに未登録です。数時間〜数日で取り込まれる見込みですが、確認していません
• ▸8.1以前が影響を受けるかの公式の表。8.2〜8.5だけが表に載っています
• ▸各社のパッケージ・コンテナイメージ・ホスティングの対応状況。公式は「ベンダーに確認を」としか書いていません。個別の更新状況は確認していません
• ▸リリース日の表記。php.netのトップページのニュースは10月21日、ChangeLogの8.5.12などの項目は10月22日と書かれていて、表記が揃っていません
• ▸完全な技術詳細。この記事は公式の要点です。攻撃の条件や設定の細部は、GitHubの2つのアドバイザリに書かれています

共有するならこの3行

• ▸PHPに、認証なしでリモートコード実行につながる重大な脆弱性2件（CVE-2026-109618・CVE-2026-109619、どちらもCVSS v4.0 9.2）。Apacheのmod_phpは特に危険と公式が書いている
• ▸★8.5.12／8.4.27／8.3.36／8.2.35へ今すぐ更新。OSのパッケージや、ホスティング事業者の対応も確認する。更新したらワーカーを再起動する。8.1以前は、ベンダーのバックポートかサポート中の版へ
• ▸すぐ更新できないときの緩和は部分的。`memory_limit=-1`（上書き不可）、`post_max_size` を小さく、`session.upload_progress.enabled=0`、PHP 8.5は `fatal_error_backtraces=0`。いずれも完全ではない