AzureのCosmos DBに最も危険な脆弱性 CVE-2026-66803、修正済みで対処不要

トップ/記事一覧/AzureのCosmos DBに最も危険な脆弱性 CVE-2026-66803、修正済みで対処不要

ニュース2026年7月31日公開本日更新

この記事のポイント

マイクロソフトのクラウド型データベース「Azure Cosmos DB」に、危険度が最大級（CVSS 10.0）の欠陥CVE-2026-66803が見つかりました。放置すれば他人のデータベースを丸ごと乗っ取られる恐れがありましたが、すでに提供元が修正を完了しており、利用者側の操作は不要です。悪用の報告もありません。

マイクロソフトのクラウド型データベース「Azure Cosmos DB」に、危険度が最大級（CVSS 10.0）の欠陥が見つかりました。管理番号はCVE-2026-66803。マイクロソフトは2026年7月30日に情報を公開しました。

先に結論を書きます。この欠陥はすでにマイクロソフト側の修正が完了しており、Azure Cosmos DBを使っている企業や開発者が自分で何かをする必要はありません。実際に悪用された形跡も報告されていません。Azure Cosmos DBはマイクロソフトが運用を丸ごと引き受ける「マネージドサービス」（利用者はサーバーの管理をせず、機能だけ使うクラウドサービス）のため、直し作業はすべてサーバー側で行われました。つまり、あなたが管理画面を開いてパッチを当てる、といった対応は不要です。

とはいえ、危険度10.0という数字は最上位で、内容も「他人のデータベースを丸ごと乗っ取れる恐れがあった」という重いものです。何が起きていたのか、なぜ利用者の操作が要らないのかを、順番に整理します。

CVE-2026-66803の概要

まず基本情報を表にまとめます。数値はアメリカ政府の脆弱性データベース（NVD）とマイクロソフトの公開情報に基づきます。

項目	内容
管理番号	CVE-2026-66803
危険度（CVSS）	10.0 / 最大（CRITICAL）
欠陥の種類	アクセス制御の不備（CWE-284）
影響	認証なしの攻撃者がネットワーク越しにコード実行
対象	Azure Cosmos DB （マイクロソフトのクラウドDB）
公開日	2026年7月30日
修正状況	マイクロソフトが修正完了（利用者の操作は不要）
悪用の有無	報告なし（KEV未登録）

Azure Cosmos DBは、世界中のアプリやサービスの裏側でデータを保管するデータベースです。マイクロソフト自身の「Teams」のメッセージや「Copilot」の利用データも一部ここに保存されており、規模の大きい基盤です。そこに危険度10.0の欠陥が見つかったため、「うちのサービスは大丈夫か」という不安が広がりました。この欠陥の詳細を最初に報告したのは、クラウドセキュリティ企業のWiz（ウィズ）で、同社は今回の一連の欠陥を「CosmosEscape（コスモスエスケープ）」と名付けています。

なお、NVDでの分析は執筆時点で「Awaiting Enrichment（追加情報の付与待ち）」の状態です。CVSSの数値や技術分類はマイクロソフトの申請値に基づくもので、NVD独自の詳細分析は今後追記される見込みです。

誰が狙い、何をする欠陥だったのか

今回の欠陥が狙われた場合、危ないのはクラウド基盤を専門に攻める、腕の立つ攻撃者や金銭目的の犯罪集団です。普通の利用者が誤って踏むような罠ではなく、クラウドの内部構造を深く理解した相手が、時間をかけて仕掛けるタイプの攻撃でした。

その相手がやろうとすることは、ひとことで言えば侵入の入り口を1つ手に入れることです。攻撃者はまず、誰でも作れる普通のCosmos DBアカウントを1つ用意します。そこから細工したデータ検索を送り込み、本来は自分の領域から出られないはずの仕切りを突破して、サービス全体のデータベースを開けられる「マスター鍵」を盗み出すという流れです。この鍵は、契約している会社が違っても、置いてある地域が違っても、どの顧客のデータベースでも開けてしまうものでした。

もし修正前に悪用されていたら、被害は「1社のデータ漏洩」では済みませんでした。同じ基盤に相乗りしている無関係な会社のデータまで、読み取りも書き換えも自由にされていた恐れがあります。サービスを使うエンドユーザーは自分の情報が抜かれ、システムを運用する企業は顧客データと信用を一度に失いかねない、というのが最悪の想定でした。幸い、Wizによればこの攻撃が実際に外部で使われた形跡はなく、研究目的の検証にとどまっています。

仕組み：1つの検索から「全部の鍵」まで

