【核心提要】
【正文报道】
近日，网络安全研究机构 Wiz Research 公布了一项名为 "CosmosEscape" 的重大漏洞利用链。该漏洞存在于微软的 Azure Cosmos DB 服务中，攻击者可以通过特定的 Gremlin 查询绕过预设的安全限制，获取到能够访问该服务上所有数据库的“Cosmos 主密钥”（Cosmos Master Key）。这一关键漏洞不仅涉及技术层面的安全漏洞，更揭示了多租户（Multi-tenant）系统在架构设计上的深层次风险：即当一个平台级的全局密钥存在时，一旦被攻破，受影响的客户往往处于完全无能为力的境地。
技术路径与核心威胁 该攻击链始于对 Gremlin 数据库的一条特制查询。在正常情况下，Cosmos DB 会将此类查询编译为 .NET 代码并施加限制以确保其仅在预定的范围内运行。然而，由于系统未能充分考虑 .NET 反射（Reflection）机制的漏洞，攻击者能够成功“逃逸”出沙箱，并在数据库网关（DB Gateway）上执行代码。
由于 DB Gateway 是处理客户查询的多租户核心服务，一旦被攻破，攻击者即可获取到所谓的“Cosmos 主密钥”。这是一个具有极高权限的平台级密钥，可以用于跨越不同订阅和租户标识，枚举并访问任何 Cosmos DB 账户的主密钥。考虑到 Cosmos DB 是支撑 Microsoft Teams 和 Copilot 等核心服务的底层基础设施，该漏洞的影响范围甚至延伸到了微软自身的后端系统。
修复过程与行业争议 根据披露信息，Wiz 于 2025 年 11 月 20 日向微软报告了此问题。微软在当天确认后，于两天内通过“热修复”封堵了存在漏洞的 Gremlin 入口点。然而，要彻底移除该平台级密钥并重构整个凭据模型，直到 2026 年 7 月才在所有区域完成。
这一长达数月的时间跨度引发了业内广泛讨论。支持者认为，必须区分“热修复”与“架构重建”。由于网关服务涉及数以万计的客户且高度复杂，重构一个被微软自身高度依赖的底层查询执行引擎不可能一蹴而就。与此同时，该事件也再次引发了关于“共同责任模型”（Shared Responsibility Model）的讨论：由于漏洞完全存在于云服务提供商（CSP）的基础设施中，用户端无法采取任何防护措施，这使得客户必须完全信任供应商提供的修复声明。
透明度与警示意义 值得注意的是，此次事件在公开记录中缺乏典型的安全指标，如 CVE 编号、CVSS 评分或明确的暴露时间窗口。这种“静默处理”反映了超大规模云服务商在处理核心基础设施漏洞时的特殊策略。
对于平台架构师而言，"CosmosEscape" 提供了一个深刻的警示：在构建托管式多租户服务时，必须审视系统中是否存在任何能够跨越多个租户边界的凭证。如果存在此类“全局密钥”，那么移除它的代价和所需的时间往往是巨大的。微软给出的答案是：先用两天时间通过补丁阻断攻击路径，再花费数月时间在幕后完成架构重构。
【小编观点】 "CosmosEscape" 的真正警示意义在于“信任的不对称性”。在云原生时代，用户高度依赖云服务商提供的基础设施安全。当漏洞发生在底层多租户隔离层时，客户往往处于信息不对称的弱势地位。此案例提醒开发者和架构师：在设计系统时，应尽可能消除任何能够跨越租户边界的“上帝钥匙”，因为一旦这些密钥存在，修复它们的代价往往是巨大的，且过程对用户透明度极低。
背景链接： 原文链接：https://www.infoq.com/news/...
暂无回复，快来抢沙发吧！
本次需消耗银元：
100
当前账户余额: 0 银元
【核心提要】
【正文报道】
近日，网络安全研究机构 Wiz Research 公布了一项名为 "CosmosEscape" 的重大漏洞利用链。该漏洞存在于微软的 Azure Cosmos DB 服务中，攻击者可以通过特定的 Gremlin 查询绕过预设的安全限制，获取到能够访问该服务上所有数据库的“Cosmos 主密钥”（Cosmos Master Key）。这一关键漏洞不仅涉及技术层面的安全漏洞，更揭示了多租户（Multi-tenant）系统在架构设计上的深层次风险：即当一个平台级的全局密钥存在时，一旦被攻破，受影响的客户往往处于完全无能为力的境地。
技术路径与核心威胁
该攻击链始于对 Gremlin 数据库的一条特制查询。在正常情况下，Cosmos DB 会将此类查询编译为 .NET 代码并施加限制以确保其仅在预定的范围内运行。然而，由于系统未能充分考虑 .NET 反射（Reflection）机制的漏洞，攻击者能够成功“逃逸”出沙箱，并在数据库网关（DB Gateway）上执行代码。
由于 DB Gateway 是处理客户查询的多租户核心服务，一旦被攻破，攻击者即可获取到所谓的“Cosmos 主密钥”。这是一个具有极高权限的平台级密钥，可以用于跨越不同订阅和租户标识，枚举并访问任何 Cosmos DB 账户的主密钥。考虑到 Cosmos DB 是支撑 Microsoft Teams 和 Copilot 等核心服务的底层基础设施，该漏洞的影响范围甚至延伸到了微软自身的后端系统。
修复过程与行业争议
根据披露信息，Wiz 于 2025 年 11 月 20 日向微软报告了此问题。微软在当天确认后，于两天内通过“热修复”封堵了存在漏洞的 Gremlin 入口点。然而，要彻底移除该平台级密钥并重构整个凭据模型，直到 2026 年 7 月才在所有区域完成。
这一长达数月的时间跨度引发了业内广泛讨论。支持者认为，必须区分“热修复”与“架构重建”。由于网关服务涉及数以万计的客户且高度复杂，重构一个被微软自身高度依赖的底层查询执行引擎不可能一蹴而就。与此同时，该事件也再次引发了关于“共同责任模型”（Shared Responsibility Model）的讨论：由于漏洞完全存在于云服务提供商（CSP）的基础设施中，用户端无法采取任何防护措施，这使得客户必须完全信任供应商提供的修复声明。
透明度与警示意义
值得注意的是，此次事件在公开记录中缺乏典型的安全指标，如 CVE 编号、CVSS 评分或明确的暴露时间窗口。这种“静默处理”反映了超大规模云服务商在处理核心基础设施漏洞时的特殊策略。
对于平台架构师而言，"CosmosEscape" 提供了一个深刻的警示：在构建托管式多租户服务时，必须审视系统中是否存在任何能够跨越多个租户边界的凭证。如果存在此类“全局密钥”，那么移除它的代价和所需的时间往往是巨大的。微软给出的答案是：先用两天时间通过补丁阻断攻击路径，再花费数月时间在幕后完成架构重构。
【小编观点】
"CosmosEscape" 的真正警示意义在于“信任的不对称性”。在云原生时代，用户高度依赖云服务商提供的基础设施安全。当漏洞发生在底层多租户隔离层时，客户往往处于信息不对称的弱势地位。此案例提醒开发者和架构师：在设计系统时，应尽可能消除任何能够跨越租户边界的“上帝钥匙”，因为一旦这些密钥存在，修复它们的代价往往是巨大的，且过程对用户透明度极低。
背景链接：
原文链接：https://www.infoq.com/news/...