ApigeeのDrupalポータルもPHP更新が必要｜既存VMと自動復旧の作成元を点検

ApigeeでAPIを管理しているから、開発者ポータルもGoogle側で修正されると思っていないでしょうか。Google Cloudが2026年10月24日に公開したGCP-2026-072は、PHPの重大脆弱性について、Apigee本体と顧客が運用するDrupalポータルを分けて対応するよう案内しています。

特に注意が必要なのは、Marketplaceから作った既存のポータルVMです。新規デプロイ用のイメージが修正されても、稼働中のVMは自動更新されません。さらに、今のVMへ修正しても、自動増設や自動復旧に使う作成元が古ければ、脆弱な環境を再び公開する可能性があります。

本稿は2026年10月25日にGoogle CloudのApigeeセキュリティ告知とPHP公式アドバイザリを確認した続報です。新しいPHP脆弱性の発見を伝えるものではありません。既報のGoogle Cloud全般の対応に対し、今回はDrupal開発者ポータルの対象判定、既存VMと再作成元の二重更新、侵害時の資格情報対応に絞ります。

まずApigee本体とDrupalポータルを分ける

Googleの告知では、Apigee、Apigee Hybrid、Apigee Edge for Public Cloud、API hub、Apigee integrated portalはPHPを使わず、今回の2件の影響を受けません。Apigee Edge for Private Cloudも、任意導入のDrupalポータル部分を除いて対象外です。製品名だけで全体を停止したり、逆にクラウドサービスだからすべて対象外と判断したりしないでください。

確認対象は、Marketplace版とDocker版のApigee Developer Portal Kickstart、Apigeeモジュールなどを使う自己ホストのDrupal 10・11ポータル、Private Cloudに関連するDrupal 7・9ポータルなどです。APIのゲートウェイを管理するチームと、ポータルのOS・PHPを管理するチームが異なる場合、後者への連絡が抜けやすくなります。

本サイトの提案として、公開ドメインを入口に、ポータルの実装、ホスティング先、PHP実行環境、構成管理の所有者を一行で対応付けます。管理画面にApigeeの名称があるかではなく、インターネットから受けた要求を処理するPHPがどこにあるかを特定してください。過去に委託先や別サーバーへ移したポータルも、現行の資産台帳と照合します。

モジュール更新だけではPHPのRCEは直らない

対象となるCVE-2026-109618とCVE-2026-109619は、認証なしのリモートコード実行につながるPHP本体の問題です。PHP公式のOOM corruptionアドバイザリとstale global stateアドバイザリは、修正版としてPHP 8.2.35、8.3.36、8.4.27、8.5.12を示しています。修正は10月21日のもので、10月24日は今回のApigee向け告知の公開日です。

GoogleはApigee用Drupalモジュールの更新だけでは修正できず、PHPの更新が必要だと明記しています。ポータルのモジュール一覧が最新でも、要求を処理するPHPワーカーが古ければ対応完了にはなりません。本稿では実際のポータルに対する攻撃を試していません。また、確認したApigee告知だけから、特定の利用者が侵害されたとは判断できません。

対応記録は、アプリケーション依存関係と実行基盤で分けると確認しやすくなります。前者にはDrupalとApigeeモジュール、後者にはOSパッケージ、PHP、FPMのプロセス、VMまたはコンテナの作成元を記録します。アプリケーション担当がモジュール更新を終えた時点でチケットを閉じず、基盤担当の実行版確認を完了条件に含めます。

Marketplaceは稼働VMと作成元を両方確認する

Googleの案内では、Marketplaceの新規デプロイはPHP 8.3.36を含む修正済みイメージを使います。一方、既存デプロイでは、まず稼働中のVMを更新してPHP-FPMを再起動し、その後にマネージドインスタンスグループが使うイメージを確認します。このポータルのFPM再起動にはsystemctlではなくsupervisorctlを使うよう、告知で指定されています。

作成元のイメージ名に日付が含まれる場合、告知はapigee-devportal-drupal-202610231240以降を修正済みとしています。日付なしのapigee-devportal-drupalは修正済みイメージを指します。実際のテンプレートと参照イメージを確認し、古い日付付きイメージなら修正済みのものへ移す必要があります。

ここでのセキュリティ上の判断は、増設・自動復旧によって脆弱性が再導入される経路を閉じられたかです。手作業で一台を直した事実と、今後作られるすべてのVMが修正版になる事実は別です。本サイトでは、稼働中VMの一覧と、インスタンステンプレートの参照先を同じ変更記録へ保存することを提案します。

• まず外部公開されている全VMを列挙し、未更新の実行環境が残る範囲を確定する。
• 実行中のPHP-FPMの版とプロセスの入れ替わりを確認する。CLIのphpの結果だけで代用しない。
• 増設・自動復旧で選ばれるテンプレートとイメージを確認し、古い作成元を更新する。
• 構成管理から再適用した後も修正済みイメージを維持できるか確認する。

