PHPの5.4から8.5.11までが対象というのは本当か。CVSS9.2「CVE-2026-109618/109619」の影響範囲を確かめる

まず初めに

PHPは1995年に公開され、今年で31年目になる、もう十分に枯れた「古株」のはずの言語だ。それなのに、CVSS9.2という最高クラスの激震が今になって出てくる。しかも原因は、メモリの「後始末忘れ」——掃除をサボった結果、前の客の忘れ物が次の客の手元に化けて出てくるという、わりと地味な話だ。地味だからといって侮れない。影響範囲はPHP 5.4から最新の8.5.11まで、つまり現役世代ほぼ全員が巻き込まれている。長年使われ続けてきたという実績は、裏を返せば「直すべき場所がまだ山ほど残っている」という意味でもある。

※個人の感想です

何が起きているのか

Google Cloud(著者:同社CISOのChris Betz氏、Google DeepMind Gemini Security責任者のRaluca Ada Popa氏)は2026年10月21日、公式ブログでPHP本体に影響する2件の脆弱性への対応をまとめた記事を公開しました。両脆弱性は、同日にPHPプロジェクトとセキュリティ企業Wiz Researchによって公表されたものです。

1つ目の「CVE-2026-109618」は、メモリ不足(Out-of-memory)の処理中にPHPが中断すると、リクエストの内部データが部分的にしか初期化されていない状態のまま残り、その後のリクエスト後処理(cleanup)が、この無効なデータを有効なものとして扱ってしまう可能性がある、という問題です。2つ目の「CVE-2026-109619」は、あるリクエストに属する内部状態が、その裏付けとなるメモリが解放された後も残存することがあり、同じ処理の仕組み(ワーカー)で後から処理される別のリクエストが、通常の初期化で上書きされる前に、この古い(stale)状態を使ってしまう可能性がある、という問題です。どちらも対象はPHPのコア言語ランタイムそのもので、特定のアプリケーションやライブラリの問題ではありません。影響を受けるバージョンはPHP 5.4から直近の8.5.11までとされています。

両脆弱性のCVSS基本値は9.2(Critical)。記事では、攻撃者がシステムをクラッシュさせたり乗っ取ったりでき、データの窃取・改ざん・消去が容易になる可能性があるとされ、想定される攻撃の形態として、認証不要のリモートコード実行(RCE)とメモリ情報の漏えいが挙げられています。ただし、実際の悪用のしやすさは環境ごとの緩和要因によって変わる場合があるとも補足されており、記事には現時点での実際の悪用や攻撃事例についての記述はありません。脆弱性の発見にはPHPプロジェクトとWiz Researchが取り組み、Google CloudのAIモデル「Gemini 4 Argon」が脆弱性の発見・エクスプロイト開発・攻撃の検知・修正内容の検証に活用されたと説明されています。

Google Cloud自体のサービスそのものが脆弱というわけではありませんが、Google Cloud上で動くPHPアプリケーションは影響を受ける可能性があります。対象となるのは、App Engine(Standard・Flexible)、Cloud Run、Cloud Run functions、Cloud Functions for Firebase、GKE(Google Kubernetes Engine)、そしてGoogle Cloud MarketplaceでPHPを使ったCMSやLAMPスタックのソリューションです。修正版はPHP 8.5.12、8.4.27、8.3.36、8.2.35で、これより古いPHP 5.5、7.2、7.3、7.4、8.1はすでにPHP公式のサポートが終了しているため、バックポート(旧バージョン向けの修正の提供)は行われません。該当する古いバージョンを使い続けている場合は、修正版へのアップグレードが必要になります。

なぜ重要なのか

CVSS9.2という最高クラスの深刻度が示す問題は、ウェブサービスの土台部分であるPHP本体で、認証を必要としないリモートコード実行につながる可能性がある、という点です。アプリケーション固有のコードの不備ではなく、言語ランタイムそのものの問題であるため、個別のアプリケーションをどれだけ注意深く作っていても、使っているPHP本体のバージョンが古ければ影響を受ける可能性があります。

もう一つ注目すべき点は、修正がPHP 8.2以降に限られ、それより古いバージョンはサポート終了によりバックポートされないという事実です。長年同じバージョンのPHPを使い続けているシステムほど、今回の修正の対象外になりやすく、アップグレード作業そのものが必要になります。Google Cloudの発表は、脆弱性の技術的な説明だけでなく、どのクラウドサービスのどの設定が自動的に更新され、どこが利用者自身の対応を必要とするかを具体的に切り分けて示している点で、対応の優先順位を考える手がかりになります。

