PHPの深刻な脆弱性2件が公開。CVSS 9.2、全バージョンに影響、即時対応が必要
PHPのコアランタイムに2件の深刻な脆弱性が公開された。識別番号はCVE-2026-109618とCVE-2026-109619。いずれもCVSS基本スコア9.2のクリティカルと評価されている。
影響を受けるのはPHP 5.4から8.5.11までのすべてのバージョンだ。認証不要のリモートコード実行やメモリ情報の漏えいにつながる可能性があり、修正版へのアップデートが急がれる。PHP 8.1以前はサポート終了済みのため修正が提供されない。
Google Cloudは2026年10月21日に顧客向けガイダンスを公開した。サーバーレス環境の自動パッチ状況、Cloud Armorによる緩和策、パッチ適用前の暫定対策をまとめている。この記事ではその内容を整理して解説する。なお、Google Cloud自体は今回の脆弱性の影響を受けていない。影響があるのはGoogle Cloud上でPHPを実行しているユーザーだ。
今回の脆弱性の概要
2件ともPHPのワーカープロセス内で発生するメモリ管理の欠陥で、攻撃者が細工したリクエストを送ることで悪用される可能性がある。
2つの脆弱性が狙う経路
CVE-2026-109618は、リクエスト処理中にメモリ不足（OOM）が発生した際の後始末に問題がある。内部データが部分的にしか初期化されていない状態で処理が中断されると、その後のクリーンアップが不正なデータを有効なものとして扱ってしまう。
CVE-2026-109619は、リクエストが所有する内部状態が、メモリが解放された後も残存するという欠陥だ。同じワーカープロセスが後続のリクエストを処理する際、通常の初期化が行われる前に古い状態を参照してしまう。いわゆるuse-after-freeと呼ばれるメモリ破壊の一種である。
この2件の発見には、Wiz ResearchとGoogle DeepMindのGemini 4 Argonが関与した。Wiz Researchは調査結果と調整プロセスを公開しており、Gemini 4 Argonは脆弱性の発見、エクスプロイト開発、攻撃検知、パッチ検証に貢献したと報告されている。
影響を受けるバージョンと修正版
影響を受けるのはPHP 5.4から8.5.11までのすべてのバージョン。修正版はPHP 8.5.12、8.4.27、8.3.36、8.2.35として公開された。
PHP 8.1以前はサポート終了済みのため修正が提供されない。PHP 5.5、7.2、7.3、7.4、8.1を使用している場合は、PHP 8.2以降へのアップグレードが必須となる。ここが今回の対応で最も重要な分岐点だ。
- PHP 5.4〜8.5.11が影響を受けるバージョンだ
- PHP 8.5.12、8.4.27、8.3.36、8.2.35で修正済みだ
- PHP 8.1以前はサポート終了のため修正が提供されない
Google Cloud環境での対応手順
デプロイ先のプラットフォームによって対応が異なる。自動更新の対象かどうかを最初に確認しよう。PHP 8.2以降を使用していなければ、どのプラットフォームでも恩恵を受けられない。
サーバーレスプラットフォームの自動パッチ
Google CloudはApp Engine Standard、App Engine Flexible、Cloud Run、Cloud Run Functions、Cloud Functions for Firebase向けに更新済みのサーバーレスベースイメージを順次展開している。
App Engine Standard（PHP 8.2以降）は自動的に更新される。追加操作は不要だ。Cloud RunとCloud Run Functionsは、自動ベースイメージ更新が有効であれば自動更新される。無効の場合は再ビルドと再デプロイが必要になる。
App Engine Flexibleは自動更新されない。PHP 8.2以降を使用して、できるだけ早く再デプロイする必要がある。カスタムランタイムを使用している場合は、PHP依存関係を修正版に更新してから再デプロイする。
コンテナとGKEでの再デプロイ
Google Kubernetes Engine（GKE）では、コンテナイメージを修正版のPHPで更新し、ポッドを再デプロイする。Cloud Runに自作のコンテナイメージをデプロイしている場合も同様だ。
Google Cloud Marketplaceのソリューション（LAMPスタックやCMSなど）を利用している場合は、ソリューションプロバイダーの更新を適用するか、PHPを直接更新する。自作のコンテナイメージは自分の責任で再ビルドする必要がある。
アップグレード後は、ディスク上のパッケージを更新しただけでは不十分だ。実行中のワーカープロセスには古いバイナリが残る。php-fpmやApacheなどのSAPIを明示的に再起動すること。スーパーバイザー管理のワーカーも再起動の対象となる。
Cloud Armorによる緩和策
Cloud Armorはマネージドルールを用いた緩和策を公開している。マネージドルールを有効にしている顧客は追加の操作が不要で、脅威インテリジェンスのルールセットを通じて自動的に保護が適用される。
マネージドルールの展開
まだCloud Armorのマネージドルールを展開していない場合は、今すぐ導入することでリスクを下げられる。File UploadとRFIカテゴリを有効にし、すべてのルールセットカテゴリを安定版で強制モードに設定することが推奨されている。
マネージドルールの保護は、グローバルまたはリージョンのアプリケーションロードバランサーを経由するインターネット向けPHPアプリケーションに適用される。ファーストラインの多層防御として機能する。
リクエストボディのサイズ制限
とくに重要なのがリクエストボディのサイズ制限だ。攻撃者は大きなペイロードを送ってメモリ不足（OOM）を引き起こす可能性があるため、検査上限を超えるリクエストや不必要に大きなコンテンツがバックエンドに到達しないようルールを作成する。
Cloud Armorの緩和策はあくまで補完的な防御層であり、根本的な解決には修正版PHPへのアップグレードと再デプロイが必要だ。WAFだけに頼らず、アップグレードを並行して進めるべきである。
監視と検知の方法
Google Cloudの監視ツール
Google CloudとWizは、顧客向けに監視・監査・ランタイム検知の支援を提供している。主なツールは以下の通りだ。
- On-Demand Scanning APIは、ローカルやArtifact Registry内のコンテナイメージを手動スキャンできる。Artifact Analysisを利用していれば、新規・既存の成果物に対して脆弱性が通知される
- Security Command Centerの外部公開スキャンでは、Compute Engine、GKE、Cloud Run上の公開PHPワークロードを検出できる
- 脆弱性評価を有効にすると、Compute Engine VM、GKEノード、コンテナワークロードが脆弱なPHPバージョンを使用しているか確認できる
- Container Threat DetectionとCloud Run Threat Detectionを有効にすると、ワークロードへの侵入を監視できる
Google Security OperationsにはMandiant Frontline Threatsルールパックの23個の新しいキュレーション済み検知が追加された。Enterprise Plus顧客はEmerging Threat Centerで「GLOBAL.26.015」を検索できる。
WizとMandiantによる支援
Wizの顧客はWiz Threat Intel Centerのアドバイザリを参照できる。エージェントレス検知、ランタイム脆弱性検知、Wiz DefendとSensorによる攻撃検知、自動応答ポリシーが含まれる。さらに、WizOS PHPイメージはゼロビリングユニットで60日間提供されており、CVE-2026-109618とCVE-2026-109619の両方に対してパッチ済みだ。
Mandiant Threat Defenseは、Google Security Operationsのキュレーション済み検知を監視し、今回のキャンペーンに関連する侵入活動の証拠をハンティングしている。
パッチ適用前の暫定対策
暫定対策はあくまでパッチ適用までの時間稼ぎだ。根本解決には修正版へのアップグレードが不可欠である。
PHPランタイムの硬化設定
すべてのバイナリを即座にアップグレードできない場合は、メインのphp.iniまたはFPMプール設定に以下の項目を追加し、全ワーカーを再起動する。
- すべての設定をメインのphp.iniに記載する。.htaccessなどリクエスト単位の設定を避ける
- pm.max_requests=1を設定して、リクエストごとにワーカープロセスをリセットする。これによりマルチステップのメモリ攻撃を遮断できる
- display_errors=Offだけでは不十分。エラー非表示にしてもセッションクッキー経由でメモリが漏えいする可能性がある
怪しい挙動を示すサーバーがある場合は、パッチ適用や再起動の前にワーカーのメモリフォレンジックを取得することが推奨されている。再起動すると揮発性のヒープ証拠が完全に失われるためだ。パッケージを更新しても、実行中のワーカープロセスには古いバイナリが残る。php-fpmやApacheなどのSAPIを明示的に再起動する必要がある。
サードパーティのRPMミラーは調整開示に遅れる可能性があるため、公式ディストリビューションのセキュリティリポジトリを使うべきだ。修正版が適用されたか確認するには以下のコマンドを実行する。
apt-get changelog php-fpm | grep -E "CVE-2026-109618|CVE-2026-109619"
rpm -q --changelog php-fpm | grep -E "CVE-2026-109618|CVE-2026-109619"エッジプロキシとWAFの設定
RFC 1867のマルチパート解析はスクリプト実行前に発生するため、リバースプロキシとWAFが前線の防御となる。主な回避手法への対策は以下の通りだ。
- ファイルアップロードが不要なルートではmultipart/form-dataをブロックする
- チャンク転送エンコーディングを使用したPOSTリクエストを拒否し、クライアントの最大ボディサイズを8MBに設定する
- 深くネストした角括弧のフィールド名をブロックする
- PHPSESSIDクッキーの形式を厳格に検査し、nullバイトや英数字以外の文字を含むものを拒否する
- 脆弱な公開リソースへのingressをWAF経由に限定する
OSレベルのサンドボックス化
ネイティブのuse-after-free実行はワーカープロセス内で発生するため、OSレベルの封じ込めも重要だ。専用の非特権アカウントでPHPワーカーを実行し、ドキュメントルートを読み取り専用にする。systemdならProtectSystem=strict、KubernetesならreadOnlyRootFilesystemをtrueに設定する。
ワーカーの総メモリはcgroups（MemoryMax=2Gなど）で制限する。LimitASやulimit -vはmmap()がNULLを返して脆弱なOOM経路を引き起こすため避ける。PHPサーバーからの外向きインターネットアクセスをブロックし、/bin/sh、curl、wgetなどのシェルツール実行を制限することも有効だ。
この記事のポイント
- CVSS 9.2のクリティカルなPHP脆弱性が2件公開された。CVE-2026-109618とCVE-2026-109619だ
- PHP 5.4〜8.5.11が影響を受ける。修正版はPHP 8.5.12、8.4.27、8.3.36、8.2.35
- PHP 8.1以前は修正なし。サポート終了済みのためPHP 8.2以降へのアップグレードが必須
- Google CloudのApp Engine Standardは自動更新。FlexibleやGKEは手動での再デプロイが必要
- Cloud ArmorのマネージドルールとWAF設定で一時的な緩和が可能。ただし根本解決にはパッチ適用が不可欠
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験