Google CloudがPHP緊急対応を更新｜自動更新と再デプロイの境界を確認する

Google Cloudは2026年10月22日、PHPの重大脆弱性CVE-2026-109618とCVE-2026-109619への対応案内を公開しました。さらに同日9時25分（米国太平洋夏時間、日本時間では23日1時25分）にCloud Armorの推奨策を更新しています。App EngineやCloud Runを使っていても、すべてのPHPが自動で安全な版へ切り替わるわけではありません。

本稿は2026年10月23日1時台にGoogle Cloudのブログ、セキュリティ情報、PHP公式アドバイザリを再確認した続報です。脆弱性そのものは既報のため、今回はGoogle Cloud上の実行方式ごとに「自動更新の対象」「再デプロイが必要な対象」「利用者が作り直す対象」を分けます。Google Cloudの基盤自体が脆弱という記事ではなく、同社の基盤上で利用者が動かすPHPワークロードが対象です。

更新案内で新たに具体化されたこと

Google Cloud公式ブログ「Responding to core PHP vulnerabilities」は、App Engine Standard、App Engine Flexible、Cloud Run、Cloud Run functions、GKE、Marketplaceで利用者が取るべき対応を分けました。また、Cloud Armorのマネージドルール、コンテナイメージの検査、実行時の脅威検知についても案内しています。

Google Cloud Security Bulletin GCP-2026-070は、この2件をCriticalとして掲載し、修正済みの依存関係を含むワークロードの再デプロイを求めています。Artifact Analysisを利用している場合は、新規と既存のイメージの両方で該当脆弱性の通知を受けられると説明されています。

PHP公式アドバイザリでは、CVE-2026-109618とCVE-2026-109619はいずれも2026年10月21日に公開され、PHP 8.2.35、8.3.36、8.4.27、8.5.12で修正されています。Google Cloudは両件のCVSS v4.0基本値を9.2とし、PHP 5.4から8.5.11までを影響範囲として説明しています。利用中の系列が古い場合、同じ系列内の小さな更新では解決できない点が重要です。

自動更新の有無は製品名だけでは決まらない

実行環境	Googleの案内	利用者側の確認
App Engine Standard	PHP 8.2以降の対応ランタイムは自動更新	実行版を確認。PHP 8.1以前は8.2以降へ上げて再デプロイ
App Engine Flexible	デプロイ済みアプリは自動更新されない	対応ランタイムへ変更して再デプロイ。カスタムランタイムは依存関係も更新
Cloud Run functions	PHP 8.2以降で自動ベースイメージ更新が有効なら自動更新	更新設定を確認。無効なら再デプロイ
Cloud Run	自動ベースイメージ更新が有効なサービスは自動更新	無効または自作コンテナなら修正版で再ビルド・再デプロイ
GKE	利用者がコンテナイメージを更新	修正版PHPを含むイメージへ更新しPodを再展開
Marketplace	ソリューション提供元の更新またはPHPの直接更新	イメージ名だけで判断せず、提供元の修正版と実行中の版を確認

「サーバーレスだから対応不要」と一括りにすると、App Engine Flexibleや自動ベースイメージ更新を無効にしたCloud Runを見落とします。Google Cloudは更新済みのサーバーレス用ベースイメージを展開していても、デプロイ済みのすべてのアプリを同じ方法で差し替えるわけではありません。基盤側に修正版が用意されたことと、自分のリビジョンがその版で動いていることを分けて確認します。

自作コンテナでは、DockerfileのPHPタグだけを変更しても、ビルドキャッシュが古いレイヤーを再利用する場合があります。本サイトの提案として、キャッシュ条件、ベースイメージのダイジェスト、イメージの作成時刻、PHPの実行版を一組で記録します。再ビルド後は新しいリビジョンへトラフィックが移ったことまで確認し、古いリビジョンが外部から到達可能なまま残っていないかを調べます。

PHP 8.1以前は自動修正を待たない

Google Cloudは、PHP 8.1以前に対してPHPプロジェクトが今回の修正をバックポートしないと説明しています。案内では、PHP 5.5、7.2、7.3、7.4、8.1を使うアプリはPHP 8.2以降へ移行する必要があると具体的に挙げています。古いランタイムを「自動更新対象の製品上で動いている」という理由だけで待機させないでください。

大きな系列更新では、拡張モジュール、Composer依存関係、非推奨機能、文字列や型の扱いに互換性差が出る可能性があります。しかし、互換性試験が終わるまで公開サービスを無期限に旧版で動かすことも安全ではありません。公開範囲の縮小、一時停止、読み取り専用化、影響の少ない機能からの再開などを含め、事業判断として例外期限を設定します。