私たちへの影響

今回の発表で直接対応が必要になるのは、Google Cloud上でPHPアプリケーションを運用している開発者・企業です。特に、App Engine Flexibleでカスタムランタイムを使っている場合や、Cloud Run・GKEで独自のコンテナイメージを使っている場合は、自動更新の対象にならないため、利用者自身でPHPの依存関係を更新し、再デプロイする必要があります。App Engine Standard(対応ランタイム)やベースイメージの自動更新が有効なCloud Run・Cloud Run functionsは、自動的にパッチが適用されるとされています。

一般の消費者が直接何らかの操作をする必要はありません。ただし、普段使っているウェブサービスやブログ、ECサイトの裏側には、PHPで作られたCMS(コンテンツ管理システム)が使われていることが少なくありません。サイトの運営者・管理者がこうした脆弱性情報を把握し、適切に更新しているかどうかが、間接的に利用者のデータの安全性にも関わってきます。

初心者が知っておくべきこと

脆弱性ぜいじゃくせいの深刻度を表す「CVSS」とは、ソフトウェアの脆弱性がどれくらい危険かを、共通の基準で0から10までの点数にする仕組みです。今回の9.2は、この基準の中でも「Critical(緊急)」と呼ばれる最も高い区分に入ります。「CVE」は、個々の脆弱性に割り振られる共通の識別番号で、今回のように複数の組織・報道で同じ脆弱性を指す際の「共通言語」として使われます。「RCE(リモートコード実行)」とは、攻撃者が対象のコンピューター上で、本来許可されていないプログラムを外部から実行できてしまう状態のことです。

Q. 自分の運営するサイトがGoogle Cloud以外の、一般的なレンタルサーバーでPHPを使っている場合も対象になりますか。 A. 今回のCVE-2026-109618・CVE-2026-109619は、PHP本体(コア言語ランタイム)自体の脆弱性であり、Google Cloud固有の問題ではありません。したがって、PHP 5.4から8.5.11までの該当バージョンを使っている環境では、クラウド事業者やホスティング形態を問わず影響を受ける可能性があります。PHP 8.1以前は修正版のバックポート対象外なので、サポート中の修正版への更新が必要です。ただし、各ホスティング事業者がどのように対応しているか、自動的にパッチが適用されるかどうかは、この一次資料(Google Cloudの発表)からは分かりません。自分が使っているサーバーやホスティングサービスのPHPバージョンとサポート状況を、提供元に確認することをおすすめします。

IT Postの見方——「気づかれにくい基盤」の脆弱性をどう扱うか

IT Postは、脆弱性の発見から公表までにPHPプロジェクト・Wiz Research・Google Cloudが連携し、修正版の提供とあわせて同日に情報を公開した今回の進め方自体は、適切な対応だと考えます。脆弱性を見つけた側が一方的に先に公表してしまうと、修正が間に合わないまま攻撃者だけが情報を手にする事態になりかねません。

ただ、IT Postでは、こうした基盤レベルの脆弱性ほど、実際に使っている事業者・個人には気づかれにくいという点を重視すべきだと考えます。PHP本体のバージョンを意識して運用しているのは、多くの場合、専任の運用担当者を抱える企業です。小規模な事業者や個人が低コストで利用しているホスティングサービス・CMSほど、裏側のPHPバージョンが古いまま放置されやすく、かつ本人がその事実に気づく手段も限られます。影響範囲の広さとサポート期限の仕組みそのものを、利用者側にもっと分かりやすく伝える仕組みが、クラウド事業者・ホスティング事業者の双方に求められていると、IT Postでは考えます。

※個人の感想です

今後どうなりそうか

Google Cloudの発表時点では、実際の悪用が確認されたという記載はありません。しかし、脆弱性の詳細が公表された以上、時間が経つほど実証用のコードが出回るリスクが高まるのが一般的な傾向であり、未修正のまま放置される環境が残れば、今後実際の攻撃に使われる可能性は否定できません。IT Postでは、今回の脆弱性を悪用した実際の攻撃事例が報告されるかどうか、また他の主要なクラウド事業者・ホスティング事業者の対応状況についても、あらためて確認していきます。