Aviso de seguridad de MongoDB

 (mongodb.com)
2 puntos por GN⁺ 2023-12-18 | 1 comentarios | Compartir por WhatsApp
  • MongoDB Alerts es un centro de avisos que reúne en un solo lugar problemas de integridad de datos, operaciones y seguridad CVE, para verificar el alcance del impacto por versión y qué despliegues de MongoDB requieren acción
  • La sección de integridad de datos de 2026 incluye errores de consultas de rango descendente sobre _id en clustered collections, permisividad de duplicados en unique index de sharded clusters, omisiones en Relational Migrator y no aplicación de read/write concern al conectarse directamente a un shard
  • En el aspecto operativo, hasta abril de 2026 las principales CA públicas dejarán de emitir certificados TLS con clientAuth EKU, lo que puede afectar configuraciones de mTLS y autenticación X.509 en MongoDB self-managed
  • La sección de seguridad ofrece listas de CVE por producto desde 2019 hasta 2026 para MongoDB Server, Compass, mongosh, drivers, Ops Manager y más
  • Quienes operan estos sistemas deben comparar las versiones en uso de Server, Atlas, Relational Migrator, Compass, mongosh y los drivers por lenguaje con el alcance afectado, y aplicar upgrades de versiones parcheadas o las configuraciones de mitigación anunciadas

Alcance que cubre la página MongoDB Alerts

  • MongoDB Alerts es una página que reúne alertas y recomendaciones importantes de MongoDB
  • La lista completa de bugs y solicitudes de funciones puede consultarse en MongoDB JIRA
  • Los nuevos avisos también se ofrecen vía RSS Feed
  • La página está compuesta por las siguientes categorías
    • Data Integrity Related
    • Operations Related
    • Security Related: Common Vulnerabilities and Exposures (CVEs)
    • General

Alertas de integridad de datos de 2026

  • Consultas de rango descendente sobre _id en clustered collections

    • Aviso del 17 de junio de 2026
    • Si en una clustered collection se aplica orden descendente al campo _id y se usan condiciones de rango con formas como {$lt: A}, {$gt: A}, {$gte: A, $lt: B}, {$gt: A, $lte: B}, los documentos de borde pueden incluirse o excluirse incorrectamente
    • No afecta a time series collections, non-clustered collections, clustered collections sin orden descendente sobre _id, ni a combinaciones de operadores de comparación con el mismo tipo de inclusión/exclusión
    • Versiones afectadas:
      • MongoDB 8.0.0–8.0.23
      • 8.2.0–8.2.9
      • 8.3.0–8.3.2
    • SERVER-121822

  • Garantía de unicidad en unique index de sharded clusters

    • Aviso del 14 de mayo de 2026
    • En un sharded cluster, si la shard key es igual al index key pattern o un strict prefix, y el unique index usa non-simple collation, puede que no se fuerce la unicidad entre shards
    • Valores como "YES" y "yes", que difieren en bytes pero son equivalentes según la collation, pueden insertarse por separado en shards distintos
    • Las condiciones del problema son: dos o más shards, un unique index con non-simple collation, y que la shard key sea igual al index key pattern o un strict prefix
    • Versiones afectadas:
      • 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

  • Omisiones en migraciones de Relational Migrator

    • Aviso del 14 de mayo de 2026
    • Quienes migraron con Relational Migrator pueden sufrir omisión de documentos en migraciones hacia sharded clusters cuando hay embedded documents o embedded arrays
    • Un cyclic mapping con foreign keys excluidas bajo un embedded array, columnas de tablas fuente usadas en varias relaciones de composite foreign key y la selección de field names en conflicto pueden producir omisiones, inconsistencias o campos mal nombrados
    • El producto afectado es MongoDB Relational Migrator anterior a 1.16.0
    • SERVER-126522

  • No aplicación de read/write concern al conectarse directamente a un shard

    • Aviso del 14 de mayo de 2026
    • Si se conecta directamente a un shard node sin pasar por mongos, puede que no se aplique el cluster-wide default read/write concern
    • En ese caso, las escrituras podrían ejecutarse con {w: 1} en vez del concern configurado, y si ocurre un rollback, podrían perderse escrituras reconocidas
    • En un sharded cluster solo se debe conectar a través de mongos
    • Si se necesita conexión directa al shard, se debe actualizar de inmediato a una versión parcheada o especificar un read/write concern explícito como {w: "majority"} en el connection string
    • Versiones afectadas:
      • 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

