Uma vulnerabilidade severa que afeta múltiplas versões do MongoDB está a ser ativamente explorada "in the wild", colocando em risco dezenas de milhares de bases de dados expostas na web. Batizada de "MongoBleed" (CVE-2025-14847), a falha recebeu uma classificação de severidade de 8.7 e permite que atacantes extraiam remotamente segredos, credenciais e outros dados sensíveis sem necessidade de autenticação.
Segundo os dados da plataforma Censys, até ao dia 27 de dezembro, existiam mais de 87.000 instâncias de MongoDB potencialmente vulneráveis expostas na internet pública. Os Estados Unidos lideram a lista com quase 20.000 servidores, seguidos pela China e pela Alemanha.
Como funciona o "sangramento" de dados
A vulnerabilidade reside na forma como o servidor MongoDB lida com pacotes de rede processados pela biblioteca zlib para compressão de dados sem perdas. Investigadores da Ox Security explicam que o problema ocorre porque o MongoDB devolve a quantidade de memória alocada ao processar mensagens de rede, em vez do comprimento real dos dados descomprimidos.
Um agente malicioso pode enviar uma mensagem malformada que afirma ter um tamanho maior quando descomprimida. Isto leva o servidor a alocar um buffer de memória maior do que o necessário, acabando por devolver ao cliente dados que estavam nessa memória ("in-memory data"), os quais podem conter informações críticas.
O tipo de segredos que podem ser "sangrados" desta forma inclui credenciais de acesso, chaves de API ou de serviços cloud, tokens de sessão, informações de identificação pessoal (PII), logs internos e configurações. O investigador de segurança Joe Desimone lançou um "exploit" de prova de conceito (PoC), acessível através do seu perfil no X (antigo Twitter), criado especificamente para demonstrar como é possível extrair estes dados sensíveis da memória.
O analista de segurança Kevin Beaumont confirma, através do seu artigo no DoublePulsar, que o código do exploit é válido e requer apenas "um endereço IP de uma instância MongoDB para começar a procurar na memória coisas como palavras-passe de bases de dados (que estão em texto simples), chaves secretas da AWS, etc."
Impacto real e deteção
O impacto estende-se significativamente aos ambientes cloud. Dados de telemetria da plataforma de segurança Wiz indicaram que 42% dos sistemas visíveis "têm pelo menos uma instância de MongoDB numa versão vulnerável". Uma vez que a descompressão das mensagens de rede ocorre antes da fase de autenticação, qualquer atacante pode explorar o MongoBleed sem precisar de credenciais válidas.
Existem relatos de que alguns piratas informáticos afirmam ter utilizado esta falha numa violação recente da plataforma online do Rainbow Six Siege da Ubisoft. Este incidente surge num momento em que o jogo tem enfrentado instabilidade, com relatos de caos no Rainbow Six Siege devido a ações de hackers.
Para os administradores de sistemas, a deteção de compromisso é crucial. Eric Capuano, cofundador da Recon InfoSec, alerta que aplicar a correção é apenas parte da resposta. Um método de deteção sugerido envolve procurar IPs de origem com centenas ou milhares de conexões, mas zero eventos de metadados. Florian Roth criou também o "MongoBleed Detector", uma ferramenta que analisa os logs do MongoDB para identificar potenciais explorações.
Versões afetadas e como corrigir
O MongoDB emite alerta urgente para que os administradores atualizem imediatamente os seus sistemas. O patch de correção está disponível para instâncias auto-alojadas ("self-hosting") desde o dia 19 de dezembro.
A lista de versões impactadas é extensa, abrangendo desde lançamentos antigos do final de 2017 até versões tão recentes como novembro de 2025:
MongoDB 8.2.0 até 8.2.3
MongoDB 8.0.0 até 8.0.16
MongoDB 7.0.0 até 7.0.26
MongoDB 6.0.0 até 6.0.26
MongoDB 5.0.0 até 5.0.31
MongoDB 4.4.0 até 4.4.29
Todas as versões do MongoDB Server v4.2, v4.0 e v3.6
A recomendação forte é a atualização para uma versão segura (8.2.3, 8.0.17, 7.0.28, 6.0.27, 5.0.32 ou 4.4.30). Para os clientes do serviço gerido MongoDB Atlas, a correção foi aplicada automaticamente, não sendo necessária qualquer ação.
Caso a atualização imediata não seja possível, a única mitigação recomendada pelo fornecedor é desativar a compressão zlib no servidor. Alternativas seguras para compressão de dados incluem o Zstandard (zstd) e o Snappy.
Nenhum comentário
Seja o primeiro!