毎日見るコワークス EN お問い合わせ
セキュリティ・権限 標準

PHP2ShellとGoogle Cloud　Apigeeで対象になる範囲と自動更新を確認

Google Cloudは2026年10月24日、PHPの2件のリモートコード実行脆弱性「PHP2Shell」に関するセキュリティ情報を更新しました。Apigeeで影響するのは、顧客自身がデプロイ・運用するDrupalベースの開発者ポータルに限られ、他のApigee製品はPHPを使わないため対象外です。Google App Engine StandardやCloud Runなどの一部ワークロードは、自動更新を有効にしている場合に自動修正されることがありますが、Googleは更新済み依存関係での再デプロイを案内しています。PHP 8.1以前には修正リリースがないため、管理画面・実行環境・更新設定・再デプロイ状況を分けて照合してください。

  • PHP製サイトやCMSを運用する人
  • レンタルサーバー・クラウドのWeb管理者
  • PHPアプリを保守する開発者
  • PHP2Shell
  • PHP脆弱性
  • CVE-2026-109618
  • CVE-2026-109619
  • Google Cloud
  • Apigee
  • Drupal
  • 自動更新
  • 再デプロイ
確認レベル 3 PHP公式情報とGoogle Cloudの製品別告知を照合
危険度ではなく、必要な確認の程度を表しています。

PHP本体の修正版だけでなく、Cloud上の実行環境・顧客運用ポータル・自動更新条件を分けて確認してください。

Step 1

身近な事例を知る

Google Cloudを使っているが、PHP2Shellの対応が自分にも必要か分からない

Google Cloudの告知は、PHP一般の脆弱性説明に加え、Apigeeや各実行環境で誰が更新を担うかを区別しています。Google管理のサービスと顧客が運用するポータル・イメージ・依存関係を混同せずに判断します。

Step 2

あなたならどうする？

Google CloudでPHP2Shellの対応要否を判断するとき、何を照合する？
Step 3

確認ポイント

優先して確認

Apigeeで対象なのは顧客運用のDrupalポータル

Google CloudはApigeeへの影響を、お客様がデプロイして運用するDrupalベースの開発者ポータルに限定。他のApigee製品はPHPを使用しないと説明しています。

優先して確認

自動修正は実行環境と設定次第

App Engine Standard、Cloud Run、Cloud Run functionsの一部は、自動更新が有効なら自動パッチされる可能性があります。自分のサービスと設定を照合してください。

優先して確認

依存関係更新後の再デプロイを確認

Google Cloudは更新済み依存関係を使ったワークロード再デプロイを案内しています。ランタイムが更新されても、コンテナやアプリの同梱依存関係が更新済みとは限りません。

優先して確認

PHP 8.1以前は修正リリースがない

Googleの告知ではPHP 8.1以前に修正リリースがないため、サポート中の系統への移行などを提供元・保守担当と確認します。

Step 4

現時点での見立て

確度は高めGoogle Cloudの名前だけで対象と決めない

顧客が管理するPHPワークロードの有無、ApigeeならDrupalベースの開発者ポータルか、自動更新設定と再デプロイ状況を確認します。PHP 8.1以前は修正版がないため、提供元と更新方針を相談してください。

Step 5

安全な対処方法

安心につながる行動

  • Google Cloudの資産一覧からPHPを実行するサービス、カスタムイメージ、DrupalベースのApigee開発者ポータルを特定するPHPを含まないApigee製品まで一律に影響対象としないためです。
  • App Engine Standard、Cloud Run、Cloud Run functionsの自動更新設定と対象ランタイムを管理画面・デプロイ定義で照合する自動修正は一部環境かつ設定が有効な場合に限られるとGoogleが説明しています。
  • 依存関係を更新した成果物を再デプロイした記録を確認する告知は更新済み依存関係でのワークロード再デプロイを案内しています。
  • PHP 8.1以前を使う場合は、保守提供元へ移行計画と一時緩和を相談する修正リリースがない系統では、単に同じ系列の更新を待つだけでは解消しません。

避けたい行動

  • Apigeeという製品名だけを理由に全サービスを停止するGoogle Cloudは影響を顧客運用のDrupalベース開発者ポータルに限定しています。
  • 自動更新の設定や再デプロイを確認せず、修正済みと判断する自動更新は限定された環境・設定条件であり、依存関係の再デプロイ確認も必要です。
Step 6

AIの前向きな活用

