[SUMMARY]Wiz揭露Azure Cosmos DB的CosmosEscape漏洞鏈，攻擊者原可藉Gremlin查詢逃逸沙箱、取得平台級金鑰並接管任意帳戶；Microsoft已修補，未見研究外濫用。[SUMMARY] <h2>事件說明</h2> <p>Wiz Research 揭露的 <st
Wiz Research 揭露的 CosmosEscape，是一條針對 Azure Cosmos DB 的重大漏洞鏈，核心風險在於攻擊者可利用自己建立的 Gremlin 資料庫提交特製查詢，進一步繞過服務內建隔離，最終取得任意 Cosmos DB 帳戶的主要存取金鑰，對資料執行完整讀寫操作。[2][5]
這起事件的影響不只限於單一租戶。根據研究描述，漏洞鏈最終可觸及平台級的簽章金鑰，也就是 Wiz 所稱的 Cosmos Master Key，因此攻擊者不必事先取得目標帳戶權限，就有機會列舉並鎖定特定企業的 Cosmos DB 帳戶，再進一步存取其資料庫。[1][2][5]
Wiz 於 2025 年 11 月 20 日向 Microsoft 通報，Microsoft 隨後在 48 小時內封鎖 Gremlin 查詢的攻擊入口；長期架構修正則在 2026 年 7 月完成並推送到所有 Azure 區域。[1][3][5] Microsoft 表示，調查存取紀錄後未發現研究測試以外的未授權活動，也未發現客戶資料遭讀取，客戶無須採取額外行動。[1][3][5]
CosmosEscape 的關鍵問題出在 Gremlin query 的處理流程。Cosmos DB 會先將查詢轉換成 .NET code 再執行，而研究人員發現其限制機制未能完整阻擋 .NET reflection，使得原本只應用於受控查詢的執行環境，意外具備讀寫檔案與觸發任意程式碼行為的可能性。[2][4]
一旦攻擊者在隔離環境中取得執行能力，就能進入代替客戶執行查詢的 database gateway。該閘道運作於多租戶叢集，並可透過叢集憑證取得一把簽章金鑰；Wiz 後續確認，這把金鑰並非僅限單一帳戶，而是適用於整個服務，因此被命名為 Cosmos Master Key。[2][5]
根據公開說明，這把金鑰不受單一帳戶、租戶、區域或資料庫介面限制，且可透過公開端點取得任意 Cosmos DB 帳戶的主要存取金鑰。[1][2][5] 由於主要金鑰本身具備完整讀寫權限，攻擊者一旦取得，即可直接讀取、修改或刪除目標資料庫內容。[2][5]
研究人員也指出，攻擊者還可能查詢 Cosmos DB 的帳戶設定目錄，其中包含帳戶名稱、Azure subscription ID、tenant ID、network restrictions 與標籤等資訊。[2][5] 這代表攻擊者不只可「拿到金鑰」，還能先行做目標識別與篩選，使攻擊流程更具針對性，而非單純的隨機掃描。[2][5]
值得注意的是，private endpoint 或限制外部網路連線的帳戶也可能受到影響。原因在於資料庫閘道本身負責執行網路限制；若閘道被控制，攻擊者可能從 Microsoft 服務內部連線到原本封閉的資料庫，甚至在帳戶設定被修改後，既有網路規則也可能被改動。[2][5]
從風險模型來看，CosmosEscape 的威脅屬於 cross-tenant 與 platform-wide 等級，因為攻擊面不是單一客戶的應用程式，而是託管在雲端平台內的共用服務機制。[1][3][5]
若攻擊成功，受影響對象可能涵蓋所有使用 Azure Cosmos DB 的客戶工作負載。[4][5] 這種設計層級的失誤，意味著影響半徑遠大於一般應用層漏洞，因為它直接碰觸到雲端資料庫的信任邊界。[3][4]
在資料面上，主要風險是任意資料庫帳戶被完整接管，進而產生資料外洩、竄改、刪除與橫向探索的可能性。[2][5] 在控制面上，攻擊者還可能透過目錄資訊找出具備特定租戶或訂閱特徵的資產，提升對高價值目標的命中率。[2][5]
雖然 Microsoft 表示未發現未授權利用跡象，但此類漏洞的嚴重性仍不容低估，因為它證明了雲端託管服務內部的隔離與金鑰模型，一旦失守，客戶再多的邏輯防線也可能被繞過。[1][3][5]
就本次事件而言，Microsoft 已完成修補，且官方表示客戶無需額外操作。[1][3][5] 但從防禦工程角度，企業仍應把這起事件視為雲端信任模型的警示，特別是對於高敏感資料庫與跨區多活架構，需重新檢視權限、網路與偵測設計。[2][5]
再者，建議企業將 private endpoint、網路限制與帳戶層級的存取控管視為互補而非單點依賴，因為本案顯示閘道層若遭入侵，原本依賴服務內部執行的邊界控制可能失去預期效果。[2][5] 對於重要資料庫，還應定期檢查訂閱、租戶與標籤等資產中繼資訊，避免因目錄資訊過於完整而降低攻擊者的搜尋成本。[2][5]
最後，安全團隊應把雲端原生服務納入威脅建模與事件演練，包含 sandbox escape、service-to-service authentication、以及 gateway compromise 等情境。[4][5] 這類風險通常不會反映在單一應用弱點掃描中，必須結合雲端供應商公告、存取審計與異常行為偵測，才能及早發現問題。[1][3][7]
5步驟修補清單