Aviso de segurança do MongoDB

 (mongodb.com)
2 pontos por GN⁺ 2023-12-18 | 1 comentários | Compartilhar no WhatsApp
  • O MongoDB Alerts é um hub de avisos que reúne problemas de integridade de dados, operacionais e de segurança CVE em um só lugar, permitindo verificar o escopo de impacto por versão e quais implantações do MongoDB exigem ação
  • Os itens de integridade de dados de 2026 incluem erro em consultas de intervalo descendente de _id em clustered collection, permissão de duplicação em unique index de sharded cluster, omissões no Relational Migrator e não aplicação de read/write concern ao conectar diretamente a um shard
  • No aspecto operacional, até abril de 2026 as principais CAs públicas deixarão de emitir certificados TLS com clientAuth EKU, o que pode afetar configurações de mTLS e autenticação X.509 em implantações self-managed do MongoDB
  • A seção de segurança fornece listas de CVEs por produto, de 2019 a 2026, para MongoDB Server, Compass, mongosh, drivers, Ops Manager e outros
  • Na prática, é preciso comparar as versões em uso de Server, Atlas, Relational Migrator, Compass, mongosh e drivers por linguagem com o escopo afetado, e aplicar upgrades para versões corrigidas ou as configurações alternativas divulgadas

Escopo coberto pela página MongoDB Alerts

  • MongoDB Alerts é uma página que reúne alertas e recomendações importantes do MongoDB
  • Uma lista abrangente de bugs e solicitações de funcionalidades pode ser consultada no MongoDB JIRA
  • Novos avisos também são fornecidos por RSS Feed
  • A página é composta pelas seguintes categorias
    • Data Integrity Related
    • Operations Related
    • Security Related: Common Vulnerabilities and Exposures (CVEs)
    • General

Alertas de integridade de dados de 2026

  • Consultas de intervalo descendente de _id em clustered collection

    • Aviso publicado em 17 de junho de 2026
    • Em clustered collection, se for aplicada ordenação descendente ao campo _id e forem usadas condições de intervalo no formato {$lt: A}, {$gt: A}, {$gte: A, $lt: B}, {$gt: A, $lte: B}, documentos de borda podem ser incluídos ou excluídos incorretamente
    • Não afeta time series collection, non-clustered collection, clustered collection sem ordenação descendente em _id, nem combinações de operadores de comparação com o mesmo tipo de inclusão/exclusão
    • Versões afetadas:
      • MongoDB 8.0.0–8.0.23
      • 8.2.0–8.2.9
      • 8.3.0–8.3.2
    • SERVER-121822

  • Garantia de duplicidade em unique index de sharded cluster

    • Aviso publicado em 14 de maio de 2026
    • Em um sharded cluster, se a shard key for igual ao index key pattern ou um strict prefix dele, e o unique index usar non-simple collation, a unicidade entre shards pode não ser aplicada
    • Valores como "YES" e "yes", que têm bytes diferentes mas são iguais segundo a collation, podem ser inseridos independentemente em shards diferentes
    • As condições do problema são: dois ou mais shards, unique index com non-simple collation, e shard key igual ao index key pattern ou sendo seu strict prefix
    • Versões afetadas:
      • 5.0.0–5.0.32
      • 6.0.0–6.0.28
      • 7.0.0–7.0.31
      • 8.0.0–8.0.20
      • 8.2.0–8.2.6
    • SERVER-85346

  • Omissões de migração no Relational Migrator

    • Aviso publicado em 14 de maio de 2026
    • Usuários que migraram com o Relational Migrator podem sofrer omissão de documentos em migração para sharded cluster quando houver embedded document ou embedded array
    • Um cyclic mapping com foreign key excluída sob embedded array, uma source table column usada em várias relações de composite foreign key e a escolha de nomes de campo conflitantes podem gerar omissões, inconsistências ou campos com nome incorreto
    • O produto afetado é o MongoDB Relational Migrator anterior à versão 1.16.0
    • SERVER-126522

  • Não aplicação de read/write concern ao conectar diretamente a shard

    • Aviso publicado em 14 de maio de 2026
    • Se a conexão for feita diretamente a um node de shard sem passar pelo mongos, o cluster-wide default read/write concern pode não ser aplicado
    • Nesse caso, a escrita pode ser executada com {w: 1} em vez do concern configurado e, se ocorrer rollback, um acknowledged write pode ser perdido
    • A conexão a sharded cluster deve ser feita somente por meio de mongos
    • Se for necessário conectar diretamente ao shard, é preciso atualizar imediatamente para uma versão corrigida ou definir read/write concern explícito na connection string, como {w: "majority"}
    • Versões afetadas:
      • 5.0.0–5.0.32
      • 6.0.0–6.0.28
      • 7.0.0–7.0.31
      • 8.0.0–8.0.19
      • 8.2.0–8.2.3
    • SERVER-111031

