Zlib compressed protocol header length confusion may allow memory read
Corrija agora. Ela está sob exploração confirmada pelo CISA e tem exploit funcional público.
Apply mitigations per vendor instructions, follow applicable BOD 22-01 guidance for cloud services, or discontinue use of the product if mitigations are unavailable.
Resumo
CVE-2025-14847 ("MongoBleed") é uma falha de confusão de tamanho no tratamento de cabeçalhos de mensagens comprimidas via zlib no protocolo binário do MongoDB Server, que permite a um cliente não autenticado ler memória heap não inicializada do processo mongod/mongos. A falha ocorre na camada de rede, antes de qualquer verificação de autenticação ou autorização, e afeta virtualmente todas as branches do MongoDB Server, incluindo versões EOL. Está no catálogo KEV da CISA com exploração confirmada e possui PoC pública, módulo Metasploit e template Nuclei.
Detalhamento técnico
O protocolo binário do MongoDB usa o opcode OP_COMPRESSED como wrapper para mensagens (tipicamente OP_MSG) comprimidas em trânsito. O cabeçalho OP_COMPRESSED inclui, entre outros campos, o tamanho esperado da mensagem após a descompressão — valor fornecido pelo próprio cliente. O servidor usa esse valor declarado para alocar o buffer de destino da descompressão zlib antes de invocar o decompressor.
O problema (CWE-130, Improper Handling of Length Parameter Inconsistency) é que, se o payload comprimido de fato se expande para um número de bytes menor do que o declarado no cabeçalho, apenas parte do buffer alocado é escrita pelo zlib; o restante permanece com conteúdo residual de alocações heap anteriores. Código subsequente no pipeline de processamento de mensagens confia no tamanho declarado, não no número real de bytes escritos pela descompressão, e esse buffer parcialmente não inicializado acaba sendo tratado como dado de mensagem válido.
Como essa etapa de decodificação ocorre no caminho de recebimento de rede, antes de autenticação, autorização e execução de query, o bug independe de credenciais, roles ou configuração de acesso a bancos/coleções — a única pré-condição real é que a porta do mongod/mongos esteja acessível e que a compressão zlib seja negociável pelo servidor.
O impacto no vetor CVSS (VC:H, mas VI:N/VA:N) reflete que a falha é puramente de confidencialidade: não há corrupção de dados nem indisponibilidade diretamente associada, apenas exposição de memória heap do processo do servidor de banco de dados.
Como é explorada
O vetor de exploração é remoto e pré-autenticação: basta estabelecer uma conexão TCP com a porta do MongoDB e negociar/enviar uma mensagem OP_COMPRESSED usando o compressor zlib com um cabeçalho cujo tamanho declarado de descompressão seja maior do que o payload comprimido efetivamente produz ao ser expandido. O servidor decodifica esse payload e retorna dados que incluem os bytes residuais do heap, sem exigir usuário, senha, sessão prévia ou interação humana (AC:L, PR:N, UI:N no vetor CVSS 4.0).
Na prática, o conteúdo vazado depende do estado de memória do processo mongod no momento — pode conter fragmentos de credenciais, tokens de sessão, strings de conexão ou dados de consultas recentes de outros clientes, mas isso não é garantido em toda tentativa; a exploração é essencialmente uma leitura repetida que amplia a chance de capturar dado sensível conforme a reutilização de heap acontece.
A vulnerabilidade está no catálogo KEV da CISA desde 29/12/2025 (prazo de correção: 19/01/2026), confirmando exploração ativa observada. Existe PoC pública (repositório github.com/joe-desimone/mongobleed, referenciado no thread de oss-security), além de módulo Metasploit e template Nuclei já disponíveis, o que baixa a barreira de exploração para praticamente qualquer atacante com acesso de rede ao serviço.
Versões
Como se proteger
A correção definitiva é atualizar para as versões corrigidas por branch: 8.2.3, 8.0.17, 7.0.28, 6.0.27, 5.0.32 ou 4.4.30, conforme a linha em uso. Para as branches 3.6, 4.0 e 4.2, que são end-of-life, o fornecedor não emitiu patch — a única remediação é migrar para uma branch suportada e corrigida.
Se a atualização imediata não for possível, o próprio fornecedor recomenda desabilitar o compressor zlib no servidor, iniciando mongod/mongos com a opção networkMessageCompressors ou net.compression.compressors configurada para excluir explicitamente zlib (por exemplo, usando snappy,zstd ou disabled). Isso remove o caminho de código vulnerável, mas tem custo: perda do ganho de banda da compressão zlib e possível fallback para tráfego sem compressão em clientes que só oferecem esse compressor.
Controles de acesso a nível de aplicação — autenticação, RBAC, restrição por usuário/coleção — NÃO mitigam a falha, porque o código vulnerável executa antes de qualquer verificação de autenticação. Restringir a exposição de rede (firewall, bind em interface privada, isolamento de rede) reduz a superfície de ataque mas não é uma correção reconhecida pelo fornecedor; a única mitigação oficial além do upgrade é a desativação do compressor zlib.
Como detectar
Como a falha ocorre na camada de decodificação do protocolo binário, antes de qualquer log de autenticação, o mongod normalmente não gera evidência aplicacional direta de uma tentativa de exploração — não há um evento de auditoria nativo confiável para esse ataque. A detecção prática depende de inspeção de tráfego de rede: procurar mensagens OP_COMPRESSED com compressorId indicando zlib em que o tamanho declarado de descompressão (uncompressedSize) diverge do tamanho real do payload comprimido correspondente, ou usar as assinaturas já publicadas no template Nuclei e no módulo Metasploit como referência de padrão de exploração. Monitorar conexões não autenticadas e de curta duração à porta do MongoDB, seguidas de respostas anômalas, é o sinal indireto mais acessível.