A revelação da vulnerabilidade CosmosEscape pela Wiz Research reacendeu debates profundos sobre a segurança e os limites do isolamento em sistemas de nuvem pública multi-tenant. A brecha permitia acesso de leitura e escrita a praticamente qualquer banco de dados no Azure Cosmos DB.
- A Wiz Research descobriu a 'CosmosEscape', uma vulnerabilidade crítica de bypass de sandbox no Azure Cosmos DB.
- A falha permitia execução de código remota (RCE) e acesso à 'Cosmos Master Key', expondo potencialmente dados de múltiplos clientes.
- Embora mitigado em dois dias, a eliminação total do risco de credenciais exigiu seis meses de rearquitetura por parte da Microsoft.
- O caso acende discussões sobre os limites do modelo de responsabilidade compartilhada e os riscos de isolamento em ambientes de nuvem multi-tenant.
A anatomia do ataque cosmosescape<\/h2>
O vetor de ataque teve início a partir de uma consulta maliciosa estruturada contra um banco de dados Gremlin sob controle dos próprios pesquisadores. O Azure Cosmos DB compilava as requisições Gremlin em código .NET sob restrições rígidas, projetadas para manter a execução sob controle. No entanto, as defesas não consideraram adequadamente as capacidades de reflexão (.NET reflection).
Ao burlar o sandbox original, os pesquisadores obtiveram execução remota de código (RCE) no DB Gateway — o serviço multi-tenant responsável por processar as requisições dos clientes. Esse acesso expôs o que a Wiz batizou de 'Cosmos Master Key': um segredo global capaz de recuperar a chave primária de qualquer conta do Cosmos DB e listar bancos de dados filtrados por assinaturas de tenants.
# publicidade
O potencial de estrago era gigantesco, uma vez que o Cosmos DB sustenta serviços internos vitais da própria Microsoft, como o Teams e o Copilot, estendendo o raio de impacto para além de clientes corporativos comuns.
A complexidade da remediação<\/h2>
A linha do tempo do incidente revela um contraste marcante entre mitigações emergenciais e correções definitivas de arquitetura. A Wiz notificou a Microsoft no dia 20 de novembro de 2025. O ponto de entrada vulnerável (a API do Gremlin) foi bloqueado provisoriamente por um hotfix em apenas dois dias.
Contudo, a eliminação definitiva da chave mestra global levou cerca de seis meses, sendo concluída apenas em julho de 2026. Esse tempo foi necessário para que a Microsoft desenvolvesse, testasse e distribuísse um modelo de credenciais totalmente novo por todas as regiões globais do Azure.
Profissionais do setor defenderam a postura da gigante de Redmond em relação ao tempo de resposta estrutural. Como o gateway utilizava a chave global para buscar as chaves privadas de cada conta ativa antes de repassar as requisições, alterar esse fluxo de autenticação exigiu reescrever o motor de execução de consultas de um ecossistema que atende dezenas de milhares de clientes globais.
O desafio da responsabilidade compartilhada<\/h2>
A repercussão da falha resgatou discussões acaloradas sobre o Modelo de Responsabilidade Compartilhada. Especialistas apontam que incidentes de quebra de isolamento de tenants ('tenant isolation break') evidenciam cenários onde o cliente fica totalmente de mãos atadas, sem qualquer mecanismo de auditoria ou defesa prévia disponível.
A dependência absoluta da palavra do provedor de nuvem quanto à eficácia das correções invisíveis de infraestrutura incomoda equipes de engenharia de plataforma. Quando uma quebra desse tipo ocorre na nuvem pública, o impacto é centralizado e em larga escala, gerando assimetrias de segurança difíceis de mitigar sem estratégias multi-cloud dispendiosas.
O que não está nos registros oficiais<\/h2>
Apesar da gravidade técnica da cadeia CosmosEscape, alguns detalhes chamaram a atenção do mercado pela ausência. Diferente de incidentes anteriores no mesmo serviço (como ChaosDB em 2021 e CosMiss em 2022), esta vulnerabilidade não recebeu um identificador CVE oficial nem pontuação CVSS.
Além disso, a ausência de um aviso formal do Microsoft Security Response Center (MSRC) e a falta de clareza sobre a janela de exposição de logs históricos deixaram o mercado sem métricas concretas do real escopo do risco no período anterior ao reporte.
Para arquitetos e times de plataforma, a grande lição do CosmosEscape não é apenas aplicar correções rápidas, mas questionar ativamente os provedores de serviços gerenciados sobre onde residem suas chaves de acesso globais e qual seria o custo real de desativá-las caso o isolamento venha a falhar.
| Fase | Ação Tomada | Tempo de Execução | Impacto para o Cliente |
|---|---|---|---|
| Identificação | Wiz reporta a vulnerabilidade à Microsoft | Imediato (20 de Nov de 2025) | Nenhum detectado |
| Mitigação Inicial | Hotfix bloqueia ponto de entrada Gremlin | 2 dias (22 de Nov de 2025) | Risco imediato contido |
| Remediação Definitiva | Nova arquitetura global de credenciais distribuída | 6 meses (Concluído em Julho de 2026) | Eliminação de credenciais compartilhadas globais |
Arraste para o lado para ver toda a tabela.
Perguntas frequentes (faq)<\/h2>
O que foi a vulnerabilidade cosmosescape?<\/h3>
Uma cadeia de vulnerabilidades descoberta pela Wiz Research no Azure Cosmos DB que permitia acesso total de leitura e escrita a qualquer banco de dados do serviço contornando o isolamento de locatários.
Os clientes do azure cosmos db precisam tomar alguma ação?<\/h3>
Não, a Microsoft já concluiu a remediação completa e implementou um novo modelo de credenciais robusto globalmente.
Por que a correção definitiva demorou seis meses para ser implementada?<\/h3>
Embora o hotfix temporário tenha sido aplicado em dois dias, a eliminação completa da chave mestra exigiu uma rearquitetura profunda do motor de consultas e de autenticação global do serviço.
