Uma falha no Azure Cosmos DB poderia permitir que invasores acessassem e modificassem bancos de dados de diferentes clientes da nuvem da Microsoft. A vulnerabilidade atingia uma camada central do serviço e, segundo a Wiz, possibilitava obter as chaves de acesso de qualquer conta armazenada na plataforma.
A Microsoft corrigiu o problema e afirmou não ter encontrado indícios de exploração fora dos testes conduzidos pelos pesquisadores. A empresa também informou que nenhum dado de cliente foi acessado e que os usuários não precisam executar nenhuma ação.
O caso, chamado de CosmosEscape, mostra como uma falha na infraestrutura de um provedor pode ultrapassar a separação entre clientes e atingir aplicações construídas sobre o mesmo serviço.
O que aconteceu com o Azure Cosmos DB
O Azure Cosmos DB é um banco de dados NoSQL gerenciado pela Microsoft. Empresas usam o serviço para armazenar informações de aplicativos, lojas virtuais, chatbots, sistemas de recomendação e outras plataformas digitais.
A própria Microsoft também utiliza o Cosmos DB como parte da infraestrutura de produtos como Teams, Copilot e Entra ID.
Durante uma pesquisa de segurança, a Wiz identificou uma cadeia de vulnerabilidades na API Gremlin do Cosmos DB. Essa interface permite trabalhar com bancos de dados em formato de grafo, nos quais as informações aparecem conectadas por relações.
Os pesquisadores descobriram que uma consulta especialmente preparada conseguia escapar das restrições do mecanismo Gremlin e executar código na infraestrutura responsável pelo processamento das solicitações.
A partir desse ponto, a equipe alcançou componentes internos que deveriam permanecer isolados dos usuários do serviço.
Chave permitiria acessar contas de diferentes clientes
Depois de ultrapassar o ambiente restrito da API Gremlin, os pesquisadores encontraram uma chave usada internamente pela plataforma para recuperar as credenciais das contas.
A Wiz chamou esse segredo de Cosmos Master Key. Diferentemente de uma chave limitada a uma única organização, ela funcionava entre regiões, clientes e diferentes interfaces do Cosmos DB.
Com isso, um invasor poderia solicitar a chave primária de uma conta específica e obter acesso completo de leitura e gravação aos seus bancos de dados.
Além disso, os pesquisadores conseguiram consultar um diretório interno que reunia informações como nomes de contas, identificadores de assinaturas, tenants, configurações de rede e etiquetas.
Ao combinar essas duas capacidades, um invasor poderia localizar os bancos de determinada empresa e, depois, obter as credenciais necessárias para acessá-los.
Falha atingia até bancos de dados isolados da internet
Configurações privadas de rede normalmente reduzem a exposição de um banco de dados. No entanto, a vulnerabilidade estava dentro da própria infraestrutura responsável por aplicar esse isolamento.
Por isso, segundo a Wiz, o problema também poderia atingir contas configuradas para aceitar apenas conexões privadas ou provenientes de redes autorizadas.
Essa característica torna o caso especialmente grave. Mesmo uma empresa que tivesse bloqueado o acesso público poderia permanecer vulnerável porque o ataque ocorreria a partir de um componente confiável da própria plataforma.
O episódio reforça a importância de compreender os limites da segurança em serviços gerenciados. O cliente controla identidades, permissões, dados e configurações, mas o provedor continua responsável pela separação entre as organizações que compartilham a infraestrutura.
Microsoft corrigiu o problema em diferentes etapas
A Wiz comunicou a vulnerabilidade à Microsoft em 20 de novembro de 2025. Dois dias depois, a empresa aplicou uma correção emergencial para bloquear o ponto de entrada do ataque.
Em seguida, a Microsoft iniciou uma mudança mais ampla na arquitetura do serviço. A companhia concluiu a distribuição dessa correção de longo prazo em todas as regiões em julho de 2026.
Além de eliminar a chave que permitia o acesso entre contas, a Microsoft adicionou novas proteções à autenticação entre serviços, às redes internas e aos mecanismos de monitoramento.
Segundo a empresa, uma análise dos registros não encontrou atividades não autorizadas além dos testes da Wiz. Por esse motivo, a Microsoft afirma que os clientes não precisam trocar chaves nem modificar suas aplicações.
Caso lembra outra falha descoberta em 2021
Esta não foi a primeira vulnerabilidade grave encontrada pela Wiz no Azure Cosmos DB.
Em 2021, a empresa de segurança revelou a ChaosDB, uma falha que também poderia permitir acesso a bancos de dados de outros clientes. Naquele caso, o problema envolvia o recurso de notebooks Jupyter integrado ao serviço.
Apesar das diferenças técnicas, os dois episódios compartilham um risco: uma funcionalidade controlada pelo cliente conseguiu alcançar componentes privilegiados da plataforma.
Assim, o novo caso mostra que a separação entre clientes continua sendo um dos principais desafios dos serviços de nuvem compartilhados.
O que empresas podem aprender com o CosmosEscape
A Microsoft corrigiu a vulnerabilidade antes da divulgação pública, e não há evidências conhecidas de exploração. Ainda assim, empresas não devem concluir que podem transferir toda a segurança ao provedor de nuvem.
Primeiramente, a organização precisa limitar as permissões de usuários, aplicações e integrações. Mesmo quando uma credencial oferece acesso completo, poucos sistemas devem ter autorização para utilizá-la.
A autenticação em APIs também precisa usar tokens com validade limitada, escopos específicos e mecanismos rápidos de revogação.
Além disso, as equipes devem registrar consultas, mudanças em dados e tentativas de acesso. O monitoramento ajuda a identificar comportamentos incomuns, como uma aplicação consultando grandes volumes de registros ou acessando regiões fora do padrão.
Outro cuidado envolve a separação de informações críticas. Armazenar todos os dados em uma única conta ou serviço aumenta o impacto potencial de uma credencial comprometida.
A adoção de boas práticas de segurança de APIs também reduz riscos nas aplicações conectadas ao banco. Validação de entradas, autorização granular e limites de requisição dificultam o uso indevido de endpoints expostos.
API Gateway pode criar uma camada adicional de controle
Aplicações não precisam permitir que cada serviço acesse diretamente o banco de dados. Uma camada intermediária pode validar as solicitações, aplicar regras e registrar as operações antes de consultar as informações.
Um API Gateway, por exemplo, pode centralizar autenticação, autorização, limites de tráfego e observabilidade. Dessa forma, mesmo que uma aplicação apresente uma falha, ela não recebe automaticamente acesso irrestrito à base completa.
A APIBrasil explica como uma arquitetura com API Gateway e serviços serverless pode organizar integrações e aplicar controles de segurança em um ponto central.
No entanto, essa estrutura não corrigiria uma vulnerabilidade interna do provedor como a CosmosEscape. Ela funciona como uma camada complementar para reduzir a exposição das aplicações e limitar o impacto de credenciais comprometidas.
Falha reforça riscos da concentração na nuvem
A falha no Azure Cosmos DB não resultou em um vazamento confirmado, mas revelou o impacto potencial de uma vulnerabilidade em um serviço usado por milhares de organizações.
Quando muitas aplicações dependem da mesma plataforma, um problema na camada de infraestrutura pode atingir clientes de diferentes setores ao mesmo tempo.
Por isso, empresas precisam avaliar não apenas a segurança de seus códigos, mas também a arquitetura dos serviços contratados, os acessos concedidos e sua capacidade de detectar comportamentos anormais.
Para conectar aplicações a serviços de dados com autenticação e fluxos bem definidos, acesse a documentação da APIBrasil e conheça as APIs disponíveis.