Terraformで管理している場合、Googleはsource_image_pathを修正して適用するよう案内しています。コンソール上だけで変えると、次回の適用で手動変更が戻されるためです。緊急変更を行った担当者と通常の構成管理担当者が異なる場合は、緊急対応の差分を構成管理へ戻す責任者を決めてください。

Dockerは再起動と更新済みイメージの取得を区別する

Docker版について、Googleはlatest、main、nightlyタグをPHP 8.3.36入りで再公開したと説明しています。既存コンテナを単に再起動しても、修正済みイメージの取得とコンテナの再作成を実施した証拠にはなりません。自己ビルドの場合は、更新されたベースを使って作り直す必要があります。

本サイトの提案として、更新前後のイメージダイジェスト、実行中コンテナの作成日時、内部で使われるPHPの版を一組で残します。同じタグ名が続く構成では、タグ文字列だけの比較では中身の更新を判断できません。Kubernetesでも、更新されたPodが期待するイメージを使ったかを実体で確認します。

再作成前には、DBやアップロードファイルの保存先を確認してください。Googleの告知は、データをボリュームまたはbind mountへ保存していることを確認し、バックアップを取るよう求めています。セキュリティ更新で可用性やデータを失うと、古い環境へ戻す圧力が生まれます。復旧先も修正済みで用意し、脆弱な旧コンテナを通常のロールバック候補に残さない運用を検討します。

旧Drupalポータルは停止と移行の判断が必要

Private Cloudに関連するDrupal 7・9ポータルについて、Googleは使用するPHP・OS構成にパッケージ修正がないことを示し、公開停止または内部ネットワークへの制限と、対応するPHP上のDrupal 10・11への移行を案内しています。既存の古いポータルを、新しいApigee本体の更新だけで保護できると考えないでください。

本サイトでは、移行期間中の公開継続を例外として扱い、期限、責任者、公開が必要な機能、接続資格情報の権限を明記することを提案します。閲覧専用のAPI文書と、登録・認証・アプリ管理の機能では必要な公開範囲が異なります。ただし、静的な代替ページを出すだけで元のPHPポータルを別URLから公開し続ければ、攻撃面は残ります。停止したつもりの入口をDNS、ロードバランサー、直接アクセス経路から確認します。

告知にある設定変更は更新までの露出を減らす暫定策です。PHP公式は、アプリケーションや拡張などによって到達経路が変わり、汎用的な設定変更ですべてを防ぐことはできないと説明しています。本稿では、memory_limitなどの値を一律に配布する代わりに、公式手順の対象条件を確認し、修正版への更新または公開制限を優先する判断を勧めます。

更新前の侵害とApigee接続資格情報を調べる

ポータルのPHPが侵害されると、そのプロセスが参照できた設定や資格情報も調査対象になります。Googleは、PHP-FPMからのシェル等の起動、Webルートやファイル領域の改変、multipart要求に続く異常、PHPSESSIDの不正な値などを確認するよう案内しています。単一の文字列がないことを、侵害がなかった証明にはできません。

本サイトの提案として、脆弱な版で公開していた期間を確定し、アクセスログ、FPMログ、ファイル変更、ポータルからの接続を時系列に並べます。DB接続情報、Drupal管理者、Apigee接続用の資格情報は、それぞれ到達可能な範囲と失効手段を確認します。侵害の疑いが残る場合、新しい秘密情報を疑わしいVMへ入力せず、信頼できる管理経路と修正済み環境で切り替えます。

証拠保全と再構築の共通手順は「更新しても侵害は消えない｜Webサーバーの証拠保全と再構築ランブック」に整理しています。同記事は10月24日時点の恒久対策であり、今回のApigee固有の対象範囲やイメージ判定は本稿の告知確認を基準にしてください。

完了条件は今と次回の両方が安全であること

今回の対応では、外部要求を処理する全VM・全コンテナが修正済みであることに加え、増設、自動復旧、構成管理の再適用で古いPHPが戻らないことを確認します。併せて侵害の可能性を調査し、必要な資格情報の失効と再構築を記録します。単なるイメージ更新手順ではなく、認証不要RCEへの露出を継続して閉じることが目的です。

Google Cloud全般の自動更新と利用者作業の区別は、10月23日に確認した「Google CloudがPHP緊急対応を更新した際の記事」も参考になります。今回のポータルは、その一般論に加えて既存VMとマネージドグループの作成元を具体的に分ける必要があるケースです。

調査範囲の留保として、今回の確認ではCISAの告知一覧が403で取得できませんでした。同機関の新着・更新は未確認であり、新着なしとは判断していません。本稿の対象範囲と対処は、直接確認したGoogle CloudとPHP開発元の資料に基づきます。