PHP に認証不要 RCE の重大脆弱性 2 件（CVE-2026-109618 / 109619）— 修正版 8.5.

2026年10月21日、PHP 公式は認証不要のリモートコード実行（RCE）につながる重大な脆弱性 2 件（CVE-2026-109618 / CVE-2026-109619）の修正版 PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 を、予定より早く公開した。公式は「完全な緩和策は存在しない。更新だけが安全な選択」と明記している。Web リクエストを処理する PHP は、修正版への更新を最優先にする。

本記事は 2026 年 10 月 21 日 23 時時点の PHP 公式アドバイザリ、GitHub アドバイザリ、IPA、各社の分析に基づく。悪用状況は情報源によって食い違っているため、誰の発言かを明記して整理した。手順を優先してまとめ、公式に明記のない点は「公式に明記なし」と書く。

発端は、公開予定日より前に脆弱性の存在が漏えいしたことである。PHP 開発チームは事前告知で「詳細が公開された場合は前倒しで公開する権利を留保する」としており、実際にその通りの展開になった。時系列は次のとおり。

CVE 番号の出どころにも注意が要る。10/20 の事前告知には CVE 番号が載っておらず、CERT-EU の注意喚起（SA2026-018）や漏えい情報に基づいて流通していた。10/21 の公式アドバイザリで、CVE-2026-109618（GHSA-w8hw-w9fx-j79w）と CVE-2026-109619（GHSA-6wmf-4rv5-p3rp）が確定した。深刻度も、漏えい時の「CVSS 10.0」という報道に対し、公式は 2 件とも CVSS v4.0 で 9.2（Critical）としている。本来の公開予定（エンバーゴ）は 10/22（木）11:00 ET だった（watchTowr の X 投稿より）。

PHP 公式アドバイザリによれば、対象は「Web リクエストを処理するすべての PHP 環境」である。PHP-FPM、Apache の mod_php、php-cgi、FrankenPHP、LiteSpeed が含まれる。そのうち「最もリスクが高いのは mod_php」で、認証不要のリクエストで、アプリケーションコードが動く前に攻撃を発火させるエクスプロイトが実証済みだという。2 件の違いを表にまとめる。

GitHub アドバイザリによる SAPI 別の露出は次のとおり。mod_php は .htaccess やディレクトリ単位の php_value / php_flag がリクエスト開始前に適用されるため、確認済みの RCE 経路になる。既定の入力・メモリ制限と通常の prefork 構成で、HTTP 経由の完全な RCE が検証済みである。PHP-FPM は起動失敗時に子プロセスを終了するため露出は限定的だが、通常起動後の OOM では到達し得る。完全な FPM エクスプロイトは未実証で、フロントエンドが PHP_VALUE / PHP_ADMIN_VALUE を渡す構成は条件付きで露出する。FrankenPHP は mod_php と同様に無条件でシャットダウンを呼ぶ可能性が高く「おそらく影響あり」、LSAPI（LiteSpeed） は「ありそうだが未検証」という整理である。影響は Web ワーカーのアカウント権限での認証不要 RCE とメモリ開示で、信頼性はビルド・拡張・フロントエンド・アロケータ配置に依存する。CVSS ベクトルは CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H で、攻撃複雑性は「高」、攻撃要件は「あり」だが、権限もユーザー操作も不要である。

悪用状況は情報源で食い違う。Cloudflare の CTO は 10/21 午前（UTC）に初期の攻撃を観測したと発言した。一方、IPA は悪用された攻撃を確認しておらず、watchTowr も 10/20 時点で悪用を観測していない。CISA の KEV カタログには、Tenable によれば未掲載である。PoC を名乗るコードは複数出回っているが、Tenable は「動作を検証していない。未検証のエクスプロイトコードにはマルウェアが含まれ得る」と警告し、Sansec は公開から 15 分以内に大規模攻撃が始まると予想している。PHP 公式アドバイザリは悪用状況に言及しておらず、公式による悪用の確認は「公式に明記なし」である。

PHP 公式アドバイザリによれば、影響を受けるのは 8.2.35 未満、8.3.36 未満、8.4.27 未満、8.5.12 未満である。8.1 以前は PHP プロジェクトの更新対象外で、公式の修正は出ない。php.net のサポート期限（2026-10-21 時点）と合わせて整理する。

