PHP 8.5.12と8.4.27、重大なRCE脆弱性2件を修正

PHPは2026年10月21日、2件の重大な脆弱性を修正するため、バージョン8.5.12、8.4.27、8.3.36、8.2.35をリリースしました。どちらも、攻撃者がログインせずにWebサーバー上でコードを実行できるおそれがあります。PHP.netのセキュリティアドバイザリーは、すべてのPHPユーザーに直ちに更新するよう求めています。さらに、どの設定変更でもサーバーを完全には守れないと付け加えています。そのため、新しいリリースをインストールすることが唯一の安全な選択肢です。

PHPは前日、バグの詳細が予定より早く流出したことを受けて、この定例外リリースを予告していました。この事前告知については今朝お伝えしました。今日のリリースで、未解決だった疑問に答えが出ました。どのバージョンが修正されたのか、バグが何をするのか、そして誰が最も危険にさらされているのか、です。

2件のPHP脆弱性の中身

どちらのバグも、Webリクエストごとの準備と後片付けを行うコードにあります。PHPは、0から10で深刻度を示す標準的な尺度であるCVSS v4.0で、それぞれを9.2と評価しています。そして、どちらも「認証なしでのリモートコード実行を可能にするおそれがある」としています。認証なしとは、攻撃者がアカウントもパスワードも必要としないという意味です。

CVE	GitHubアドバイザリー	何が問題か
CVE-2026-109618	GHSA-w8hw-w9fx-j79w	メモリ不足により、PHPがリクエストの準備を途中で止めてしまうことがあります。その後、後片付けのコードが作りかけのデータを有効なものとして扱うおそれがあります。
CVE-2026-109619	GHSA-6wmf-4rv5-p3rp	一部のリクエストデータが、その裏にあるメモリよりも長く残ることがあります。同じワーカープロセス上の次のリクエストが、その古いデータを先に使ってしまうおそれがあります。

ワーカープロセスとは、Webサーバーがリクエストに応答するために動かし続けている、長時間稼働するPHPのコピーの1つです。ワーカーの再利用は普通のことで、高速です。だからこそ、あるリクエストの残りのデータが次のリクエストに影響するのです。

誰が危険にさらされているか

PHPのアドバイザリーによると、Webリクエストを処理するすべてのインストール環境が影響を受ける可能性があります。これにはPHP-FPM、mod_phpを使ったApache、php-cgi、FrankenPHP、LiteSpeedが含まれます。PHPは、Apache自体の中でPHPを動かすモジュールであるmod_phpを、最もリスクが高いと見ています。アドバイザリーは「実証済みのエクスプロイト」について説明しています。そこでは、認証なしの1回のリクエストが、アプリケーションのコードが動く前に攻撃を引き起こします。

この点は、アプリケーションレベルの防御に頼っている人にとって重要です。WordPressやフレームワーク内のファイアウォールルールは、実行される機会すらありません。

PHPのアドバイザリーは、実環境での攻撃を報告していません。ほかの報道は、それほどはっきりしていません。TechStartupsによると、Cloudflareの最高技術責任者（CTO）が攻撃の初期の兆候を確認しましたが、その規模は不明です。TechStartupsはまた、watchTowrの最高経営責任者（CEO）であるBenjamin Harris氏の発言も引用しています。同氏はBleepingComputerに対し、どちらのバグも「CVSS10」だと語りました。これはPHP自身の9.2より高い評価です。Gulf NewsはReutersを引用し、公表後の水曜日に、欧州などの政府系Webサイトがオフラインになったと報じています。それらの停止が攻撃によるものかどうかは述べていません。

Amazonはその後、同社のハニーポット網MadPotが、このリリースの4日前の10月17日に攻撃の試みを記録していたと発表しました。詳しくはAmazon、公表の4日前にPHP2Shellの攻撃の試みを確認をご覧ください。

インストールすべきPHPのバージョン

ブランチ	修正版	備考
PHP 8.5	8.5.12	修正済み
PHP 8.4	8.4.27	修正済み
PHP 8.3	8.3.36	修正済み
PHP 8.2	8.2.35	修正済み。ブランチは2026年12月31日にサポート終了
PHP 8.1、8.0、7.4	なし	最小限のソースパッチのみ。PHP-8.1-CVE-2026-109618-109619などの名前のブランチで提供
7.4より古いもの	なし	PHPからの修正なし

7.4、8.0、8.1向けのソースパッチは、パッケージ化されたリリースではありません。誰かがビルドする必要があります。Gulf Newsは、一部のベンダーが、まだサポートしている古いバージョンに修正をバックポートする可能性があると指摘しています。

PHPはまた、部分的な緩和策も挙げています。session.upload_progress.enabledを無効にすることや、リクエストサイズの上限を厳しくすることなどです。アドバイザリーは、これらが「インストール環境を安全にするものではない」と率直に述べています。本当の更新を展開する間、攻撃の範囲を狭めるだけです。

開発者にとっての意味

今日パッチを適用し、忘れがちな場所にも適用してください。目立つサーバーだけが、組織で動いているPHPのコピーであることはまれです。

• メインサイトだけでなく、すべてのランタイムを確認する。 各ホストでphp -vを実行してください。次に、コンテナのベースイメージ、CIランナー、ステージング環境のマシン、社内ツールを確認します。古いタグに固定されたDockerイメージは、誰かが再ビルドするまでバグを抱えたままです。
• 更新後に再起動する。 PHP-FPMとApacheはワーカープロセスを動かし続けます。ディスク上の新しいパッケージは、それらのワーカーが再起動するまで何の効果もありません。そのため、更新後に実行中のバージョンを確認してください。
• mod_phpのホストを最優先にする。 PHPはこれを最もリスクの高い構成としており、コードが実行される前に作動するエクスプロイトがあります。mod_phpのサーバーを今日更新できない場合は、更新できるまでオフラインにすることを検討してください。
• PHP 8.1以前は緊急のアップグレード対象として扱う。 公式リリースは出ません。ソースパッチで時間は稼げますが、それは誰かがビルドして保守する場合に限られます。ホスティング事業者やLinuxディストリビューションに、バックポートを提供するかどうか問い合わせてください。
• PHP 8.2のサポート終了に備える。 8.2ブランチは2026年12月31日にセキュリティ修正の提供を終えます。今のうちに8.4か8.5へ移行しておけば、年末に再び慌てずに済みます。
• ログを監視する。 早期の攻撃の報告は確認されていませんが、詳細はすでに公開されています。PHPワーカーで異常なクラッシュやメモリ不足エラーが起きたら、詳しく調べる価値があります。