Uma falha crítica no MongoDB Server permite que um invasor sem autenticação envie duas solicitações capazes de derrubar o servidor de banco de dados. A interrupção só ocorre se, mais tarde, esse servidor for escolhido para assumir como nó principal sem ter recebido algumas alterações recentes.
A MongoDB, empresa responsável pelo banco de dados, lançou versões corrigidas no início desta semana.
Os servidores afetados integram um conjunto de réplicas, grupo de servidores MongoDB que mantém cópias dos mesmos dados. Um deles, o primário, processa todas as novas gravações, enquanto os demais replicam essas alterações. Se o primário ficar indisponível, os outros integrantes elegem um novo.
Pesquisadores do Datadog Security Labs reproduziram a falha em um ambiente de testes e divulgaram suas conclusões ontem. Nas versões vulneráveis, ativar a autenticação não impede o envio das duas solicitações. Segundo os pesquisadores, um invasor não consegue fazer o integrante visado ficar defasado, vencer uma eleição ou saber quando qualquer uma dessas situações ocorre.
Identificada como
CVE-2026-118383
, a falha é uma vulnerabilidade de use-after-free: o servidor tenta acessar uma área de memória que já foi liberada. A MongoDB atribuiu à vulnerabilidade a pontuação 9,5 em 10 na escala de gravidade CVSS 4.0. A empresa informou que identificou a falha e que “não tem conhecimento de tentativas de exploração”.
Entre os integrantes afetados estão os servidores de fragmentos e de configuração de clusters fragmentados. Uma instância independente do `mongod`, ou seja, um único servidor fora de qualquer conjunto de réplicas, não é afetada.
As versões corrigidas de cada ramificação afetada estão listadas no registro da CVE. Todas as versões anteriores da mesma ramificação, até a primeira, também são vulneráveis.
Segundo o comunicado de segurança da MongoDB, os clusters do MongoDB Atlas recebem automaticamente as versões corrigidas durante a manutenção. Clientes que adiam a manutenção devem instalar a atualização o quanto antes.
Implantações gerenciadas pelos próprios clientes precisam receber a versão corrigida em todos os integrantes do conjunto de réplicas. Depois da atualização, é necessário conferir a versão em execução em cada integrante, inclusive nos que estão em containers e nos que ficaram offline durante a manutenção.
A ramificação 8.2 não aparece entre as versões afetadas, e seu lançamento mais recente é o 8.2.12. No entanto, uma prova de conceito publicada no GitHub relata que a falha também ocorreu na versão 8.2.12 durante um teste em laboratório com uma configuração específica para testes.
A ramificação 8.2 chegou ao fim de sua vida útil em 31 de julho, de acordo com o cronograma da empresa. Depois dessa data, uma versão deixa de receber atualizações, inclusive correções de segurança.
Enquanto não for possível atualizar um integrante, os pesquisadores recomendam restringir o acesso à rede do banco de dados aos sistemas que realmente precisam dele. A medida limita quem pode enviar as duas solicitações, mas não corrige a falha.
Quando um integrante vence uma eleição, primeiro ele se atualiza, aplicando as gravações que deixou de receber, antes de aceitar novas gravações. Segundo a análise técnica dos pesquisadores do Datadog, a falha está na rotina de limpeza executada ao fim dessa etapa de atualização.
As duas solicitações são comandos `ping` que incluem o valor `readConcern.afterOpTime`. Cada uma pede ao servidor que aguarde até que a replicação alcance determinado ponto. Para isso, o servidor registra uma notificação pendente, chamada de “espera”.
A criação dessas esperas não derruba o servidor. Elas não expiram e permanecem até que o integrante seja reiniciado, reverta alterações ou deixe de ser o primário.
Para provocar a interrupção, o integrante que recebeu as solicitações precisa vencer uma eleição posterior, mesmo estando defasado em relação a outro integrante. Quando a etapa de atualização termina, a rotina de limpeza é executada duas vezes e reutiliza memória já liberada. Com isso, o novo primário falha antes de aceitar qualquer gravação. Segundo os pesquisadores, uma vez reunidas essas condições, a interrupção não depende de uma disputa de tempo.
No laboratório, os pesquisadores fizeram o integrante ficar defasado e provocaram a transferência de função usando acesso administrativo para pausar e encerrar processos `mongod`. Apenas as duas solicitações vieram de um cliente sem credenciais, que não tinha permissão para gravar no banco de dados.
Na versão 8.0.34, o integrante falhou com um erro de segmentação, deixando o cluster de testes sem um primário. Em outra implantação, um novo primário poderia ser eleito e o sistema continuar funcionando.
Na versão corrigida 8.0.37, o servidor rejeitou imediatamente as duas solicitações por falta de autorização, e o integrante continuou em execução. Uma parte da correção permite que apenas usuários internos do sistema utilizem `readConcern.afterOpTime`.
A MongoDB afirma que, em determinadas condições, a falha também pode levar à execução arbitrária de código no processo do servidor. No entanto, “não conseguimos executar código” no laboratório, disseram os pesquisadores. Os resultados também não indicam com que frequência o ataque teria êxito em outras configurações.
O autor da prova de conceito afirma que o código reproduz a falha em um conjunto de réplicas de teste. A reprodução confiável exige uma configuração exclusiva para testes, que um invasor remoto não consegue ativar. O impacto descrito é uma interrupção ou corrupção de memória, sem alegação de execução de código.
A segunda parte da correção impede que a rotina de limpeza seja executada duas vezes, mesmo quando já existem esperas, segundo os pesquisadores. Eles não testaram essa parte da correção.
No teste de laboratório da prova de conceito, realizado com a autenticação desativada, a versão corrigida 8.0.37 aceitou as esperas criadas, mas executou a rotina de limpeza apenas uma vez.
Para identificar a criação das esperas ou uma interrupção, procure estes sinais nos logs estruturados do servidor, observados pelos pesquisadores durante um teste com uma versão vulnerável:
- Evento de log: uma entrada `COMMAND "Slow query"` (ID 51803) para um comando `ping` sem autenticação que contém `readConcern.afterOpTime` e termina com `MaxTimeMSExpired`.
- Evento de log: um integrante inicia a atualização para se tornar primário (ID 21359) e, em seguida, sai dessa etapa duas vezes (ID 21363) durante a mesma transição.
- Evento de log: um sinal fatal ou rastreamento de pilha que envolve `CatchupState::abort_inlock()` após essas saídas.
Uma eleição normal ou uma única saída da etapa de atualização não indica essa falha. As solicitações também podem chegar antes da transferência de função, por isso vale conferir os logs anteriores do mesmo integrante.
A inclusão dos campos das solicitações nos logs depende das configurações de registro. Além disso, o campo `attr.remote` pode exibir um endereço de loopback, em vez do endereço IP real do cliente.
Publicidade
Tenha acesso aos melhores hackers éticos do mercado através de um serviço personalizado, especializado e adaptado para o seu negócio. Guardsi: qualidade, confiança e especialidade em segurança ofensiva de quem já protegeu centenas de empresas. Saiba mais...