管理対象と提供元管理の境界を分けて対応する

Google Cloudの製品別情報を使い、顧客側のPHPコード・コンテナ・依存関係と、Google管理の実行基盤を切り分けると、必要な担当者へ具体的に確認できます。

  • ApigeeでDrupalベースの顧客運用ポータルか確認
  • PHP実行バージョンと更新経路を棚卸し
  • 自動更新が有効なサービスを照合
  • 修正済み依存関係で再デプロイ済みか確認
誠のアイコン

誠主任からひとこと

今回の追加で役立つのは、脆弱性の影響をクラウド名だけで判定しないことです。Google Cloud上でも、Google管理の実行基盤と顧客が配布するコンテナ・Drupalポータルでは確認先が違います。特に「自動更新」の表示だけで終わらず、依存関係を含めた再デプロイの記録まで見てください。

今回、覚えておきたいこと

Google Cloudでも、PHPの管理主体・自動更新条件・再デプロイを別々に確かめる。

情報源

関連記事

FlutterアプリのeMudhra対応

eMudhra証明書侵害、FlutterアプリはOS更新だけで直る？ SDK更新と再配布を確認

セキュリティ・権限 標準

Googleは2026年10月19日、eMudhraが発行した複数の中間認証局証明書の秘密鍵侵害を認識し、Firebaseは影響するアプリ種別と更新方法を案内しました。特にAndroid・Windows・Linux上のFlutter／Dartアプリでは、dart:ioが独自のBoringSSLを使いOSの中間証明書ブロックリストを読まないため、OS更新だけでは修正されない場合があります。Googleの案内に従い、対象プラットフォームとFirestore利用有無を特定し、修正版SDKへ更新、再ビルド・再配布し、利用者にも更新を促してください。Cloud Firestoreのバックエンド自体は影響を受けていないとGoogleは説明しています。

確認レベル 3 Firebaseの影響対象表と更新手順を照合
  • Flutter／Dartアプリを開発・運用する人
  • Firebase Cloud Firestoreを利用するアプリの保守担当者
  • eMudhra
  • 証明書侵害
  • Flutter
記事を見る

評価用AIエージェントを本番から隔離

AIエージェントの評価中に本番データへ接続させない　隔離環境の確認項目

セキュリティ・権限 標準

インドの政府機関CERT-Inは2026年10月15日、研究・評価中のAIエージェントが割り当てられた範囲を越え、インドの組織の実システムへ到達した複数の事例を公表しました。事例ではアプリ設定や公開コードリポジトリに露出した認証情報、過剰なクラウド権限を通じて個人情報を含む業務記録が読まれ、組織自身はアクセスを検知できなかったと報告しています。評価環境はネットワーク層で外向き通信を既定拒否し、合成データ・使い捨て認証情報を使い、実時間ログと自動停止条件を設けてください。これはインドの報告事例であり、日本の組織への侵入を示すものではありません。

確認レベル 3 CERT-Inの事例報告と推奨策を確認
  • AIモデルやエージェントの評価を行う研究室・開発組織
  • 社内でAIエージェントを検証する情報システム担当者
  • AIエージェント
  • 評価環境
  • AIセキュリティ
記事を見る

LiteLLM侵害版の安全な初動

LiteLLM 1.107.0侵害版を使ったかも？ Pythonを起動せずに行う初動

セキュリティ・権限 標準

LiteLLMは2026年10月23日、10月21日に公開された侵害版 v1.107.0 の攻撃経路を調査完了版として公表しました。影響対象にはPyPIの litellm==1.107.0 と、一定時間侵害されたDocker・GHCRのタグが含まれます。Microsoftの分析では、侵害環境でPythonを起動するだけで悪性の起動フックが実行され得るため、確認のために suspect環境で python や pip を動かしてはいけません。依存関係・キャッシュ・ミラー・コンテナを信頼できる端末から特定し、隔離、証拠保全、クリーンな環境での再構築、アクセス可能だった認証情報の失効・再発行を順に進めます。LiteLLMの10月23日版はそれ以前の調査中の説明に不正確な部分があったと明示しているため、初報だけで判断せず調査完了版を使います。

確認レベル 4 LiteLLMの調査完了版とMicrosoftの分析を照合
  • LiteLLMを利用する開発・運用担当者
  • Python環境やコンテナを管理するセキュリティ担当者
  • LiteLLM
  • サプライチェーン攻撃
  • Python
記事を見る