8.1 以前でも手立てがゼロではない。PHP 公式アドバイザリによれば、一部のディストリビューションと LTS ベンダーがバックポートを提供するので、ベンダーに確認するか、サポート中のバージョンへ移行する。さらに PHP セキュリティチームは、深刻度を踏まえて PHP 7.4 / 8.0 / 8.1 向けの最小限のソースバックポートを GitHub ブランチ（PHP-7.4-CVE-2026-109618-109619 など）で提供している。ソースからビルドする人や LTS ベンダーがない人向けである。Linux ディストリビューションと LTS ベンダーは事前にパッチを受け取っているため、まずベンダーの更新パッケージを確認する。ディストリのパッケージは番号が上流と異なる（Ubuntu は 8.1.2-1ubuntu2.x のようにパッケージ版のみ上がる）ので、バージョン番号ではなくパッケージのリビジョンとディストリの告知で判断する。ディストリ側の読み方はLinux カーネル脆弱性の対応まとめも参考になる。なお本記事の執筆時点（22:50 JST）では、Debian の DSA や Ubuntu の USN は未確認である。Remi リポジトリ（ボランティア運営）の利用者に対し、公式はディストリパッケージへの切り替えかソースビルドを強く要請しており、同リポジトリは当日は更新されない。8.2 は 2026 年 12 月 31 日に EOL となり、以降は修正が提供されない。

手順は「棚卸し → 暫定緩和（更新できない場合のみ）→ 修正版の適用 → 侵害確認 → EOL の解消」の順に進める。緩和は修正の代わりにならないため、最短で修正版を入れることを軸にする。

フェーズ 0: 棚卸し（今すぐ）

- PHP が動いているものを可能な範囲で洗い出す（IPA）。見落としやすいのは、レンタルサーバー上の WordPress、EC、社内ツール、製品内蔵の PHP（Huntress）
- バージョンの確認方法は 4 つ。CLI は php -v、Web は phpinfo() を置いた一時ファイル（確認後に必ず削除）、WordPress は管理画面「ツール → サイトヘルス → 情報 → サーバー」、レンタルサーバーはコントロールパネルの PHP バージョン設定
- 優先順位は、インターネットに面しているものが最優先（Huntress）。EOL バージョンは攻撃者が短時間で悪用する恐れがあるため特に優先する（IPA）
- 製品に内蔵された PHP は、IPA によればマニュアルや開発元のセキュリティ情報を確認すればよく、全製品を個別に調べることまでは求めていない

フェーズ 1: すぐ更新できない場合の緩和（任意。どれも修正ではない）

PHP 公式アドバイザリは「更新だけが完全な解決策。以下は特定の攻撃経路への露出を減らすが、安全にはならない」と明記している。更新できる環境では、緩和を飛ばしてフェーズ 2 に進む。

WAF については、Cloudflare が緊急 WAF ルールを無料プランを含めて配布している。ただし Cloudflare の CTO 自身が「一時しのぎ」と位置づけており、Sansec と Geniar 氏は、オリジンサーバーへの直接アクセスを Cloudflare の IP 範囲に制限しないと素通りされると指摘している。Geniar 氏はカスタムルール例（未検証）として any(lower(http.request.headers["content-type"][*])[*]) contains "multipart" を挙げている。Sansec によれば、Magento や WordPress のメンテナンスモードは PHP がリクエストを解析した後に動くため、この脆弱性への対策にならない。

効かないもの、やってはいけないこと

- file_uploads = Off — Geniar 氏によれば、multipart の本文は解析されるため効かない
- post_max_size の縮小だけに頼る — Geniar 氏は安全な値が不明だとする。公式も更新の代わりにはならないとしている
- enable_post_data_reading = Off — フォームが壊れる（Geniar 氏）
- アプリ層のチェック — CSRF やログイン判定は、PHP が本文を解析した後に動く（Geniar 氏）
- オリジンに直接アクセスできる状態の WAF — 素通りされる
- Apache の PHP ハンドラだけを無効にする — .php がソースのまま配信され、認証情報が漏れる。止めるなら Web サーバーごと停止するか 503 を返す（Geniar 氏）
- ini_set() や .user.ini での設定 — 公式が頼らないよう明記している（リクエスト解析前に適用される設定で行う）
- error_reporting や @ で診断を隠す — 効かない（公式）

フェーズ 2: 修正版の適用（公開後すぐ）

適用後は必ずプロセスを再起動する。 php-fpm、Apache（mod_php）、Laravel Octane、キューワーカーなどは古いコードをメモリに保持し続ける（Geniar 氏）。確認は php -v と Web 側（phpinfo または CMS のサイトヘルス）の両方で行う。CLI と Web で別の PHP が動いていることがあるためだ。確認後は、フェーズ 1 で入れた遮断ルールや暫定設定を外し、アップロード・フォーム・決済の動作確認をする。session.upload_progress は、GitHub アドバイザリが不要なら更新後も無効のままにすることを示唆している。fatal_error_backtraces（PHP 8.5）を更新後に戻すべきかは、公式に明記なし。

フェーズ 3: 侵害の有無を確認する（公開前から攻撃が観測されたとの発言があるため）