Patrones recurrentes en alertas recientes de integridad de datos

  • Sharding y migración

    • El aviso de marzo de 2026 trata el riesgo de pérdida de datos durante chunk migration en una sharded collection con un compound wildcard index que incluye un shard key prefix
    • En noviembre de 2025 se registró un problema donde una cross-shard transaction podía quedar parcialmente committed bajo ciertas condiciones de failover
    • En abril de 2024 se incluyó un problema donde una sharded multi-document transaction podía devolver datos incorrectos u omitir writes

  • Time series collections

    • El aviso de noviembre de 2025 informa que no se generan ni insertan 2dsphere index keys para metric data en una time series collection, lo que puede hacer que una geospatial query devuelva resultados incompletos
    • El aviso de agosto de 2025 trata un problema donde ciertos patrones de entrada de métricas en double-precision pueden causar corrupción de datos
    • El aviso de enero de 2025 incluye la posibilidad de pérdida de datos en time series collections con la combinación de inserts concurrentes ordered: false y retryable writes

  • Precisión de resultados de consultas

    • En marzo de 2026 se registró un problema donde una aggregation query con $group inmediatamente después de $sort y usando acumuladores $top o $bottom puede devolver resultados incorrectos
    • En febrero de 2026, la interfaz SQL puede devolver resultados incorrectos cuando en la cláusula WHERE una condición OR es UNKNOWN y la otra es TRUE
    • En junio de 2025, una query con $elemMatch y un string predicate puede usar un index con collation incompatible y omitir documentos que deberían incluirse

Alertas relacionadas con operaciones

  • Cambio de política de clientAuth EKU en CA públicas

    • Aviso del 22 de enero de 2026
    • Las principales Certificate Authority públicas están aplicando un requisito de política para dejar de emitir, antes de abril de 2026, certificados TLS que incluyan Extended Key Usage de client authentication (clientAuth)
    • Este cambio solo afecta a los despliegues self-managed de MongoDB que usan certificados de CA públicas para mutual TLS (mTLS) o autenticación X.509
    • Los clientes self-managed deben migrar a una private PKI infrastructure o cambiar la configuración de MongoDB antes de las fechas límite de abril y mayo de 2026
    • Los clientes de Atlas no se ven afectados
    • Alcance afectado:
      • X.509 Cluster Authentication
      • X.509 Client Authentication
      • mTLS que usa certificados de CA públicas de Google Trust Services, Let’s Encrypt, DigiCert y Sectigo
    • Aviso relacionado

  • mongosh y autocomplete de Node.js REPL

    • Aviso del 30 de septiembre de 2025
    • Distribuciones de terceros como MongoDB Shell instaladas mediante Homebrew o npm package manager pueden verse afectadas por un bug de Node.js REPL
    • Durante el autocomplete pueden ocurrir side effects no intencionales
    • El alcance afectado es mongosh anterior a 2.5.8 cuando se usa con Node.js 20.19.5–24.7.0
    • MONGOSH-2635

  • FIPS mode y OpenSSL 3

    • Aviso del 11 de septiembre de 2025
    • En Linux, MongoDB configurado en FIPS mode que usa OpenSSL 3 para operaciones criptográficas puede utilizar algoritmos criptográficos del non-FIPS provider
    • En ese caso, un cliente podría establecer una conexión TLS hacia MongoDB en modo FIPS usando algoritmos criptográficos no compatibles con FIPS
    • Versiones afectadas:
      • 6.0.0–6.0.25
      • 7.0.0–7.0.22
      • 8.0.0–8.0.12
    • SERVER-109268

