- MongoBleed (CVE-2025-14847) é uma vulnerabilidade grave de vazamento de memória presente em todas as versões do MongoDB desde 2017, permitindo que um invasor leia dados arbitrários da memória heap do banco de dados
- A vulnerabilidade é causada por um bug no caminho de compressão zlib e pode ser explorada sem autenticação, bastando apenas conectar-se ao banco de dados
- O invasor pode enviar uma requisição comprimida manipulada para induzir o servidor a alocar um buffer com tamanho incorreto, expondo a memória de operações anteriores (senhas, chaves de API etc.) contida nele
- O MongoDB distribuiu um patch em 19 de dezembro de 2025, mas as versões EOL (3.6, 4.0, 4.2) não foram corrigidas
- Essa vulnerabilidade, presente por 8 anos, afeta mais de 210 mil instâncias do MongoDB expostas à internet e exige aplicação imediata do patch ou desativação da compressão em ambientes de nuvem e on-premises
Visão geral do MongoBleed
- MongoBleed (CVE-2025-14847) é uma vulnerabilidade encontrada no caminho de compressão de mensagens zlib 1 do MongoDB e afeta todas as versões desde 2017
- Um invasor pode ler dados arbitrários da memória heap apenas conectando-se ao banco de dados, sem autenticação
- Versões com fim de suporte (EOL), como MongoDB 3.6, 4.0 e 4.2, não foram corrigidas
- O bug foi introduzido em um PR de maio de 2017 e foi divulgado oficialmente em 19 de dezembro de 2025
- O MongoDB anunciou que aplicou patches a todas as instâncias, incluindo o serviço em nuvem Atlas
Estrutura de comunicação do MongoDB
- O MongoDB usa seu próprio protocolo TCP em vez de HTTP, e as mensagens são transmitidas no formato BSON (Binary JSON)
- Todas as requisições são compostas pelo comando OP_MSG e, quando comprimidas, são encapsuladas em uma mensagem OP_COMPRESSED
- A mensagem inclui campos como
uncompressedSize, originalOpcode e compressorId
uncompressedSize indica o tamanho esperado após a descompressão
Etapa 1 do exploit — alocação incorreta de buffer
- O invasor define o valor de
uncompressedSize como muito maior do que o real, fazendo o servidor alocar um buffer grande
- Exemplo: declarar uma mensagem real de 1 KB como se tivesse 1 MB
- Após a descompressão, o servidor MongoDB não valida o tamanho real e confia no valor fornecido pelo usuário
- Como resultado, a memória fica com uma estrutura como
[dados reais | lixo de heap não referenciado]
- Como o MongoDB, baseado em C++, não inicializa a memória, essa área pode conter dados sensíveis de operações anteriores
- Exemplo: senhas, tokens de sessão, chaves de API, dados de clientes, configurações do sistema etc.
Etapa 2 do exploit — vazamento de dados
- O invasor envia uma entrada BSON malformada para induzir o servidor a interpretar os dados residuais da memória como string
- O primeiro campo do BSON é uma string e segue a regra de string terminada em nulo (null-terminated string) da linguagem C
- Se o invasor enviar uma string sem caractere nulo de terminação, o servidor continuará lendo outros dados da memória
- Exemplo:
[ { "a | password: 123\0 | apiKey: jA2sa | ip: 219.117.127.202 ]
- O servidor interpreta isso como um campo BSON inválido e inclui esse conteúdo na mensagem de erro da resposta
"errmsg": "invalid BSON field name 'a | password: 123'"
- Repetindo esse processo, o invasor pode varrer toda a memória heap e coletar informações sensíveis
Impacto e gravidade
- Como ocorre na fase pré-autenticação (pre-auth), o invasor pode acessar dados sem fazer login
- Instâncias do MongoDB expostas à internet ficam imediatamente em risco
- Segundo buscas no Shodan, mais de 213 mil instâncias do MongoDB estão publicamente expostas
- Trata-se de uma vulnerabilidade que existiu por cerca de 8 anos, de 2017 a 2025, e, por sua estrutura simples, tem alta probabilidade de exploração real
- O MongoDB afirmou que “até o momento não há evidências de exploração”, mas não divulgou um pedido formal de desculpas nem uma linha do tempo detalhada
Mitigação
- Atualizar para a versão com patch mais recente (8.0.17 ou superior)
- No curto prazo, também é possível mitigar desativando a compressão de rede zlib
- Usuários do MongoDB Atlas já receberam o patch
Informações adicionais e discussões relacionadas
- O líder da equipe de segurança da Elastic deu o nome “MongoBleed” à falha e publicou um PoC (script em Python)
- MongoDB e Elastic competem na área de busca e análise
- Recursos relacionados:
Resumo
- MongoBleed é uma vulnerabilidade de vazamento de memória causada por um bug no processamento de compressão zlib
- Um invasor pode obter dados de memória anteriores (senhas, chaves de API etc.) por meio de uma requisição comprimida manipulada
- Todas as versões do MongoDB entre 2017 e 2025 são afetadas, e aplicar o patch ou desativar a compressão é essencial
- Mais de 210 mil instâncias expostas à internet são alvos potenciais
- O MongoDB distribuiu um patch, mas houve críticas pela falta de suporte às versões EOL e demora na resposta pública
1 comentários
Comentários do Hacker News
Graças a isso, a memória não inicializada deixou de conter dados significativos
Eu esperava uma queda de desempenho, mas na prática não houve nenhum impacto mensurável
Acho que todo mundo que usa linguagens sem segurança de memória deveria fazer isso. Esse bug do Mongo também poderia ter sido mitigado dessa forma
Dizem que isso melhora a eficiência da compressão de memória e, em média, acaba até melhorando o desempenho
MALLOC_CONF=opt.junk=free, o malloc faz a mesma coisaOu seja, muitas implementações já oferecem esse recurso como opção
Se precisar de mais desempenho, basta escrever um alocador customizado para um caso específico
Isso também permitiria outras otimizações que não são possíveis no alocador do sistema
0xdbe memória liberada com0xdfIsso ajuda a encontrar rapidamente bugs de use-before-initialization e use-after-free
E isso já é o padrão
init_on_free=1do kernelO Mongo é desenvolvido primeiro em um repositório privado e depois os commits são levados ao repositório público via Copybara
A confusão com as datas surgiu nesse processo
Vou atualizar o texto para explicar isso e a diferença de datas
Nossos clusters Atlas já tinham sido atualizados alguns dias antes da divulgação do CVE
Hoje em dia, a maioria dos alocadores deveria fazer isso por padrão
Chris melhorou essa parte no Blink, e o resultado acabou se espalhando por todo o Chromium
A documentação relacionada também é interessante
Post do blog do Chromium
Documentação do PartitionAlloc
No mundo SQL é raro, mas às vezes acontece
A filosofia é não precisar se preocupar com schema, durabilidade, leitura/escrita, conectividade e nada disso
Então não surpreende que também não se preocupem com segurança
Essa atitude leva à mentalidade de “vamos fazer o que é mais cômodo agora”, e no fim isso se conecta a problemas de segurança como instâncias públicas de banco de dados
Na prática, é comum usar SQL e NoSQL juntos
NoSQL tem pontos fortes em alta disponibilidade para grandes volumes de dados, e SQL é adequado para armazenar dados relacionais
Por exemplo, iMessage e o sistema de matchmaking da EA também usam NoSQL
No fim, os dois são necessários. Não é uma relação de competição, e sim de complemento
Por exemplo, o PostgreSQL pode obter permissões sobre o sistema inteiro só com a configuração padrão
Por isso a maioria das pessoas entende bem o risco de um servidor SQL público
Pessoalmente eu não gostaria de usar, mas há casos em que DynamoDB ou MongoDB fazem sentido tecnicamente
Vídeo relacionado
Mas buffer overflow continua existindo desde 2003
Esse tipo de problema vai se repetir para sempre, a menos que seja bloqueado no nível da linguagem
Meus sentimentos aos desenvolvedores do Mongo
Eu ainda acho melhor usar ToroDB ou o JSONB do PostgreSQL