Os clientes do Akamai Hunt que foram afetados já receberam um mapeamento detalhado dos ativos vulneráveis, com as etapas de mitigação necessárias.
Resumo executivo
Em 19 de dezembro de 2025, uma nova vulnerabilidade que afeta a maioria das implantações do MongoDB foi divulgada publicamente nas instâncias do MongoDB.
A vulnerabilidade, chamada MongoBleed, está relacionada à forma como o MongoDB processa mensagens compactadas com zlib e permite que clientes não autenticados vazem memória heap não inicializada a partir do banco de dados.
Esta CVE (Common Vulnerability and Exposure) recebeu a pontuação 8,7 no sistema CVSSv4 (Common Vulnerability Scoring System).
Em 29 de dezembro de 2025, a CISA (Cybersecurity and Infrastructure Security Agency) adicionou a CVE-2025-14847 ao seu catálogo de KEV (Known Exploited Vulnerabilities), confirmando que a exploração está ativa. Em paralelo, a telemetria da Akamai indicou que o MongoDB se comunica com aproximadamente 62% das redes corporativas.
Nesta publicação do blog, trazemos uma análise técnica da MongoBleed, uma visão geral das versões afetadas do MongoDB (com a análise de correções) e orientações práticas de mitigação, incluindo as Insight queries da Akamai Guardicore Segmentation para ajudar a identificar ativos vulneráveis.
Detalhes da vulnerabilidade
A MongoBleed tem origem na forma como o MongoDB processa mensagens compactadas do Wire Protocol, um recurso ativado por padrão.
O MongoDB se comunica por mensagens sinalizadas com o opcode OP_MSG, em que as cargas úteis de solicitação são codificadas no formato BSON (binary JSON). Quando uma mensagem compactada é enviada, a carga útil de OP_MSG original é encapsulada em uma estrutura OP_COMPRESSED.
Uma mensagem OP_COMPRESSED inclui a carga útil de OP_MSG e o tamanho esperado da carga útil não compactada.
struct OP_COMPRESSED {
struct MsgHeader {
int32 messageLength;
int32 requestID;
int32 responseTo;
int32 opCode;
};
int32_t originalOpcode;
int32_t uncompressedSize;
uint8_t compressorId;
char *compressedMessage;
};Um invasor pode manipular o campo uncompressedSize para torná-lo maior do que o tamanho real da carga compactada. Como esse valor não é validado, a manipulação leva a uma alocação de buffer maior do que o esperado, preenchida com memória heap não inicializada.
Essa memória vazada pode incluir trechos de senhas em texto não criptografado, credenciais, chaves de API ou outros dados confidenciais mantidos na memória, dependendo do que ocupava a heap antes.
O vazamento é agravado pela lógica de tratamento de erros do MongoDB. Quando o objeto BSON malformado que foi enviado não contém um terminador nulo, o servidor analisa a memória até encontrar um. Quando a análise falha, o servidor retorna uma resposta de erro que inclui a mensagem original e o conteúdo vazado da heap.
Até o momento em que este texto foi escrito, a Shodan relatou mais de 213 mil instâncias do MongoDB expostas à Internet, enquanto a Censys mencionou mais de 87 mil, destacando a ampla exposição da vulnerabilidade.
Exploit público disponível
Poucos dias após a divulgação, um exploit funcional foi publicado no GitHub. Esse exploit depende do envio repetido de solicitações compactadas malformadas, permitindo que invasores vazem grandes porções da memória heap de maneira progressiva.
Versões afetadas
A MongoBleed afeta as seguintes versões do MongoDB:
8.2.0 a 8.2.2
8.0.0 a 8.0.16
7.0.0 a 7.0.27
6.0.0 a 6.0.26
5.0.0 a 5.0.31
4.4.0 a 4.4.29
Todas as versões v3.6, v4.0 e v4.2
Análise de patches
A correção de uma linha calcula o tamanho da mensagem com base no tamanho da saída, em vez de simplesmente confiar no valor informado pelo BSON OP_COMPRESSED. Isso garante que nenhuma memória adicional seja alocada além do tamanho real da mensagem.
- return {output.length()};
+ return length;Mitigação
Atualização para uma versão corrigida
Uma correção foi introduzida nas seguintes versões: 8.2.3, 8.0.17, 7.0.28, 6.0.27, 5.0.32 e 4.4.30.
A atualização para uma dessas versões elimina a vulnerabilidade por completo.
Redução da exposição com segmentação de rede
Até que uma correção seja aplicada, é possível reduzir bastante a exposição usando a segmentação ao:
Bloquear o acesso de entrada da Internet às instâncias do MongoDB na porta TCP/27017
Permitir conexões apenas de fontes claramente confiáveis
Identificação de hosts vulneráveis com a Akamai Guardicore Segmentation
As seguintes Insight queries da Akamai Guardicore Segmentation identificam hosts que estão executando instâncias vulneráveis do MongoDB.
Ativos do Linux
WITH LINUX AS (
SELECT DISTINCT name, version, source
FROM deb_packages
WHERE name = 'mongodb-org-server'
UNION ALL
SELECT DISTINCT name, version, source
FROM rpm_packages
WHERE name = 'mongodb-org-server'
),
PARSED AS (
SELECT name, source, version,
CAST(REGEX_MATCH(version, '([0-9]+)\.([0-9]+)\.([0-9]+)', 1) AS INTEGER) AS major,
CAST(REGEX_MATCH(version, '([0-9]+)\.([0-9]+)\.([0-9]+)', 2) AS INTEGER) AS minor,
CAST(REGEX_MATCH(version, '([0-9]+)\.([0-9]+)\.([0-9]+)', 3) AS INTEGER) AS patch
FROM LINUX
)
SELECT name, source, version
FROM PARSED
WHERE
(major = 8 AND minor = 2 AND patch BETWEEN 0 AND 2)
OR
(major = 8 AND minor = 0 AND patch BETWEEN 0 AND 16)
OR
(major = 7 AND minor = 0 AND patch BETWEEN 0 AND 27)
OR
(major = 6 AND minor = 0 AND patch BETWEEN 0 AND 26)
OR
(major = 5 AND minor = 0 AND patch BETWEEN 0 AND 31)
OR
(major = 4 AND minor = 4 AND patch BETWEEN 0 AND 29)
OR
(major = 3 AND minor = 6)
OR
(major = 4 AND minor IN (0, 2))Ativos do Windows
WITH WINDOWS AS (
WITH MONGO_PROGRAMS AS (
SELECT DISTINCT name, version, install_source AS source, REGEX_MATCH(name, 'MongoDB [0-9].*', 0) AS mongo_match
FROM programs
WHERE name LIKE "MongoDB%"
)
SELECT DISTINCT name, version, source
FROM MONGO_PROGRAMS
WHERE LENGTH(mongo_match) > 0
),
PARSED AS (
SELECT name, source, version,
CAST(REGEX_MATCH(version, '([0-9]+)\.([0-9]+)\.([0-9]+)', 1) AS INTEGER) AS major,
CAST(REGEX_MATCH(version, '([0-9]+)\.([0-9]+)\.([0-9]+)', 2) AS INTEGER) AS minor,
CAST(REGEX_MATCH(version, '([0-9]+)\.([0-9]+)\.([0-9]+)', 3) AS INTEGER) AS patch
FROM WINDOWS
)
SELECT name, source, version
FROM PARSED
WHERE
(major = 8 AND minor = 2 AND patch BETWEEN 0 AND 2)
OR
(major = 8 AND minor = 0 AND patch BETWEEN 0 AND 16)
OR
(major = 7 AND minor = 0 AND patch BETWEEN 0 AND 27)
OR
(major = 6 AND minor = 0 AND patch BETWEEN 0 AND 26)
OR
(major = 5 AND minor = 0 AND patch BETWEEN 0 AND 31)
OR
(major = 4 AND minor = 4 AND patch BETWEEN 0 AND 29)
OR
(major = 3 AND minor = 6)
OR
(major = 4 AND minor IN (0, 2))Desativação de solicitações compactadas (mitigação temporária)
Se não for possível atualizar ou segmentar a instância, as solicitações compactadas com zlib podem ser desativadas para evitar a exploração. Veja instruções detalhadas no Issue Tracker oficial do MongoDB.
Resumo
A MongoBleed (CVE-2025-14847) é uma vulnerabilidade do MongoDB que pode ser explorada remotamente, permitindo que invasores não autenticados vazem memória heap não inicializada.
Com exploits públicos disponíveis e dezenas de milhares de instâncias expostas à Internet, o risco de vazamentos de dados confidenciais é imediato. As organizações que estiverem usando as versões afetadas deverão atualizar para uma versão corrigida ou aplicar as regras de segmentação de rede para minimizar a exposição.
Fique por dentro
O Akamai Security Intelligence Group continuará monitorando, notificando e criando mitigações quanto a ameaças como essas para nossos clientes e para a comunidade de segurança em geral. Para acompanhar as notícias mais recentes do Akamai Security Intelligence Group, confira nossa página inicial de pesquisa e siga nossos perfis nas redes sociais.
Tags