更新確認はビルドログだけで終えません。Cloud Runなら実際にトラフィックを受けるリビジョン、GKEなら起動中Podのイメージダイジェスト、App Engineなら稼働バージョンでPHPの実行版を確認します。複数リージョン、待機系、夜間ジョブ、管理用サービスも同じ台帳へ入れます。

Cloud Armorの改訂案内はパッチの代わりではない

10月22日9時25分PDTの更新では、Cloud Armorのマネージドルールが具体化されました。Google Cloudによると、既に有効なマネージドルールには保護が自動適用されます。未導入の場合は、インターネット向けPHPアプリで、グローバルまたはリージョナルのApplication Load Balancerを使う構成に対し、File UploadとRFIカテゴリーを含むstable版をenforceで有効にするよう案内しています。

Cloud Armor Managed rules overviewでは、マネージドルールはプレビュー段階の機能で、stableとcanaryが継続的に更新されると説明されています。stableは本番検証済みの基準、canaryは早期のシグネチャとして提供されます。新しいルールをいきなり本番遮断へ使うのではなく、canaryをpreviewで観測し、stableをenforceで運用する方法も公式資料に示されています。

今回の脆弱性では、大きな要求本文がメモリー不足条件に関係し得るため、GoogleはWAFが検査しない本文をバックエンドへ届けない設定も検討するよう求めています。Cloud ArmorのWAF設定資料によると、事前定義WAFルールが検査できる要求本文は、設定に応じて先頭8KBから64KBまでです。

ただし、検査上限を超えた要求を一律に拒否すると、画像アップロード、バックアップ受信、大きなJSON APIなど正当な機能も止まります。本サイトの提案として、エンドポイント別の通常サイズを確認し、アップロード経路を分離し、previewログで影響を測ってから遮断へ進めます。Content-Lengthだけに依存するルールでは、ヘッダーの欠落や転送方式も考慮が必要です。

Google自身も、Cloud Armorを恒久修正ではなく一時的な補完策と位置付けています。WAFのイベントが見えなくなっても、PHP更新と再デプロイを止めてはいけません。ロードバランサーを経由せずにサービスへ到達できる経路があれば、WAFの適用範囲外になるため、Cloud Runの入口設定、GKEの外部公開、直接IPや別のロードバランサーも棚卸しします。

イメージ検査と実行時監視を役割で分ける

Artifact Analysisは、Artifact Registryなどのイメージに脆弱なPHPが含まれるかを見つける材料になります。しかし、レジストリに修正済みイメージがあるだけでは、本番のPodやリビジョンが更新された証拠になりません。脆弱性検出、ビルド、デプロイ、トラフィック切り替え、旧版停止を別の状態として追跡します。

Google Cloudは、Security Command CenterのGKE向けContainer Threat DetectionとCloud Run threat detection、Google Security OperationsのMandiant Frontline Threatsルールに追加した23件の検知も案内しています。これは侵害が発生したと断定する情報ではなく、更新と並行して不審な挙動を調べる選択肢です。本サイトでは実際の顧客環境で検知精度を試験していません。

監視では、メモリー異常、ワーカーの再起動、予期しない子プロセス、外向き通信、認証情報の利用を時系列で確認します。脆弱な版が動いていた期間を先に確定し、その期間に作られたリビジョンやPod、WAFイベント、アプリログを照合します。更新後の正常性確認と、更新前の侵害調査を混同しないことが重要です。

対応完了は実行中の版で判定する

• Google Cloud上でPHPを使うサービス、関数、Pod、ジョブ、Marketplace製品を列挙する
• 対応ランタイム、自動ベースイメージ更新、自作コンテナ、旧系列を区別する
• PHP 8.2.35、8.3.36、8.4.27、8.5.12以降を含む形で再ビルド・再デプロイする
• 本番トラフィックを受けるリビジョンとPodでPHP版・イメージダイジェストを確認する
• Cloud Armorの適用経路、stableルール、要求本文の検査上限と正規通信への影響を確認する
• 脆弱版の稼働期間について、WAF・アプリ・実行時検知を照合し、例外に期限を付ける

自動更新は運用負担を減らしますが、対象外のランタイム、無効化された設定、自作イメージ、既に起動しているリビジョンまで保証する言葉ではありません。今回のGoogle Cloudの更新は、同じクラウド内でも責任の境界が実行方式で変わることを示しています。管理画面の「更新あり」ではなく、外部から要求を受ける実体が修正版へ切り替わったことを完了条件にしてください。

関連記事

• PHPが重大RCEの修正版を公開！8.5.12など4系統へ緊急更新（2026年10月21日時点の脆弱性本体と修正版。今回の記事はGoogle Cloud上の反映方法に範囲を絞っています）
• PHP脆弱性を狙う攻撃通信をCloudflareが観測｜WAFと調査範囲を点検する（WAFを補完策として扱い、オリジン直通経路と調査を分ける考え方を確認できます）