Uma vulnerabilidade em um dos principais serviços de banco de dados da Microsoft expôs um dos riscos mais sensíveis da computação em nuvem: a possibilidade de uma falha romper a barreira que deveria manter os dados de diferentes clientes completamente separados.
Pesquisadores da Wiz Research descobriram uma cadeia de ataque no Azure Cosmos DB capaz de escapar do ambiente isolado utilizado para executar consultas da API Gremlin e alcançar componentes internos da infraestrutura da Microsoft.
O problema, batizado de CosmosEscape, permitiu aos pesquisadores chegar a um segredo compartilhado pela plataforma que eles chamaram de Cosmos Master Key.
A partir desse segredo, seria possível solicitar a chave primária de uma conta específica do Cosmos DB e obter acesso completo de leitura e escrita ao banco correspondente.
O alcance potencial era enorme: segundo a Wiz, a técnica poderia atingir qualquer banco de dados do serviço, incluindo ambientes de clientes e bancos utilizados internamente pela própria Microsoft.
A Microsoft corrigiu o problema e, segundo as informações divulgadas até agora, não encontrou evidências de que a vulnerabilidade tenha sido explorada fora da pesquisa controlada.
Ataque começava em um banco controlado pelo pesquisador
Um dos aspectos mais relevantes do CosmosEscape é que o ataque não começava necessariamente comprometendo a conta de outra organização.
Os pesquisadores criaram seu próprio ambiente Cosmos DB utilizando a API Gremlin, voltada ao trabalho com bancos de dados em formato de grafos.
O Cosmos DB possui mecanismos para impedir que consultas executadas por clientes ultrapassem determinados limites.
Esse tipo de isolamento é fundamental em serviços de nuvem multi-tenant.
Diversos clientes compartilham componentes da infraestrutura física e lógica, mas cada organização precisa permanecer isolada das demais.
A Wiz descobriu uma forma de escapar desse ambiente restrito.
Sandbox escape abriu caminho para execução de código
O mecanismo utilizado pelo Cosmos DB para processar consultas Gremlin convertia determinadas operações para código .NET executado dentro de um ambiente controlado.
Os pesquisadores descobriram que as restrições desse sandbox não impediam adequadamente determinados recursos de reflection do .NET.
A partir daí, conseguiram construir operações que permitiram avançar até execução de código no componente responsável pelo processamento das consultas.
O problema já seria significativo se terminasse nesse ponto.
Mas a investigação revelou algo muito mais poderoso.
Pesquisadores encontraram uma chave da plataforma
Ao analisar o ambiente alcançado após o sandbox escape, a equipe encontrou credenciais que davam acesso ao que chamou de Cosmos Master Key.
Não se tratava da chave de um cliente específico.
Era um segredo utilizado pela própria infraestrutura da plataforma.
Segundo a Wiz, esse segredo permitia duas capacidades particularmente críticas: identificar contas existentes no serviço e obter, sob demanda, a chave primária de uma conta Cosmos DB.
Isso transformou uma vulnerabilidade localizada na API Gremlin em um problema potencialmente sistêmico.
Chave primária significa controle sobre o banco
As contas do Azure Cosmos DB podem utilizar chaves para autenticação.
Quem possui a chave primária de leitura e escrita de determinada conta pode realizar operações altamente privilegiadas sobre seus dados.
O CosmosEscape permitiria usar o segredo da plataforma para chegar justamente a essas chaves.
O resultado seria acesso de leitura e escrita ao banco escolhido pelos pesquisadores.
A equipe demonstrou a técnica de maneira controlada utilizando contas próprias para evitar acessar informações pertencentes a clientes reais.
Nem bancos privados estavam necessariamente protegidos
Um aspecto particularmente importante da descoberta é que controles tradicionais de exposição à internet não eliminariam necessariamente o risco dessa cadeia.
Isso acontece porque o ataque era executado a partir da própria infraestrutura do serviço.
A vulnerabilidade estava na camada de isolamento do provedor, e não simplesmente em uma porta deixada aberta por determinado cliente.
Esse é um exemplo clássico da diferença entre vulnerabilidades de configuração do usuário e vulnerabilidades na infraestrutura do provedor de nuvem.
No primeiro caso, o cliente pode corrigir diretamente o problema.
No segundo, a correção depende essencialmente do fornecedor.
Microsoft também utiliza Cosmos DB
O alcance potencial ganhou ainda mais relevância porque a própria Microsoft utiliza Cosmos DB em seus serviços.
Segundo a pesquisa da Wiz, bancos relacionados a serviços internos da companhia também estavam dentro do universo que tecnicamente poderia ser alcançado pela vulnerabilidade.
Os pesquisadores não afirmam ter acessado informações desses sistemas.
A demonstração indica o alcance potencial da falha, e essa distinção é importante.
Não existe evidência pública de que dados desses serviços tenham sido efetivamente comprometidos.
Falha foi descoberta em novembro de 2025
Embora a divulgação pública tenha ocorrido em julho de 2026, a vulnerabilidade já estava sendo tratada havia meses.
A Wiz informou o problema à Microsoft em 20 de novembro de 2025.
A Microsoft confirmou o recebimento no mesmo dia.
Dois dias depois, em 22 de novembro, a empresa implantou uma correção emergencial para bloquear o caminho utilizado na exploração.
Paralelamente, começou a trabalhar em uma solução arquitetural mais abrangente.
Correção definitiva levou meses
A resposta imediata interrompeu a cadeia conhecida de exploração, mas a Microsoft continuou modificando a arquitetura relacionada ao problema.
Segundo a linha do tempo publicada pela Wiz, a implantação da correção de longo prazo em todas as regiões foi concluída em julho de 2026.
A solução também eliminou a dependência daquele segredo compartilhado da forma explorada pelos pesquisadores.
A divulgação pública aconteceu em 30 de julho.
Clientes não precisam instalar um patch
Existe uma diferença importante entre o CosmosEscape e uma vulnerabilidade tradicional de software empresarial.
O Azure Cosmos DB é um serviço gerenciado.
A parte vulnerável estava na infraestrutura operada pela Microsoft.
Isso significa que não existe um pacote que cada administrador precise baixar e instalar em seus servidores para corrigir especificamente o CosmosEscape.
A remediação foi feita pela Microsoft no próprio serviço.
Esse modelo é uma das vantagens dos serviços gerenciados: correções de infraestrutura podem ser distribuídas centralmente.
Ao mesmo tempo, evidencia uma característica do modelo de responsabilidade compartilhada: determinadas vulnerabilidades simplesmente estão fora do alcance direto do cliente.
Microsoft não encontrou exploração maliciosa
Até o momento, não há indicação pública de comprometimento de clientes provocado pelo CosmosEscape.
A Microsoft informou não ter encontrado evidências de acesso não autorizado além das atividades realizadas pelos pesquisadores durante a descoberta.
Isso muda significativamente a interpretação do episódio.
Estamos diante da divulgação de uma vulnerabilidade crítica já corrigida, e não da confirmação de um vazamento envolvendo todos os clientes do Cosmos DB.
Dizer que “todos os bancos foram invadidos”, portanto, seria incorreto.
O que existiu foi uma cadeia técnica capaz de potencialmente chegar a qualquer um deles.
Por que uma única chave é tão perigosa?
O episódio traz novamente à discussão um princípio fundamental de segurança: evitar segredos com privilégios excessivamente amplos.
Imagine milhares de cofres diferentes.
Cada cliente possui sua própria chave.
O isolamento parece adequado.
Mas existe uma chave superior capaz de solicitar ou gerar acesso para todos eles.
Essa chave passa a representar um ponto extremamente valioso.
Se for comprometida, a separação existente nas camadas inferiores perde parte de sua eficácia.
O CosmosEscape mostrou uma versão desse problema aplicada à escala de um serviço global de nuvem.
Não é a primeira descoberta grave no Cosmos DB
A Wiz já havia revelado uma vulnerabilidade importante no Azure Cosmos DB em 2021.
Na época, o problema ficou conhecido como ChaosDB e estava relacionado ao recurso Jupyter Notebook.
Aquela vulnerabilidade também poderia permitir acesso indevido a bancos de outros clientes em determinadas circunstâncias.
Os dois casos são tecnicamente diferentes.
Ainda assim, ambos evidenciam a importância do isolamento entre tenants em serviços de nuvem.
Quando uma plataforma atende milhares de organizações simultaneamente, uma falha nessa fronteira pode assumir uma dimensão muito maior do que uma vulnerabilidade encontrada em um servidor convencional.
O risco do ambiente multi-tenant
Boa parte da computação em nuvem funciona justamente porque recursos podem ser compartilhados de maneira eficiente.
Máquinas, redes, sistemas de armazenamento e componentes de controle atendem diferentes organizações.
A segurança desse modelo depende de uma premissa fundamental:
um cliente nunca deve conseguir atravessar a fronteira que o separa dos demais.
O CosmosEscape demonstrou o que pode acontecer quando essa barreira é quebrada.
Um atacante começaria dentro de uma conta legítima que ele próprio controla e avançaria para uma camada compartilhada da infraestrutura.
Isso torna vulnerabilidades de cross-tenant access algumas das descobertas mais importantes na segurança de cloud.
IA ajudou na descoberta
Existe ainda um detalhe interessante na pesquisa.
Segundo a Wiz, uma versão inicial do seu pesquisador de vulnerabilidades baseado em inteligência artificial, chamado Atlas, auxiliou no trabalho que levou à descoberta.
O episódio, portanto, reúne duas tendências relevantes da cibersegurança atual.
De um lado, infraestruturas de nuvem cada vez mais complexas.
Do outro, ferramentas de IA ganhando capacidade para ajudar pesquisadores a encontrar vulnerabilidades que podem permanecer escondidas em sistemas altamente especializados.
Essa mesma evolução também significa que atacantes poderão utilizar ferramentas semelhantes.
O que empresas brasileiras podem aprender
Não há evidência de que organizações brasileiras tenham sido comprometidas pelo CosmosEscape.
O caso, entretanto, é relevante para qualquer empresa que dependa de serviços gerenciados de nuvem.
A primeira lição é que mover uma aplicação para cloud não elimina riscos de infraestrutura.
Parte deles apenas passa a ser administrada pelo provedor.
A segunda é evitar depender exclusivamente de uma única barreira de segurança.
Identidade, privilégios mínimos, segmentação, monitoramento e registros de auditoria continuam importantes mesmo quando o banco está hospedado em um serviço gerenciado.
Também vale avaliar, quando compatível com a arquitetura, modelos baseados em identidade e RBAC em vez da dependência indiscriminada de chaves estáticas.
CosmosEscape mostra o tamanho do risco sistêmico na nuvem
O CosmosEscape não resultou, até onde se sabe publicamente, em um comprometimento em massa do Azure Cosmos DB.
Mas sua importância está justamente no que poderia ter acontecido.
Uma única cadeia de vulnerabilidades permitiu sair de uma consulta criada dentro de uma conta controlada pelos pesquisadores, executar código em infraestrutura compartilhada e alcançar um segredo com privilégios sobre toda a plataforma.
Em ambientes de nuvem, vulnerabilidades assim possuem uma característica particular: o raio de impacto potencial deixa de ser um servidor ou uma organização.
Pode chegar à própria plataforma.
E é por isso que isolamento entre clientes, gestão de segredos e arquitetura de privilégios continuam sendo alguns dos pontos mais críticos da segurança dos grandes provedores de cloud.