Padrões recorrentes em alertas recentes de integridade de dados

  • Sharding e migração

    • O item de março de 2026 trata do risco de perda de dados durante chunk migration em sharded collection com compound wildcard index contendo shard key prefix
    • Em novembro de 2025, foi registrado um problema em que cross-shard transaction pode ser parcialmente confirmada sob certas condições de failover
    • Em abril de 2024, foi incluído um problema em que sharded multi-document transaction pode retornar dados incorretos ou omitir writes

  • Time series collection

    • O item de novembro de 2025 informa que chaves de índice 2dsphere para metric data em time series collection podem não ser geradas nem inseridas, fazendo com que geospatial query retorne resultados incompletos
    • O item de agosto de 2025 trata de um problema em que certos padrões de entrada de métricas em double-precision podem causar corrupção de dados
    • O item de janeiro de 2025 inclui a possibilidade de perda de dados em time series collection na combinação de insert concorrente com ordered: false e retryable writes

  • Precisão dos resultados de consulta

    • Em março de 2026, foi registrado um problema em que uma aggregation query com $group logo após $sort usando os acumuladores $top ou $bottom pode retornar resultados incorretos
    • Em fevereiro de 2026, a interface SQL pode retornar resultados incorretos quando uma condição OR na cláusula WHERE for UNKNOWN e a outra for TRUE
    • Em junho de 2025, uma query com $elemMatch e predicate de string pode usar um índice com collation incompatível e omitir documentos que deveriam ser incluídos

Alertas operacionais

  • Mudança de política de clientAuth EKU em CAs públicas

    • Aviso publicado em 22 de janeiro de 2026
    • As principais Certificate Authorities públicas estão aplicando uma exigência de política pela qual, até abril de 2026, deixarão de emitir certificados TLS que incluam client authentication (clientAuth) Extended Key Usage
    • Essa mudança afeta apenas implantações self-managed do MongoDB que usam certificados de CA pública para mutual TLS (mTLS) ou autenticação X.509
    • Clientes self-managed devem migrar para uma private PKI infrastructure ou alterar a configuração do MongoDB antes do prazo de abril–maio de 2026
    • Clientes Atlas não são afetados
    • Escopo afetado:
      • X.509 Cluster Authentication
      • X.509 Client Authentication
      • mTLS com certificados de CA pública de Google Trust Services, Let’s Encrypt, DigiCert e Sectigo
    • Aviso relacionado

  • mongosh e autocomplete do Node.js REPL

    • Aviso publicado em 30 de setembro de 2025
    • Distribuições de terceiros, como o MongoDB Shell instalado via Homebrew ou npm package manager, podem ser afetadas por um bug no Node.js REPL
    • Side effects não intencionais podem ocorrer durante o autocomplete
    • O escopo afetado é o mongosh anterior à versão 2.5.8 quando usado com Node.js 20.19.5–24.7.0
    • MONGOSH-2635

  • FIPS mode e OpenSSL 3

    • Aviso publicado em 11 de setembro de 2025
    • No Linux, uma configuração do MongoDB em FIPS mode que usa OpenSSL 3 para operações criptográficas pode usar algoritmos criptográficos do non-FIPS provider
    • Nesse caso, o client pode estabelecer conexão TLS com o MongoDB em FIPS mode usando um algoritmo criptográfico não compatível com FIPS
    • Versões afetadas:
      • 6.0.0–6.0.25
      • 7.0.0–7.0.22
      • 8.0.0–8.0.12
    • SERVER-109268