Avisos de seguridad CVE de 2026

  • Vulnerabilidades de MongoDB Server

    • CVE-2026-11933, del 12 de junio de 2026, es una vulnerabilidad post-authentication de use-after-free en la conversión server-side JavaScript BSON-to-array, con puntuación de 8.8
    • Las versiones afectadas son 8.3.3 y anteriores, 8.2.10 y anteriores, 8.0.25 y anteriores, 7.0.36 y anteriores, 6.0.28 y anteriores, 5.0.33 y anteriores y 4.4.30 y anteriores
    • SERVER-128125

  • Pre-authentication denial of service

    • CVE-2026-9740 puede provocar un pre-auth stack overflow por recursión no acotada en BSONColumn interleaved-reference, con puntuación de 8.7
    • Las versiones afectadas son anteriores a 8.3.3, anteriores a 8.2.10, anteriores a 8.0.24 y anteriores a 7.0.35
    • SERVER-125063
    • CVE-2026-25611 es un pre-authentication memory exhaustion denial of service donde un mensaje no autenticado puede agotar la memoria, con puntuación de 8.7
    • Las versiones afectadas son anteriores a 8.2.4, anteriores a 8.0.18 y anteriores a 7.0.29
    • SERVER-116210

  • Información sensible registrada en logs

    • CVE-2026-9735 es un problema donde MongoDB Server puede registrar authentication parameters y credentials en el server log, y afecta a MongoDB Server anteriores a 8.3.3
    • SERVER-126506
    • CVE-2026-9751 es un problema donde información sensible puede quedar registrada en mongod.log cuando el parámetro ldapQueryPassword se configura con el comando runtime setParameter
    • Las versiones afectadas son anteriores a 8.3.3, anteriores a 8.2.10, anteriores a 8.0.24 y anteriores a 7.0.35
    • SERVER-123370

  • Crash del servidor y problemas de disponibilidad

    • CVE-2026-9754 es un problema donde un authenticated user with read role puede leer parte de memoria de stack no inicializada en el comando filemd5, con puntuación de 7.1
    • CVE-2026-9753 puede causar un server crash cuando un malformed binary diff se pasa a $_internalApplyOplogUpdate
    • CVE-2026-9752 puede provocar un server crash durante la generación de 2dsphere index keys cuando una GeometryCollection tiene un strict-winding polygon
    • CVE-2026-9749 puede causar un server crash al usar MaxKey()

  • Drivers y herramientas

    • CVE-2026-9101 es prototype pollution en el parsing de CSV de Compass, y afecta a Compass 1.36.3 a 1.49.5
    • CVE-2026-9100 es un problema de heap memory out-of-bounds read y crash en el legacy GridFS file reader del C Driver
    • CVE-2026-6811 puede causar crash de la aplicación por stack exhaustion en el MongoDB PHP driver
    • CVE-2026-2303 permite crash de la aplicación o information leak por heap out-of-bounds read en el wrapper C de GSSAPI del MongoDB Go Driver
    • CVE-2026-2302 es un problema de unsafe reflection en Mongoid::Criteria.from_hash del MongoDB Ruby Driver

  • RCE en Ops Manager

    • CVE-2026-8431 es una RCE a través del webhook body de Ops Manager, con puntuación de 9.4
    • Si un administrative user puede configurar un webhook, ciertos valores dentro del payload pueden ejecutar comandos arbitrarios
    • El alcance afectado va desde Ops Manager 7.0 hasta antes de 8.0.23
    • Ops Manager release notes

Familias de productos que aparecen con frecuencia en avisos de seguridad desde 2025

  • MongoDB Server

    • Se repiten CVE relacionados con server crash, denial of service, privilege escalation, validación de certificados, malformed BSON, aggregation, query planner, sharding y time series
    • Las versiones afectadas varían por aviso y abarcan las ramas MongoDB 5.0, 6.0, 7.0, 8.0, 8.1, 8.2 y 8.3

  • Clientes y drivers

    • C Driver, PHP Driver, Go Driver, Ruby Driver, Rust Driver, Node.js Driver, Java driver, .NET/C# Driver, PyMongo, libbson y js-bson aparecen como productos afectados
    • Algunos avisos tratan problemas donde datos relacionados con autenticación quedan expuestos a command listener o connection pool event listener

  • Herramientas operativas

    • Compass, mongosh, MongoDB for VS Code, Atlas Kubernetes Operator, Enterprise Kubernetes Operator, Ops Manager, Cloud Manager, BI Connector, Atlas SQL ODBC driver y Database Tools están incluidos entre los productos afectados
    • Se incluyen problemas como omisiones de configuración ACL en MSI de instalación de Windows, local privilege escalation, control character injection e insuficiente validación de entrada relacionada con MITM

