Cloud Service Meshに高危険度DoS、管理方式で対応が分かれる

Google Cloudは2026年10月12日付のセキュリティ速報で、Cloud Service Meshで使われるEnvoy ProxyのDoS脆弱性「GCP-2026-067」を公表し、深刻度をHighとした。特定の経路書き換え条件でプロキシが異常終了し、通信の可用性に影響する可能性がある。

Cloud Service Meshの個別セキュリティ速報によると、影響を受けるin-cluster版はv1.29とv1.30で、修正版はそれぞれ1.29.8-asm.8と1.30.5-asm.8だ。in-cluster版のv1.28は今回の影響対象ではない。マネージド版は自動更新され、利用者による作業は不要とされている。

管理方式とバージョンで分かれる対応

更新の要否を分けるのは、Cloud Service Meshの管理方式と、稼働中の正確なバージョンだ。in-cluster版では影響を受ける系列を利用者が更新する。一方、マネージド版ではサービス側の自動更新が対応となる。今回の速報に基づく判定は次のとおりだ。

• in-cluster版 v1.30：影響対象。1.30.5-asm.8へ更新する。
• in-cluster版 v1.29：影響対象。1.29.8-asm.8へ更新する。
• in-cluster版 v1.28：今回の脆弱性の影響対象外。
• in-cluster版 v1.27以前：サポート終了。サポート対象版へ更新する。
• マネージド版：自動更新されるため、利用者の作業は不要。

系列名だけでは、更新を終えたかどうかを判断できない。たとえばv1.30系列を使っていても、稼働版が示された修正版より前なら更新対象となる。逆に、該当する修正版をすでに適用している環境に、同じ修正を重ねて適用する必要はない。確認すべきなのは「v1.30かどうか」だけではなく、パッチ番号を含む版の全体である。

v1.28の「影響対象外」は、この脆弱性に限った判断だ。ほかの脆弱性への対応状況や通常の更新方針まで示すものではない。また、v1.27以前については影響版として修正版が列挙されているのではなく、サポートが終了した版として更新が案内されている。両者は更新を考える理由が異なる。

同じ組織で複数のクラスタを運用している場合も、製品名だけで一括判定はできない。管理方式と稼働版がクラスタごとに異なれば、必要な対応も異なる。今回の公表が直接求める更新作業は、影響対象のin-cluster版に対するものだ。

Envoy Proxyが異常終了する条件

問題が起きるのは、経路の選択後にリクエストの経路情報が変わり、選択済みの経路との間に不整合が生じる場合だ。対象となる経路にはprefix_rewriteが設定されている。HTTPフィルタが経路選択後に「:path」ヘッダーを書き換え、その文字列が一致した経路プレフィックスより短くなると、Envoy Proxyが異常終了し得る。

速報が挙げるHTTPフィルタの例は、route_cache_action: RETAINを設定したext_procだ。これは発生し得る構成を具体的に示す例であり、ext_procを使う通信がすべて異常終了するという意味ではない。経路選択後の変更、prefix_rewriteの設定、変更後の経路の長さが組み合わさる点が重要になる。

Envoyの経路書き換え処理の修正では、取り除くプレフィックスが現在の経路より長いときにアサーションが起きたり、サイズ計算が不正になったりする処理を改めている。修正後の処理は長さを確認し、条件を満たさない書き換えを安全に扱う。Cloud Service Meshの速報が示した「変更後の:pathが一致済みプレフィックスより短い」という条件は、この不整合に対応する。

DoSとして問題になるのは、該当条件でプロキシのプロセスが終了し、そこを通る通信が妨げられ得ることだ。どの通信経路に条件が存在するかは、経路設定とHTTPフィルタの組み合わせに左右される。ただし、設定を調べて条件の有無を把握することと、影響対象版に示された修正を適用することは別の作業である。

マネージド版は自動更新、利用者の作業は不要

マネージド版に対する案内は、利用者の対応は不要で、システムが自動更新されるというものだ。in-cluster版向けに示された修正版番号を、マネージド版の利用者が指定して導入する手順は示されていない。管理方式の違いが、そのまま更新を実施する主体の違いになる。

「作業不要」は、個々の環境で更新が完了した時刻を示す表現ではない。公表されているのは利用者側の作業区分と自動更新の方針である。マネージド版の利用者は、この速報を理由にin-cluster版と同じ手動アップグレードを計画する必要はない。

この区分は、脆弱性の発生条件がマネージド版には存在しないという説明とも異なる。Cloud Service Meshの案内は、マネージド版についてサービス側で更新すると明記している。更新方法を判断する際には、脆弱性の識別子だけでなく、利用しているサービスがどちらの管理方式に属するかを確かめる必要がある。

in-cluster版は系列に合う修正版へ

影響を受けるin-cluster版では、稼働中の系列に対応する修正版へクラスタを更新する。修正版は系列ごとに別々に示されているため、片方の番号をもう片方の系列に当てはめることはできない。運用上の照合点は、管理方式、現在の系列、パッチ番号を含む現在の版、そして対応する更新先だ。

経路書き換えの条件を満たす設定が見つからない場合でも、速報が影響対象として挙げた系列に対する案内は修正版へのアップグレードである。設定の確認は、なぜ異常終了が起こり得るかを理解し、関係する通信経路を把握するために役立つ。提示された修正版の代わりとなる設定変更は、この速報には示されていない。

すでに修正版を適用しているクラスタと、同じ系列の旧パッチで稼働するクラスタは区別が必要だ。系列名が一致していても修正の適用状況は同じとは限らない。複数クラスタを管理する環境では、この違いが更新対象を絞る際の具体的な境界になる。

v1.27以前のin-cluster版には、今回列挙された系列別の修正版は示されていない。これらはサポート終了版として、サポート対象版への更新が案内されている。修正版の一覧に旧系列がないことを作業不要と受け取ると、サポートが切れたまま運用を続けることになる。

関連記事：

• ServiceNowにCVSS 10.0が3件、自己管理版は手動更新が必要
• Google検索のAIが旅行予約へ—日本では使える機能が分かれる
• Chrome更新を止めずに段階配信、管理者が決める三つの幅