Avisos de segurança CVE de 2026

  • Vulnerabilidades do MongoDB Server

    • Em 12 de junho de 2026, a CVE-2026-11933 foi divulgada como uma vulnerabilidade post-authentication de use-after-free na conversão server-side JavaScript BSON-to-array, com pontuação 8.8
    • As versões afetadas são 8.3.3 e anteriores, 8.2.10 e anteriores, 8.0.25 e anteriores, 7.0.36 e anteriores, 6.0.28 e anteriores, 5.0.33 e anteriores e 4.4.30 e anteriores
    • SERVER-128125

  • Pre-authentication denial of service

    • A CVE-2026-9740 pode causar stack overflow pre-auth por recursão sem limite na interleaved-reference de BSONColumn, com pontuação 8.7
    • As versões afetadas são anteriores à 8.3.3, 8.2.10, 8.0.24 e 7.0.35
    • SERVER-125063
    • A CVE-2026-25611 é uma negação de serviço por esgotamento de memória em pre-authentication, em que uma mensagem não autenticada pode esgotar a memória, com pontuação 8.7
    • As versões afetadas são anteriores à 8.2.4, 8.0.18 e 7.0.29
    • SERVER-116210

  • Informações sensíveis registradas em logs

    • A CVE-2026-9735 trata de um problema em que o MongoDB Server pode registrar parâmetros de autenticação e credenciais no server log, afetando o MongoDB Server anterior à versão 8.3.3
    • SERVER-126506
    • A CVE-2026-9751 trata de um problema em que informações sensíveis podem ser registradas em mongod.log quando o parâmetro ldapQueryPassword é definido pelo comando de runtime setParameter
    • As versões afetadas são anteriores à 8.3.3, 8.2.10, 8.0.24 e 7.0.35
    • SERVER-123370

  • Crash do servidor e problemas de disponibilidade

    • A CVE-2026-9754 trata de um problema em que um authenticated user with read role pode ler parte de memória de stack não inicializada no comando filemd5, com pontuação 7.1
    • A CVE-2026-9753 pode causar server crash quando um malformed binary diff é passado para $_internalApplyOplogUpdate
    • A CVE-2026-9752 pode causar server crash durante a geração de chaves de índice 2dsphere quando há uma GeometryCollection com strict-winding polygon
    • A CVE-2026-9749 pode causar server crash ao usar MaxKey()

  • Drivers e ferramentas

    • A CVE-2026-9101 é uma prototype pollution no parsing de CSV do Compass, afetando o Compass da versão 1.36.3 até 1.49.5
    • A CVE-2026-9100 trata de leitura out-of-bounds de heap memory e crash no legacy GridFS file reader do C Driver
    • A CVE-2026-6811 pode causar crash de aplicação por stack exhaustion no MongoDB PHP driver
    • A CVE-2026-2303 permite crash de aplicação ou information leak por heap out-of-bounds read no wrapper C de GSSAPI do MongoDB Go Driver
    • A CVE-2026-2302 trata de unsafe reflection em Mongoid::Criteria.from_hash no MongoDB Ruby Driver

  • RCE no Ops Manager

    • A CVE-2026-8431 é uma RCE via webhook body no Ops Manager, com pontuação 9.4
    • Se um usuário administrativo puder configurar um webhook, certos valores no payload podem permitir a execução de comandos arbitrários
    • O escopo afetado vai do Ops Manager 7.0 até versões anteriores à 8.0.23
    • Ops Manager release notes

