Mesmo após anos de alertas da comunidade de segurança, erros básicos de configuração continuam colocando milhares de bancos de dados MongoDB em risco em 2026. Instâncias acessíveis diretamente pela internet, sem autenticação adequada, seguem sendo descobertas por bots automatizados e apagadas em poucos segundos, resultando em perdas graves de dados e interrupções de serviços.
Um novo relatório da empresa de inteligência de ameaças Flare confirma que o problema está longe de ser resolvido. Os pesquisadores identificaram uma grande quantidade de servidores acessíveis publicamente, muitos deles já comprometidos por campanhas de extorsão que exigem pagamento em criptomoedas para uma suposta recuperação das informações.
Este artigo analisa os dados mais recentes sobre servidores MongoDB expostos, explica como funcionam os ataques de extorsão observados em 2026, detalha por que o pagamento do resgate não é uma solução confiável e apresenta orientações práticas de segurança no MongoDB para administradores de sistemas e profissionais que operam ambientes Linux.
Os números alarmantes da exposição do MongoDB
De acordo com a análise da Flare, aproximadamente 208.500 servidores MongoDB estavam acessíveis publicamente no momento da pesquisa. Essas instâncias podiam ser encontradas por meio de varreduras automatizadas simples, sem a necessidade de exploração avançada ou credenciais válidas.
O dado mais preocupante é que 45,6% desses servidores já haviam sido comprometidos. Em termos práticos, isso significa que quase metade das instâncias abertas teve seus bancos de dados apagados e substituídos por mensagens de extorsão. Em muitos desses casos, não havia qualquer evidência de backups funcionais, tornando a perda definitiva.
Esses números reforçam que o principal vetor de ataque não está em falhas sofisticadas do MongoDB, mas sim na ausência de controles básicos de acesso e na falta de políticas mínimas de segurança no MongoDB em ambientes expostos à internet.
Imagem: Flare
A anatomia do ataque: Como os cibercriminosos agem
Os ataques de extorsão observados seguem um padrão altamente automatizado. Bots percorrem a internet em busca de servidores MongoDB que aceitam conexões externas sem autenticação. Ao identificar uma instância vulnerável, o acesso é feito imediatamente, sem qualquer resistência.
Em seguida, todas as coleções existentes são apagadas. Logo após, os atacantes criam um novo banco ou coleção contendo uma nota de resgate, informando que os dados teriam sido copiados antes da exclusão e que o pagamento é a única forma de recuperação.
O valor exigido costuma ser relativamente baixo, cerca de 0,005 BTC, uma quantia calculada para parecer menor do que o custo operacional da perda de dados, aumentando a chance de pagamento por parte das vítimas.
O monopólio do ataque
Um dos achados mais relevantes do relatório da Flare é a concentração da atividade criminosa. Aproximadamente 98% das extorsões identificadas estão associadas a uma única carteira de Bitcoin. Isso indica que um único agente, ou grupo altamente organizado, domina quase toda essa campanha global.
Esse monopólio torna os ataques mais eficientes e recorrentes, já que a mesma infraestrutura automatizada é reutilizada continuamente, explorando a persistência de servidores MongoDB mal configurados em diferentes países e setores.
O risco da falsa promessa
Apesar da pressão psicológica criada pela mensagem de resgate, pagar não garante a recuperação dos dados. Não há provas de que os atacantes realmente mantenham cópias utilizáveis das informações apagadas. Em muitos casos analisados, o pagamento foi realizado e nenhum dado foi devolvido.
Além disso, o pagamento sinaliza que o alvo está disposto a negociar, o que pode resultar em novos ataques no futuro. Do ponto de vista da segurança no MongoDB, ceder à extorsão raramente resolve o problema e frequentemente o agrava.
Versões antigas e vulnerabilidades de “dia n”
Outro fator que amplia o impacto desses ataques é o uso de versões obsoletas do MongoDB. A Flare identificou cerca de 95.000 servidores executando versões antigas, muitas delas fora do ciclo oficial de suporte.
Embora a extorsão não dependa diretamente de falhas de software, versões desatualizadas aumentam a superfície de ataque. Vulnerabilidades conhecidas, também chamadas de falhas de dia n, podem ser exploradas em conjunto com configurações inseguras, facilitando ainda mais o comprometimento.
Manter o banco de dados atualizado é um dos pilares da segurança no MongoDB, especialmente em servidores Linux conectados à internet pública.
Como proteger seu banco de dados MongoDB no Linux
Evitar que um servidor MongoDB seja comprometido não exige soluções complexas. A maioria dos ataques poderia ser bloqueada com práticas básicas de segurança, muitas vezes negligenciadas.
Entre as medidas mais importantes estão:
Ativar autenticação obrigatória, impedindo acessos anônimos ao banco de dados.
Restringir conexões por firewall, permitindo acesso apenas a IPs e redes confiáveis.
Evitar exposição direta à internet, utilizando VPNs ou redes privadas sempre que possível.
Manter o MongoDB atualizado, reduzindo riscos associados a falhas conhecidas.
Implementar backups automáticos e testados, garantindo recuperação rápida em caso de incidente.
Monitorar logs e conexões, identificando comportamentos suspeitos de forma antecipada.
Executar o serviço com privilégios mínimos, limitando o impacto de um eventual comprometimento.
Essas práticas formam a base de uma estratégia sólida de segurança no MongoDB e devem ser tratadas como requisitos essenciais em qualquer ambiente profissional.
Conclusão e o futuro da segurança em bancos de dados
Os ataques de extorsão contra servidores MongoDB mal configurados mostram que a tecnologia, por si só, não é suficiente para garantir segurança. A proteção de bancos de dados depende de processos, responsabilidade operacional e automação de boas práticas desde a implantação inicial.
À medida que os ataques se tornam mais rápidos e automatizados, a defesa precisa acompanhar esse ritmo. Configurações seguras por padrão, atualizações contínuas e monitoramento ativo são fundamentais para evitar perdas graves de dados.
Agora é o momento de revisar ambientes, auditar configurações e garantir que nenhum banco de dados crítico esteja acessível sem controle. Compartilhar esse alerta com equipes técnicas e comunidades também ajuda a reduzir o impacto coletivo desse problema recorrente.