Wiz Research 在 Azure Cosmos DB 中发现一条代号 CosmosEscape 的利用链：攻击者只需提交一条特制 Gremlin 查询，就能逃逸沙箱、拿下 DB Gateway，并提取一个可读写任意租户数据库的平台级主密钥。微软两天内完成热修复，但真正移除这把"万能钥匙"、在全区域切换新凭据模型，用了整整 6 个月。
CosmosEscape 不是传统意义上的 SQL 注入。它的起点，是一条针对攻击者自己控制的 Gremlin 数据库发出的特制查询。为了把 Gremlin 查询限制在既定操作范围内，Cosmos DB 会把查询编译成 .NET 代码并放入沙箱——但限制条件没有充分考虑 .NET 反射的能力。
逃逸出沙箱之后，攻击者拿到了整个网关。
DB Gateway 是处理所有客户查询的多租户服务。在其上执行代码，意味着攻击者可以访问一个平台级密钥——Wiz 称之为 Cosmos Master Key。凭借这把钥匙，攻击者能够获取任意 Cosmos DB 账户的主密钥，并按订阅与租户标识符筛选、枚举所有数据库。
注：验证阶段攻击的是研究人员自己控制的 Gremlin 数据库；拿到主密钥后，影响范围扩大到平台上所有租户。换句话说，攻击者先用自家数据库完成“越狱”，再借用主钥匙打开每一扇门。
这次披露来自 Wiz Research——曾在 2021 年曝光 Azure ChaosDB 漏洞的研究团队。它把完整利用链交给微软的时间是 2025 年 11 月 20 日。接下来的过程，比漏洞本身更值得拆解。
注：时间线中最关键的分野是“热修复”与“根因移除”。阻断入口只用了两天；而让平台级主密钥从架构中真正消失，用了半年。前者控制损害，后者决定这个漏洞会不会“换个入口再回来”。
Cosmos DB 不是某个边缘产品的数据库。它是微软云上规模最大的多租户数据服务之一，也是 Microsoft Teams 与 Microsoft Copilot 等服务的底层支撑。AI 应用的对话上下文、文档状态、多租户数据，正运行在类似这样的基础设施之上。
AI 应用越依赖托管数据库，租户隔离就越接近一种信仰：客户相信自己的 token 不会跨越租户边界，相信平台级密钥不会被一条查询拿到。
CosmosEscape 让这个信仰出现了一道裂缝。
注：上图展示的是“依赖关系”，不是攻击路径。它的意思是：当平台级密钥被攻破时，所有建立在上面的 AI 服务都暴露在同一个风险半径里。
在技术社区里，对 CosmosEscape 的讨论几乎全部集中在三个问题上——没有多少人纠结漏洞利用细节，因为细节本身简洁得吓人。
这种漏洞不会出现在任何共同责任模型示意图中。作为 Cosmos DB 客户，我们不可能采取任何不同的措施来阻止它；它完全存在于微软的基础设施中。
争论焦点：租户隔离被突破，按照模型定义恰恰属于服务商一侧的责任。客户连“做点什么”的机会都没有。
这是微软自己和数以万计客户使用的重要服务；你不可能一夜之间凭感觉编程，给自己弄出一个新的数据库查询执行引擎。
争论焦点：移除主密钥意味着重建连微软自己都在依赖的凭据模型。两天热修复与六个月架构手术，根本不是同一件事。
超大规模云服务商一旦出问题，就真的会出大问题。
争论焦点：本地环境不会把管理 API 暴露在互联网上，也不存在跨租户横向移动；但大多数组织的补丁能力远不如超大规模云。这是一个不同的威胁模型，没有完美答案。
注：三条引语来自不同技术社区讨论中工程师的原话，均围绕“责任边界—修复成本—集中化风险”三个维度展开。
对平台安全团队来说，真正刺痛人的不是攻击链本身，而是公开记录里找不到的东西。没有 CVE、没有 CVSS、没有 MSRC 官方公告——这在一个被描述为“严重”级别的漏洞身上，并不常见。
因此，“没有证据表明客户受到利用”这句话的分母并不明确。
注：分母指评估暴露风险所必需的时间范围。不知道漏洞在系统中存在了多久，就无法判断“没有证据”到底意味着安全，还是意味着视野有限。
单条查询穿透租户隔离，平台级主密钥的移除用了半年——AI 时代的云数据库安全，核心命题已经从“打补丁”变成了“可信根密钥的生命周期管理”。
客户无法验证修复过程，只能选择信任谁。而对每一个运行在多租户云上的 AI 应用来说，最危险的或许不是某次漏洞利用，而是那些藏在架构深处、一旦泄露就覆盖所有人的万能钥匙——它们是否还躺在你的数据库里？
把下面三个问题发给你的云服务商。它们没有标准答案，但值得被认真回答。
注：这是给平台工程团队与 AI 应用负责人的自查清单。CosmosEscape 的完整攻击链已计划在 Black Hat USA 大会上公开演示，届时有更多技术细节可供复核。