Famílias de produtos que apareceram com frequência em avisos de segurança desde 2025

  • MongoDB Server

    • CVEs relacionados a server crash, denial of service, privilege escalation, certificate validation, malformed BSON, aggregation, query planner, sharding e time series têm sido registrados repetidamente
    • As versões afetadas variam conforme o aviso entre as linhas MongoDB 5.0, 6.0, 7.0, 8.0, 8.1, 8.2 e 8.3

  • Clientes e drivers

    • C Driver, PHP Driver, Go Driver, Ruby Driver, Rust Driver, Node.js Driver, Java driver, .NET/C# Driver, PyMongo, libbson e js-bson aparecem como produtos afetados
    • Alguns itens tratam de exposição de dados relacionados à autenticação em command listener ou connection pool event listener

  • Ferramentas operacionais

    • Compass, mongosh, MongoDB for VS Code, Atlas Kubernetes Operator, Enterprise Kubernetes Operator, Ops Manager, Cloud Manager, BI Connector, Atlas SQL ODBC driver e Database Tools estão entre os produtos afetados
    • Também estão incluídos ausência de configuração de ACL no instalador MSI do Windows, local privilege escalation, control character injection e falhas de validação de entrada relacionadas a MITM

Avisos gerais de segurança

  • A seção General inclui atualizações sobre o incidente de segurança divulgado pela primeira vez em 16 de dezembro de 2023
  • Os itens de 28 e 29 de dezembro de 2023 afirmam que não foram encontradas evidências de acesso não autorizado a clusters MongoDB Atlas nem a dados de clientes armazenados em clusters Atlas
  • O item de 26 de dezembro de 2023 informa que clientes estavam enfrentando problemas de login devido a um aumento acentuado nas tentativas de acesso
  • O item de 24 de janeiro de 2024 anuncia a publicação do resumo pós-evento do MongoDB
  • MongoDB Security Incident Post Event Summary

Leituras relacionadas

