Uma vulnerabilidade crítica reforça a importância da segurança da informação na nuvem
A descoberta de uma grave falha no Azure Cosmos DB chamou a atenção da comunidade de cibersegurança ao demonstrar como uma vulnerabilidade em um serviço amplamente utilizado na nuvem poderia permitir o acesso a bancos de dados pertencentes a diferentes organizações. A pesquisa conduzida pela Wiz revelou uma cadeia de exploração batizada de CosmosEscape, capaz de escapar do ambiente isolado (sandbox) do mecanismo Gremlin e alcançar privilégios extremamente elevados dentro da infraestrutura da Microsoft.
Embora a Microsoft tenha informado que não encontrou evidências de exploração maliciosa contra clientes e tenha corrigido completamente o problema, o incidente evidencia como falhas em serviços compartilhados de nuvem podem representar riscos significativos para empresas que dependem dessas plataformas para armazenar informações críticas.
Neste artigo, você entenderá como a falha no Azure Cosmos DB funcionava, quais eram seus impactos, como a Microsoft respondeu ao incidente e quais lições podem ser aplicadas para fortalecer a segurança da informação em ambientes cloud.
O que é o Azure Cosmos DB?
O Azure Cosmos DB é o banco de dados NoSQL distribuído globalmente da Microsoft, projetado para oferecer alta disponibilidade, baixa latência e escalabilidade automática.
Ele suporta diferentes modelos de banco de dados por meio de APIs compatíveis com:
- SQL
- MongoDB
- Cassandra
- Gremlin (Graph)
- Table
Sua utilização é bastante ampla em aplicações corporativas, serviços em nuvem, Microsoft Teams e diversos recursos utilizados pelo Microsoft Copilot.
Como surgiu a falha no Azure Cosmos DB
Segundo a Wiz, toda a cadeia de exploração começava em um banco de dados Gremlin controlado pelo próprio atacante.
O invasor precisava possuir apenas uma conta legítima em um banco Gremlin para iniciar a exploração.
Escapando do sandbox
O mecanismo Gremlin do Cosmos DB converte consultas em código .NET antes de executá-las dentro de um ambiente isolado.
O problema identificado pelos pesquisadores estava justamente nesse isolamento.
As restrições impostas pelo sandbox não bloqueavam corretamente os recursos de reflexão (.NET Reflection), permitindo que consultas especialmente desenvolvidas realizassem operações inicialmente não autorizadas.
Essas operações evoluíam para:
- leitura de arquivos;
- gravação de arquivos;
- execução arbitrária de código.
Esse foi o primeiro passo da cadeia CosmosEscape.
Como a exploração evoluía
Após conseguir executar código no ambiente interno do serviço, os pesquisadores alcançaram um componente denominado Database Gateway.
O papel do Database Gateway
Esse gateway possui uma função extremamente sensível:
- processar consultas;
- encaminhar solicitações;
- recuperar credenciais necessárias para acesso aos bancos de dados.
Embora os bancos dos clientes não estivessem armazenados nesse gateway, ele possuía permissões suficientes para solicitar a chave principal de qualquer conta Cosmos DB.
Isso elevava drasticamente o impacto da vulnerabilidade.
A descoberta da Cosmos Master Key
Durante a pesquisa foi identificada uma chave de assinatura compartilhada pela plataforma.
Os pesquisadores chamaram esse segredo de:
Cosmos Master Key
Segundo a análise técnica, essa chave permitia recuperar as chaves primárias de contas distribuídas entre:
- diferentes tenants;
- diversas regiões;
- APIs SQL;
- MongoDB;
- Cassandra;
- Gremlin.
Na prática, isso representava um cenário extremamente crítico.
O impacto potencial da vulnerabilidade
Caso fosse explorada por criminosos, a falha no Azure Cosmos DB poderia permitir:
- leitura de dados;
- alteração de registros;
- exclusão de informações;
- criação de novos objetos;
- comprometimento de ambientes corporativos.
A Microsoft informa que as chaves primárias concedem controle total sobre uma conta Cosmos DB.
Isso significa acesso completo aos recursos associados.
Tabela comparativa – Antes e depois da exploração
| Etapa | Situação Inicial | Após exploração |
|---|---|---|
| Banco Gremlin | Controle apenas do banco do atacante | Execução de código |
| Gateway | Apenas processamento interno | Acesso privilegiado |
| Cosmos Master Key | Não acessível | Recuperação possível |
| Chaves Primárias | Restritas ao proprietário | Recuperáveis |
| Bancos de outras organizações | Isolados | Potencialmente acessíveis |
Config Store também ficou exposto
Outro componente identificado durante a pesquisa foi o Config Store.
Segundo a Wiz, esse banco regional armazenava diversas informações administrativas, incluindo:
- nomes de contas Cosmos DB;
- identificadores de assinatura;
- identificadores de tenants;
- configurações de rede;
- tags administrativas.
Essas informações poderiam facilitar significativamente um ataque direcionado.
Após localizar uma organização específica, seria possível solicitar sua chave primária utilizando a chave global descoberta.
Ambientes privados também poderiam ser afetados
Um dos aspectos mais preocupantes da falha no Azure Cosmos DB foi a possibilidade de atingir ambientes privados.
Mesmo contas protegidas por isolamento de rede poderiam ser acessadas porque o próprio Gateway executava operações internamente.
Isso significa que determinadas barreiras de rede poderiam ser contornadas utilizando privilégios internos do serviço.
Esse cenário demonstra como a segurança da informação em serviços de nuvem depende não apenas das configurações dos clientes, mas também da proteção da infraestrutura do provedor.
Microsoft Teams e Copilot estavam em risco?
A documentação pública da Microsoft informa que:
- o Microsoft Teams utiliza Cosmos DB para armazenamento de mensagens;
- o Microsoft Copilot armazena histórico de conversas e consultas nesse banco de dados.
Por isso, a Wiz afirmou que esses bancos poderiam ser potencialmente acessíveis durante um cenário de exploração.
Entretanto, os pesquisadores ressaltaram que não acessaram dados desses serviços.
Da mesma forma, a Microsoft declarou que:
- nenhum dado de clientes foi acessado;
- nenhuma atividade maliciosa foi identificada;
- nenhuma ação dos clientes é necessária.
Tabela comparativa – CosmosEscape x Vulnerabilidades anteriores
| Vulnerabilidade | Ano | Componente afetado | Impacto |
|---|---|---|---|
| ChaosDB | 2021 | Jupyter Notebook | Acesso entre tenants |
| CosMiss | 2022 | Jupyter Notebook | Escalada de privilégios |
| CosmosEscape | 2026 | Gremlin + Gateway | Recuperação potencial de chaves globais |
Como a Microsoft respondeu
Após receber o relatório da Wiz em novembro de 2025, a Microsoft respondeu rapidamente.
As ações ocorreram em diferentes etapas.
Correções imediatas
Entre elas:
- bloqueio da vulnerabilidade Gremlin em aproximadamente 48 horas;
- investigação interna;
- monitoramento de possíveis abusos.
Correções de longo prazo
Em julho de 2026 foram concluídas medidas adicionais, incluindo:
- eliminação da chave compartilhada da plataforma;
- reforço da arquitetura de autenticação;
- melhorias adicionais de proteção.
Segundo a Microsoft, nenhuma evidência de comprometimento de clientes foi encontrada.
Lições para a segurança da informação
Mesmo grandes provedores de nuvem podem apresentar vulnerabilidades críticas.
Por isso, organizações devem adotar estratégias de defesa em múltiplas camadas.
Entre as principais recomendações estão:
Monitoramento contínuo
Ferramentas de monitoramento ajudam a detectar atividades incomuns rapidamente.
Princípio do menor privilégio
Aplicações devem utilizar apenas as permissões estritamente necessárias.
Auditoria de acessos
Logs precisam ser analisados continuamente para identificar comportamentos suspeitos.
Gestão de vulnerabilidades
A aplicação rápida de correções continua sendo uma das medidas mais importantes para reduzir riscos.
Arquitetura Zero Trust
Mesmo serviços internos devem validar continuamente identidades e permissões.
O que podemos aprender com a falha no Azure Cosmos DB
A falha no Azure Cosmos DB reforça que plataformas de nuvem modernas são extremamente complexas e que pequenos erros em mecanismos internos podem gerar consequências amplas.
Embora a Microsoft tenha afirmado que não houve comprometimento de clientes e tenha eliminado completamente a vulnerabilidade, o caso CosmosEscape demonstra como pesquisas independentes continuam desempenhando papel fundamental na evolução da segurança da informação.
Para empresas que utilizam serviços em nuvem, a principal lição é clara: confiar no provedor não elimina a necessidade de monitoramento constante, boas práticas de segurança, gestão de riscos e processos contínuos de atualização. A combinação entre resposta rápida do fornecedor e maturidade das organizações é essencial para minimizar impactos diante de novas vulnerabilidades.