Avisos generales de seguridad

  • La sección General incluye actualizaciones sobre el security incident divulgado por primera vez el 16 de diciembre de 2023
  • Las entradas del 28 y 29 de diciembre de 2023 indican que no se encontró evidencia de unauthorized access a customer data almacenada en clusters de MongoDB Atlas o en Atlas clusters
  • La entrada del 26 de diciembre de 2023 informa problemas de inicio de sesión de clientes debido a un aumento en login attempts
  • La entrada del 24 de enero de 2024 informa la publicación del post event summary de MongoDB
  • MongoDB Security Incident Post Event Summary

Lecturas relacionadas

1 comentarios

 
GN⁺ 2023-12-18
Comentarios de Hacker News

  • Ahora mismo estoy completamente bloqueado de mi cuenta de Atlas y el portal de soporte
    Uso autenticación de Mongo y Okta, pero todos los intentos de inicio de sesión fallan en la pantalla de login con "The request contained invalid data."
    El problema es que el portal de soporte también requiere autenticación, así que para pedir ayuda por una falla de autenticación, primero hay que autenticarse
    Me pregunto si alguien más está teniendo problemas para entrar al panel
    Actualización: alrededor de las 5:15 p. m., hora del Este de EE. UU., la autenticación volvió a funcionar y ya pude acceder al panel

    • Hablando como empleado de MongoDB, el problema de inicio de sesión no está relacionado con el incidente de seguridad
      Al enviar notificaciones a todos los clientes y usuarios al mismo tiempo, se dispararon los intentos de login
      Si todavía tienen problemas para iniciar sesión, intenten de nuevo en unos minutos
      Sigan revisando la página de alertas: https://www.mongodb.com/alerts
    • Cuando intento iniciar sesión, aparece upstream request timeout
    • Me pasa lo mismo con Google SSO

  • Me gusta que el comunicado sea breve y vaya al grano
    Deja claro que esto sigue en una etapa inicial, cuál es el alcance conocido hasta ahora, y que habrá actualizaciones posteriores conforme llegue más información
    Ojalá la gente no reaccione castigando a MongoDB solo porque no metieron más información cuando la investigación claramente está en una fase temprana

    • Dice que lo detectaron hasta el día 13 y que creen que llevaba ocurriendo ya desde hace algún tiempo
      Tampoco está claro en absoluto si los datos de usuarios fueron alcanzados, así que hace falta una respuesta y no solo la sensación de que aún no la dan o de que simplemente dicen "no"
    • De acuerdo
      MongoDB recibe muchas críticas, pero en esta ocasión hay que reconocerles un paso en la dirección correcta en términos de honestidad, transparencia y confianza
      Ojalá otras empresas siguieran este enfoque y, como aquí demostraron esos principios de forma directa, me dan más ganas de hacer negocios con MongoDB

  • Dice regularly rotate their MongoDB Atlas passwords; ¿me perdí algún contexto?
    ¿O de verdad un equipo de seguridad moderno sigue recomendando cambiar contraseñas periódicamente?

    • Rotar secretos para aplicaciones periódicamente sí es bueno
      Obligar a los usuarios a cambiar sus contraseñas de forma regular no lo es tanto

  • Si fui afectado, no sé cómo debería monitorear comportamientos anómalos en el sistema
    Solo mirar los logs no parece suficiente

  • Esto muestra el riesgo de la centralización extrema
    Aunque los clientes de Atlas no se vieran afectados directamente, es natural preocuparse si después del aviso se saturan el sitio web o los canales de soporte
    Para dar redundancia real en un caso así, tendría que haber más proveedores independientes de MongoDB DBaaS, pero eso quedó muy limitado por el cambio de licencia a SSPL
    Ojalá FerretDB logre construir una alternativa viable

    • ¿“Centralización extrema”? Espera a que se caiga us-East-1

  • El aviso de seguridad que recibí hoy decía que MongoDB está investigando un acceso no autorizado a algunos de sus sistemas corporativos y que quedaron expuestos metadatos de cuentas de clientes e información de contacto
    Por ahora dicen que no tienen constancia de que se hayan expuesto datos almacenados por clientes en MongoDB Atlas
    Detectaron actividad sospechosa la noche del miércoles 13 de diciembre de 2023, hora del Este de EE. UU., activaron de inmediato sus procedimientos de respuesta a incidentes y creen que el acceso continuó durante cierto periodo antes del descubrimiento
    A los clientes les recomendaron estar atentos a ataques de ingeniería social y phishing y, si aún no lo habían hecho, activar MFA resistente al phishing y cambiar contraseñas; además, actualizarán más información en mongodb.com/alerts

    • Yo también recibí el mismo correo
      Por suerte en realidad no uso MongoDB Atlas

  • “Sus datos están seguros. Nunca los escribimos en disco en primer lugar.”

  • Nunca he usado MongoDB, pero me da curiosidad por qué la gente lo elige en vez de otras bases de datos

    • Es muy flexible
      Como no desarrollas contra un esquema fijo, por ejemplo, cuando quieres cambiar rápido funcionalidades y datos, no tienes que preocuparte tanto por migraciones
      Para startups que quieren moverse rápido, eso es una gran ventaja
      Las consultas se parecen al código de la aplicación, así que uno se rompe menos la cabeza traduciendo ideas a consultas SQL y, en mi experiencia, eso termina en consultas menos frágiles
      Los ataques de inyección también suelen preocupar menos, salvo que diseñes algo peligroso a propósito, y me parece más fácil escribir consultas complejas que en SQL
      Conversiones de tipo también se pueden manejar en código en lugar de depender de funciones SQL inline específicas de cada plataforma como field_name::timestamp
      Hay un solo estándar para consultas y forma de desarrollo, y casi no existe esa necesidad de desarrollar por dialectos como pasa con SQL
      Escala bastante bien y con relativa facilidad para la mayoría de los casos de uso, y como hay básicamente una sola clase de MongoDB, también hay menos espacio para confusiones doctrinarias sobre una variante específica
    • Fue de los primeros en moverse en la época en que todo el mundo creía que una base de datos documental NoSQL resolvía todos los problemas
    • MongoDB es la opción NoSQL más representativa
      Si te parece buena idea un esquema flexible, MongoDB es excelente; si te parece mala idea, no tanto
      En resumen, eso es todo
    • Lo uso on-premises, más exactamente en un VPS
      Es fácil almacenar y manipular documentos JSON
      Si tus datos tienen forma de árbol, funciona bastante bien incluso con documentos grandes
      Si dependes de relaciones entre documentos, una base de datos SQL es mejor, pero en muchos casos —de hecho, en casi todos los casos comunes— no necesitas relaciones al estilo SQL
      MongoDB también puede manejar relaciones, pero es un poco más complejo
    • Es bastante fácil empezar
      MQL también es fácil de entender, y hace que MongoDB se sienta hasta cierto punto divertido de usar
      Por cierto, trabajo en MongoDB

  • Últimamente me pregunto por qué la gente sigue eligiendo MongoDB en vez de Postgres
    Si se me está escapando algo, de verdad me gustaría saberlo, y no estoy en contra de los datos JSON como tal; de hecho uso mucho tablas jsonb en Postgres

    • La razón para usar MongoDB es que es fácil empezar con él
      Te resuelve “cosas de base de datos” y “autenticación”
      Ya me rendí en pelear contra ese flujo, y cuando veo que usan MongoDB al principio, lo tomo de inmediato como una señal de que los desarrolladores todavía traen rueditas de entrenamiento