1 comentários

 
GN⁺ 2023-12-18
Opiniões no Hacker News

  • No momento estou completamente bloqueado fora da conta Atlas e do portal de suporte
    Uso autenticação do Mongo e do Okta, mas todas as tentativas de login falham na tela de login com "The request contained invalid data."
    O problema é que o portal de suporte também exige autenticação, então, para obter ajuda com falha de autenticação, é preciso se autenticar
    Fico curioso para saber se outras pessoas também estão tendo problemas para acessar o dashboard
    Atualização: por volta das 17h15 no horário do leste dos EUA, a autenticação voltou a funcionar e o acesso ao dashboard também ficou disponível

    • Falando como funcionário da MongoDB, o problema de login não tem relação com o incidente de segurança
      Ao enviar a notificação a todos os clientes e usuários ao mesmo tempo, as tentativas de login dispararam
      Se ainda houver problemas de login, tente novamente daqui a alguns minutos
      Continuem acompanhando a página de alertas: https://www.mongodb.com/alerts
    • Ao tentar fazer login, aparece upstream request timeout
    • Estou passando pela mesma coisa com o Google SSO

  • Gosto do fato de o comunicado ser conciso e direto ao ponto
    Ele deixa claro que ainda estão em uma fase inicial, qual é o escopo conhecido no momento e que haverá atualizações conforme novas informações chegarem
    Espero que as pessoas não reajam punindo a MongoDB por não incluir mais informações quando a investigação obviamente ainda está no começo

    • Dizem que só foi detectado no dia 13 e que acreditam que tenha ocorrido por algum tempo
      Nem parece haver certeza de que dados de usuários foram acessados; dá a impressão de que ainda não disseram ou apenas disseram "não", então precisamos de uma resposta
    • Concordo
      A MongoDB recebe várias críticas, mas, desta vez, vale reconhecer, dando um passo atrás, a honestidade, transparência e confiança na resposta
      Gostaria que outras empresas seguissem essa abordagem e, por demonstrarem esses princípios diretamente, fiquei mais disposto a fazer negócios com a MongoDB

  • Está escrito regularly rotate their MongoDB Atlas passwords; perdi algum contexto?
    Ou uma equipe de segurança moderna realmente está recomendando troca periódica de senhas?

    • É bom rotacionar segredos de aplicações periodicamente
      Forçar usuários a trocar suas senhas regularmente não é muito bom

  • Se fui afetado, não sei como deveria monitorar comportamento anômalo nos sistemas
    Só olhar os logs não parece suficiente

  • Isso mostra o risco da centralização extrema
    Mesmo que clientes do Atlas não tenham sido diretamente afetados, é natural ficarem preocupados se, depois do comunicado, o site ou os canais de suporte ficarem sobrecarregados
    Para haver redundância real nesses casos, seria preciso haver mais provedores independentes de DBaaS MongoDB, mas isso ficou bastante limitado por causa da mudança de licença para SSPL
    Espero que o FerretDB consiga criar uma alternativa viável

    • “Centralização extrema”? Espere até a us-East-1 cair

  • O aviso de segurança que recebi hoje dizia que a MongoDB está investigando acesso não autorizado a alguns sistemas corporativos e que metadados de contas de clientes e informações de contato foram expostos
    No momento, dizem não ter conhecimento de que dados armazenados por clientes no MongoDB Atlas tenham sido expostos
    Disseram que detectaram atividade suspeita na noite de quarta-feira, 13 de dezembro de 2023, no horário do leste dos EUA, acionaram imediatamente os procedimentos de resposta a incidentes e acreditam que o acesso tenha persistido por algum período antes da descoberta
    Aos clientes, recomendaram ficar atentos a ataques de engenharia social e phishing, adotar autenticação multifator resistente a phishing e trocar senhas caso ainda não tenham feito isso, e disseram que informações adicionais seriam atualizadas em mongodb.com/alerts

    • Também recebi o mesmo e-mail
      Felizmente, na prática, não uso MongoDB Atlas

  • “Seus dados estão seguros. Afinal, nunca os gravamos no disco”

  • Nunca usei MongoDB e fico curioso sobre por que as pessoas escolhem MongoDB em vez de outros bancos de dados

    • É muito flexível
      Como você não desenvolve preso a um esquema, por exemplo, ao mudar recursos e dados rapidamente, não precisa se preocupar tanto com migrações
      Para uma startup que quer se mover rápido, isso é uma grande vantagem
      As consultas parecem código da aplicação, então há menos esforço mental para traduzir ideias em consultas SQL e, pela minha experiência, isso leva a consultas menos frágeis
      Injeções também costumam exigir menos preocupação, a menos que você crie deliberadamente uma estrutura perigosa, e acho mais fácil escrever consultas complexas do que em SQL
      Conversões de tipo também podem ser tratadas no código em vez de usar funções SQL inline específicas de plataforma, como field_name::timestamp
      Há uma base única para consultas e forma de desenvolvimento, e quase não há o desenvolvimento por dialetos como no SQL
      Na maioria dos casos de uso, escala razoavelmente bem e com facilidade, e, como há um único tipo de MongoDB, há menos espaço para confusão dogmática em torno de variantes específicas
    • Foi um pioneiro na época em que todo mundo achava que bancos de dados documentais NoSQL resolveriam todos os problemas
    • MongoDB é uma das principais opções NoSQL
      Se você acha que esquema flexível é bom, o MongoDB é ótimo; se acha que esquema flexível é ruim, ele não é tão bom
      Em resumo, é só isso
    • Uso on-premises, mais precisamente em um VPS
      É fácil armazenar e manipular documentos JSON
      Se seus dados têm formato de árvore, ele se encaixa muito bem mesmo com documentos grandes
      Se você depende de relações entre documentos, um banco de dados SQL é melhor, mas em muitos casos — na prática, quase todos os casos comuns — relações no estilo SQL não são realmente necessárias
      O MongoDB também lida com relações, mas é um pouco mais complicado
    • É bem fácil começar
      MQL também é fácil de entender e faz o MongoDB parecer divertido até certo ponto
      Para contextualizar, trabalho na MongoDB

  • Hoje em dia, fico curioso por que as pessoas continuam escolhendo MongoDB em vez de Postgres
    Quero sinceramente saber se há algo que estou perdendo, não sou contra dados JSON em si e uso com frequência tabelas jsonb no Postgres

    • O motivo para usar MongoDB é que é fácil começar
      Ele faz o “trabalho de banco de dados” e a “autenticação”
      Desisti de lutar contra esse fluxo e, quando vejo MongoDB sendo usado no início, passo a encarar imediatamente como um sinal de que os desenvolvedores ainda estão usando rodinhas