- Huntress の観点 1: PHP ワーカー（php-fpm、php-cgi、httpd、apache2）の子プロセスとして、シェル（sh、bash、cmd.exe、powershell.exe）、インタプリタ（python、perl）、ダウンロード／ネットワークツール（curl、wget、nc、certutil.exe）が起動していないか
- Huntress の観点 2: リバースシェルのパターン（/dev/tcp/、fsockopen、mkfifo）がないか
- Huntress の観点 3: Web サーバーからの偵察コマンド（whoami、id、uname -a、ipconfig）がないか
- Huntress の観点 4: Web ルートの新規ファイルや Web シェル、新しい cron・スケジュールタスク・アカウントがないか
- ログ保全: 侵害が疑われたら、Web サーバーと PHP のログを保全する
- 隔離: 疑わしいサーバーはネットワークから隔離する（Huntress）
- EDR がない Linux では、Florian Roth 氏の process-watcher を観測モードで始める方法がある

フェーズ 4: EOL バージョンを使い続けている場合

公式の修正は出ない。Huntress と IPA が挙げる選択肢は 4 つある。サポート中のブランチ（8.2 以降）へのアップグレード、ディストリのバックポートの適用、オフライン化、VPN や WAF の背後への隔離である。IPA は EOL バージョンを特に優先するよう求めている。8.2 は 2026-12-31 でセキュリティサポートが終わり、8.4 も同日にアクティブサポートが終わる。今回の対応と合わせて、8.3 / 8.4 / 8.5 への移行計画を立てたい。

WordPress 本体を最新にしても、PHP は更新されない。PHP を直すのはサーバー側の作業である。まず管理画面の「ツール → サイトヘルス → 情報 → サーバー」で PHP のバージョンを確認する。修正版でなければ、レンタルサーバーの事業者の告知を見て、コントロールパネルで PHP バージョンを切り替える。事業者が一括更新する場合もあるが、各社の適用完了時刻は公式に明記なし。Movable Type は、クラウド版ならシックス・アパートが修正版公開後に直ちに更新するので利用者の作業は不要（自動更新が無効の環境も対象）、ソフトウェア版・AMI 版は利用者が PHP を更新する。国内では、ウマ娘（公式 X で 23:00 頃からのメンテナンスを告知、電撃オンライン報道）、BASE、Cygames、コドモンなど、予防的にサービスを止めてパッチ適用を待つ例が相次いだ（piyolog の整理による）。WooCommerce や Magento などの EC は、Sansec の指摘どおりメンテナンスモードでは止まらない。読み取り専用にするとカートや決済も止まる点を踏まえ、更新を急ぐ。

同系統の先例であるWordPress「wp2shell」認証不要 RCE の緊急解説、更新運用の基本を整理したWordPress 保守の実務、最初の 30 分の動き方を整理したIT トラブル緊急対応ガイドも合わせて読んでほしい。

- 棚卸し台帳を持つ: どのサーバー・どの製品でどの PHP が動くかを一覧にする。今回の棚卸しが数時間で終わるかは、台帳の有無で決まる
- サポート期限を管理する: 8.2 は 2026-12-31 で終了する。期限の半年前に移行計画を立てる
- ステージングで更新手順を確認する: 本番に入れる前に、アップロード・フォーム・決済が動くか確かめる
- ログを保全できる状態にする: Web サーバーと PHP のログが残る期間を確認しておく
- WAF とオリジン制限を整える: WAF の背後に置くだけでなく、オリジンへの直接アクセスを制限する
- 脆弱性診断を定期化する: 見落としている PHP が残っていないかを、外部の目で確かめる

全体の備えは中小企業の IT リスク対策ガイドと保守運用の完全ガイドに、診断の費用感は脆弱性診断・ペネトレーションテストの費用相場にまとめている。

- PHP 公式「Security advisory: Critical remote code execution vulnerabilities, update now」（2026-10-21）
- PHP 公式 リリース告知「PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 Released!」（2026-10-21）
- GitHub アドバイザリ GHSA-w8hw-w9fx-j79w（CVE-2026-109618）
- GitHub アドバイザリ GHSA-6wmf-4rv5-p3rp（CVE-2026-109619）
- PHP 7.4 向け最小限ソースバックポート
- PHP 8.0 向け最小限ソースバックポート
- PHP 8.1 向け最小限ソースバックポート
- PHP ChangeLog 8.5.12
- PHP 公式「Upcoming Critical PHP Security Release」（2026-10-20）
- PHP 公式 サポート状況（Supported Versions）
- IPA「【事前準備のお願い】PHPのセキュリティリリース公開予定について」（2026-10-21）
- CERT-EU「Critical Vulnerabilities in PHP」（SA2026-018）
- BleepingComputer（2026-10-20）
- Tenable「php2shell FAQ」（2026-10-21）
- Huntress「Rapid Response: php2shell」
- Sansec「Critical PHP RCE」（2026-10-21）
- Mattias Geniar「early mitigation steps」（2026-10-21）
- シックス・アパート「Movable Type への影響と対応」（2026-10-21）
- ITmedia NEWS（2026-10-21）
- piyolog「修正予告されたPHPの2件の深刻な脆弱性についてまとめてみた」（2026-10-21）
- 電撃オンライン「『ウマ娘』など複数ゲームが21日23時より緊急メンテ」（2026-10-21）