The Hacker Newsの報道とWizの技術解説によると、攻撃は複数の弱点をつなげた連鎖でした。順を追うと次のようになります。

入り口：Cosmos DBの検索機能の1つ「Gremlin（グレムリン）」に、細工した検索を投げる。この検索は内部でプログラム（.NETコード）に変換されて動く仕組みになっている。
仕切りの突破：本来は限られた処理しかできないよう制限されているが、その制限が「リフレクション」と呼ばれる特殊なプログラム機能を想定しておらず、ファイルの読み書きなど本来禁止のはずの操作ができてしまった。
踏み台の奪取：これを足がかりに、複数の顧客が共有する「DBゲートウェイ」（各データベースへの入り口を仲介する部品）の上で自由にプログラムを動かせる状態、つまりコード実行に到達した。
マスター鍵の入手：ゲートウェイ内部から、サービス全体で使われる署名鍵「Cosmos Master Key」を取り出せた。この鍵があれば、任意の顧客アカウントの正規キーを引き出せた。

問題の核心は、この「Cosmos Master Key」が特定の契約者・地域・データベース種別（SQL、MongoDB、Cassandra、Gremlinなど）に縛られていなかった点です。Tech Timesの報道によれば、1本の鍵ですべてを開けられる状態で、まさに「すべてを支配する1つの鍵」でした。Wizはこの成果を2026年8月6日開催のセキュリティ会議「Black Hat USA」で「One Key to Rule Them All」という題で発表する予定です。ネットワークで隔離した非公開のデータベースも、内部から仲介する部品が乗っ取られたため守り切れなかった、という点が特に厄介でした。

発見から修正までの流れ

この欠陥は表沙汰になる前に報告・修正が進んでいました。BleepingComputerの報道などをもとに時系列を整理します。

← スワイプで移動

報告からわずか2日で入り口をふさぎ、そこから約8ヶ月かけて設計レベルの根本修正まで終えた、という流れです。SC Mediaの報道も、修正がサービス横断の被害を防いだと伝えています。

利用者は何をすべきか

結論を繰り返します。この欠陥に対して、Azure Cosmos DBの利用者が行うべき作業はありません。マイクロソフトはサーバー側で修正を完了しており、パッチの適用や再起動、設定変更といった対応は不要です。Wizも公式に「no customer action is required（利用者の対応は不要）」と明記しています。マネージドサービスならではの利点で、利用者が気づかないうちに危険が取り除かれた形です。

キー（アクセス用の鍵）のローテーションについても、今回の欠陥のために慌てて回す必要はありません。根本原因だった「Cosmos Master Key」そのものが設計から撤廃されているためです。Cybersecurity Newsの報道でも、悪用の痕跡や顧客データへのアクセスは確認されていないとされています。

ただし、これは「今回のCVEへの対応が不要」という意味であって、日頃の備えまで不要というわけではありません。今回の件とは切り離した一般的なクラウド防御として、公開ネットワークからの直接アクセスを閉じてプライベート接続に寄せる、Entra ID（旧Azure AD）による認証と最小権限の割り当てを徹底する、といった設定はいつでも見直す価値があります。これらは今回の修正とは無関係に、普段からやっておくと安全度が上がる基本です。

同じAzureでは、少し前にも危険度10.0クラスの欠陥がまとめて公表され、やはり利用者の更新作業が不要だったケースがあります（Azure Key Vaultなど危険度10.0が6件、更新作業は不要）。クラウド側で完結する修正は珍しくなく、数字の大きさだけで過度に不安がる必要はありません。一方で、本当に攻撃が進行中の脆弱性は別です。実際に悪用されているものだけを集めた米政府のリストは、CISA KEVの日本語まとめで確認できます。今回のCVE-2026-66803は、そのリストには入っていません。

まとめ

CVE-2026-66803は、危険度こそ最大の10.0ですが、利用者側の対応が不要な脆弱性です。攻撃者が1つのアカウントから全顧客のデータベースを乗っ取れた恐れがある重い欠陥でしたが、Wizの報告を受けてマイクロソフトが48時間で入り口をふさぎ、2026年7月までに設計レベルの根本修正を終えています。実際に悪用された形跡はなく、KEVにも登録されていません。

やることは「ない」というのが今回の答えです。ニュースの見出しにある「10.0」「コード実行」という言葉に驚いた方も、Azure Cosmos DBを使っているなら、追加の作業は不要と受け止めて問題ありません。8月6日のBlack Hatで技術的な全容が明かされる予定なので、新しい事実が出れば追記します。

参照元

堀川慎

Backend Engineer / AWS / Django / Go