Avis de sécurité MongoDB

 (mongodb.com)
2 points par GN⁺ 2023-12-18 | 1 commentaires | Partager sur WhatsApp
  • MongoDB Alerts est un hub d’avis qui regroupe au même endroit les problèmes d’intégrité des données, d’exploitation et de sécurité CVE, afin de vérifier l’étendue de l’impact par version et les déploiements MongoDB nécessitant une action
  • Les éléments d’intégrité des données de 2026 incluent une erreur sur les requêtes de plage en ordre décroissant sur _id dans les clustered collections, l’autorisation de doublons dans les unique indexes des sharded clusters, des omissions dans Relational Migrator, ainsi que la non-application du read/write concern lors d’une connexion directe à un shard
  • Côté exploitation, d’ici avril 2026, les principales CA publiques cesseront d’émettre des certificats TLS incluant l’EKU clientAuth, ce qui peut affecter les configurations mTLS et d’authentification X.509 des déploiements MongoDB self-managed
  • La section sécurité fournit, par produit, une liste de CVE de 2019 à 2026 pour MongoDB Server, Compass, mongosh, les drivers, Ops Manager, etc.
  • Les praticiens doivent comparer les versions utilisées de Server, Atlas, Relational Migrator, Compass, mongosh et des drivers par langage avec les périmètres d’impact, puis mettre à niveau vers les versions corrigées ou appliquer les contournements annoncés

Périmètre couvert par la page MongoDB Alerts

  • MongoDB Alerts est une page qui rassemble les alertes et recommandations importantes de MongoDB
  • La liste complète des bugs et demandes de fonctionnalités est disponible dans MongoDB JIRA
  • Les nouveaux avis sont également fournis via un flux RSS
  • La page est organisée selon les catégories suivantes
    • Data Integrity Related
    • Operations Related
    • Security Related: Common Vulnerabilities and Exposures (CVEs)
    • General

Alertes d’intégrité des données en 2026

  • Requêtes de plage en ordre décroissant sur _id dans les clustered collections

    • Avis du 17 juin 2026
    • Dans une clustered collection, si un tri décroissant est appliqué au champ _id et que des conditions de plage de la forme {$lt: A}, {$gt: A}, {$gte: A, $lt: B}, {$gt: A, $lte: B} sont utilisées, des documents situés aux bornes peuvent être inclus ou exclus à tort
    • Les time series collections, les non-clustered collections, les clustered collections sans tri décroissant sur _id, ainsi que les combinaisons d’opérateurs de comparaison du même type inclusion/exclusion ne sont pas affectées
    • Versions affectées :
      • MongoDB 8.0.0–8.0.23
      • 8.2.0–8.2.9
      • 8.3.0–8.3.2
    • SERVER-121822

  • Garantie d’unicité des unique indexes dans les sharded clusters

    • Avis du 14 mai 2026
    • Dans un sharded cluster, si la shard key est identique au key pattern de l’index ou en est un strict prefix, et qu’un unique index utilise une collation non-simple, l’unicité peut ne pas être imposée entre shards
    • Des valeurs dont les octets diffèrent mais qui sont identiques selon la collation, comme "YES" et "yes", peuvent être insérées indépendamment sur des shards différents
    • Les conditions du problème sont : au moins deux shards, un unique index avec collation non-simple, et une shard key identique au key pattern de l’index ou constituant un strict prefix de celui-ci
    • Versions affectées :
      • 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

  • Omissions de migration dans Relational Migrator

    • Avis du 14 mai 2026
    • Les utilisateurs ayant migré avec Relational Migrator peuvent subir des omissions de documents dans une migration de sharded cluster lorsque des embedded documents ou embedded arrays sont présents
    • Un cyclic mapping avec une foreign key exclue sous un embedded array, une colonne de table source utilisée dans plusieurs relations de composite foreign keys, ou le choix de field names conflictuels peuvent produire des champs manquants, incohérents ou mal nommés
    • Le produit affecté est MongoDB Relational Migrator antérieur à 1.16.0
    • SERVER-126522

  • Non-application du read/write concern lors d’une connexion directe à un shard

    • Avis du 14 mai 2026
    • En se connectant directement à un shard node sans passer par mongos, le cluster-wide default read/write concern peut ne pas être appliqué
    • Dans ce cas, les writes peuvent être effectués avec {w: 1} au lieu du concern configuré, et des acknowledged writes peuvent être perdus en cas de rollback
    • Il faut se connecter aux sharded clusters uniquement via mongos
    • Si une connexion directe à un shard est nécessaire, il faut mettre à niveau immédiatement vers une version corrigée ou spécifier explicitement un read/write concern, par exemple {w: "majority"}, dans la connection string
    • Versions affectées :
      • 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

Motifs récurrents dans les alertes récentes d’intégrité des données

  • Sharding et migration

    • L’entrée de mars 2026 traite du risque de perte de données pendant la chunk migration dans une sharded collection ayant un compound wildcard index incluant le shard key prefix
    • En novembre 2025, un problème indiquait que des cross-shard transactions pouvaient être partiellement commit dans certaines conditions de failover
    • En avril 2024, un problème indiquait que des sharded multi-document transactions pouvaient renvoyer des données incorrectes ou omettre des writes

  • Time series collections

    • L’entrée de novembre 2025 signale que les clés d’index 2dsphere pour les metric data d’une time series collection peuvent ne pas être générées ni insérées, ce qui peut amener les geospatial queries à renvoyer des résultats incomplets
    • L’entrée d’août 2025 traite d’un problème où certains schémas d’entrée de métriques en double précision peuvent entraîner une corruption de données
    • L’entrée de janvier 2025 inclut une possibilité de perte de données dans les time series collections avec la combinaison d’inserts concurrents ordered: false et de retryable writes

  • Exactitude des résultats de requête

    • En mars 2026, un problème a été enregistré : une aggregation query où $group suit immédiatement $sort et utilise l’accumulator $top ou $bottom peut renvoyer des résultats incorrects
    • En février 2026, l’interface SQL peut renvoyer des résultats incorrects lorsqu’une condition OR de la clause WHERE vaut UNKNOWN et l’autre vaut TRUE
    • En juin 2025, une requête avec $elemMatch et un prédicat sur chaîne peut utiliser un index dont la collation ne correspond pas et omettre des documents qui auraient dû être inclus

Alertes liées à l’exploitation

  • Changement de politique des CA publiques concernant l’EKU clientAuth

    • Avis du 22 janvier 2026
    • Les principales Certificate Authorities publiques appliquent une exigence de politique mettant fin, d’ici avril 2026, à l’émission de certificats TLS incluant l’Extended Key Usage client authentication (clientAuth)
    • Ce changement n’affecte que les déploiements MongoDB self-managed utilisant des certificats de CA publiques pour mutual TLS (mTLS) ou l’authentification X.509
    • Les clients self-managed doivent migrer vers une private PKI infrastructure ou modifier la configuration MongoDB avant les échéances d’avril–mai 2026
    • Les clients Atlas ne sont pas affectés
    • Périmètre d’impact :
      • X.509 Cluster Authentication
      • X.509 Client Authentication
      • mTLS utilisant des certificats de CA publiques de Google Trust Services, Let’s Encrypt, DigiCert, Sectigo
    • Avis associé

  • mongosh et autocomplete du REPL Node.js

    • Avis du 30 septembre 2025
    • Les third-party distributions, comme MongoDB Shell installé via Homebrew ou le package manager npm, peuvent être affectées par un bug du REPL Node.js
    • Des side effects involontaires peuvent se produire pendant l’autocomplete
    • Le périmètre d’impact concerne mongosh antérieur à 2.5.8 utilisé avec Node.js 20.19.5–24.7.0
    • MONGOSH-2635

  • Mode FIPS et OpenSSL 3

    • Avis du 11 septembre 2025
    • Sur Linux, MongoDB configuré en mode FIPS et utilisant OpenSSL 3 pour les cryptographic operations peut utiliser des algorithmes cryptographiques d’un provider non-FIPS
    • Dans ce cas, un client peut établir une connexion TLS à MongoDB en mode FIPS avec un algorithme cryptographique non conforme FIPS
    • Versions affectées :
      • 6.0.0–6.0.25
      • 7.0.0–7.0.22
      • 8.0.0–8.0.12
    • SERVER-109268

Avis de sécurité CVE en 2026

  • Vulnérabilités de MongoDB Server

    • CVE-2026-11933, publié le 12 juin 2026, est une vulnérabilité use-after-free post-authentication dans la conversion BSON-to-array côté serveur JavaScript, avec un score de 8,8
    • Les versions affectées sont 8.3.3 et antérieures, 8.2.10 et antérieures, 8.0.25 et antérieures, 7.0.36 et antérieures, 6.0.28 et antérieures, 5.0.33 et antérieures, 4.4.30 et antérieures
    • SERVER-128125

  • Denial of service pre-authentication

    • CVE-2026-9740 peut provoquer un stack overflow pre-auth par récursion non bornée de BSONColumn interleaved-reference, avec un score de 8,7
    • Les versions affectées sont antérieures à 8.3.3, antérieures à 8.2.10, antérieures à 8.0.24, antérieures à 7.0.35
    • SERVER-125063
    • CVE-2026-25611 est un denial of service par épuisement mémoire pre-authentication, capable d’épuiser la mémoire via un message non authentifié, avec un score de 8,7
    • Les versions affectées sont antérieures à 8.2.4, antérieures à 8.0.18, antérieures à 7.0.29
    • SERVER-116210

  • Informations sensibles dans les logs

    • CVE-2026-9735 est un problème par lequel MongoDB Server peut enregistrer des authentication parameters et credentials dans les server logs ; le périmètre d’impact concerne MongoDB Server antérieur à 8.3.3
    • SERVER-126506
    • CVE-2026-9751 est un problème où des informations sensibles peuvent être enregistrées dans mongod.log lorsque le paramètre ldapQueryPassword est défini via la commande runtime setParameter
    • Les versions affectées sont antérieures à 8.3.3, antérieures à 8.2.10, antérieures à 8.0.24, antérieures à 7.0.35
    • SERVER-123370

  • Crashs serveur et problèmes de disponibilité

    • CVE-2026-9754 est un problème dans la commande filemd5 permettant à un authenticated user with read role de lire une partie de la mémoire de pile non initialisée ; son score est de 7,1
    • CVE-2026-9753 peut provoquer un crash serveur lorsqu’un malformed binary diff est transmis à $_internalApplyOplogUpdate
    • CVE-2026-9752 peut provoquer un crash serveur pendant la génération de clé d’index 2dsphere avec une GeometryCollection contenant un strict-winding polygon
    • CVE-2026-9749 peut entraîner un crash serveur lors de l’utilisation de MaxKey()

  • Drivers et outils

    • CVE-2026-9101 est une prototype pollution dans le parsing CSV de Compass ; les versions affectées vont de Compass 1.36.3 à 1.49.5
    • CVE-2026-9100 est un problème de lecture heap memory out-of-bounds et de crash dans le lecteur de fichiers GridFS legacy du C Driver
    • CVE-2026-6811 peut provoquer un crash applicatif par stack exhaustion dans le MongoDB PHP driver
    • CVE-2026-2303 permet un crash applicatif ou une fuite d’informations via une lecture heap out-of-bounds dans le wrapper C GSSAPI du MongoDB Go Driver
    • CVE-2026-2302 est un problème d’unsafe reflection dans Mongoid::Criteria.from_hash du MongoDB Ruby Driver

  • RCE dans Ops Manager

    • CVE-2026-8431 est une RCE via le body d’un webhook Ops Manager, avec un score de 9,4
    • Si un administrative user peut configurer un webhook, certaines valeurs du payload peuvent permettre l’exécution de commandes arbitraires
    • Le périmètre d’impact va d’Ops Manager 7.0 à avant 8.0.23
    • Notes de version d’Ops Manager

Familles de produits souvent présentes dans les avis de sécurité depuis 2025

  • MongoDB Server

    • Des CVE liées aux server crashes, denial of service, privilege escalation, certificate validation, malformed BSON, aggregation, query planner, sharding et time series sont régulièrement enregistrées
    • Les versions affectées varient selon l’avis et couvrent les branches MongoDB 5.0, 6.0, 7.0, 8.0, 8.1, 8.2 et 8.3

  • Clients et drivers

    • C Driver, PHP Driver, Go Driver, Ruby Driver, Rust Driver, Node.js Driver, Java driver, .NET/C# Driver, PyMongo, libbson et js-bson apparaissent parmi les produits affectés
    • Certains éléments traitent de problèmes où des authentication-related data sont exposées à un command listener ou à un connection pool event listener

  • Outils d’exploitation

    • Compass, mongosh, MongoDB for VS Code, Atlas Kubernetes Operator, Enterprise Kubernetes Operator, Ops Manager, Cloud Manager, BI Connector, Atlas SQL ODBC driver et Database Tools figurent parmi les produits affectés
    • Les problèmes incluent l’absence de configuration ACL dans les MSI d’installation Windows, la local privilege escalation, la control character injection et un manque de validation d’entrée lié au MITM

Avis de sécurité généraux

  • La section General inclut des mises à jour sur un security incident rendu public pour la première fois le 16 décembre 2023
  • Les entrées des 28 et 29 décembre 2023 indiquent n’avoir trouvé aucune preuve d’un unauthorized access à des MongoDB Atlas clusters ni à des customer data stockées dans des Atlas clusters
  • L’entrée du 26 décembre 2023 signale que des problèmes de connexion client sont en cours en raison d’une forte hausse des login attempts
  • L’entrée du 24 janvier 2024 annonce la publication par MongoDB du post event summary
  • MongoDB Security Incident Post Event Summary

À lire aussi

1 commentaires

 
GN⁺ 2023-12-18
Avis sur Hacker News

  • Je suis actuellement complètement bloqué hors de mon compte Atlas et du portail de support
    J’utilise l’authentification Mongo et Okta, et toutes les tentatives de connexion échouent sur l’écran de login avec « The request contained invalid data. »
    Le problème, c’est que le portail de support nécessite lui aussi une authentification : pour obtenir de l’aide sur un échec d’authentification, il faut s’authentifier
    Je me demande si d’autres ont aussi des problèmes d’accès au tableau de bord
    Ajout : vers 17 h 15, heure de l’Est des États-Unis, l’authentification s’est remise à fonctionner et l’accès au tableau de bord est redevenu possible

    • En tant qu’employé de MongoDB, je précise que les problèmes de connexion sont sans rapport avec l’incident de sécurité
      L’envoi simultané de notifications à tous les clients et utilisateurs a provoqué un pic de tentatives de connexion
      Si vous rencontrez encore des problèmes de connexion, veuillez réessayer dans quelques minutes
      Continuez à consulter la page d’alerte : https://www.mongodb.com/alerts
    • Quand j’essaie de me connecter, j’obtiens upstream request timeout
    • Même chose avec le SSO Google

  • J’apprécie que l’annonce soit concise et aille droit au but
    Elle dit clairement que l’enquête en est encore à ses débuts, quelle est l’étendue actuellement connue, et que des mises à jour suivront au fur et à mesure que les informations arriveront
    J’espère qu’on ne va pas réagir comme si MongoDB devait être sanctionné pour ne pas avoir inclus davantage d’informations alors que l’enquête en est manifestement à un stade très précoce

    • Il est indiqué que cela n’a été détecté que le 13, et qu’ils pensent que cela durait depuis un certain temps
      On ne sait même pas vraiment si les données des utilisateurs ont été touchées ; j’ai l’impression qu’ils ne l’ont pas encore communiqué, ou qu’ils se contentent de dire « non », et il faut une réponse
    • D’accord
      MongoDB reçoit beaucoup de critiques, mais sur cette réponse, il faut prendre du recul et reconnaître l’honnêteté, la transparence et la confiance dont ils font preuve
      J’aimerais que d’autres entreprises adoptent cette approche, et le fait que MongoDB ait concrètement montré ces principes me donne davantage envie de travailler avec eux

  • Il est écrit regularly rotate their MongoDB Atlas passwords ; est-ce qu’un contexte m’a échappé ?
    Ou bien les équipes de sécurité modernes recommandent-elles vraiment de changer régulièrement les mots de passe ?

    • Faire tourner régulièrement les secrets applicatifs, c’est une bonne pratique
      Forcer les utilisateurs à changer périodiquement leur mot de passe, beaucoup moins

  • Si l’on est concerné, je ne vois pas bien comment surveiller les comportements anormaux dans le système
    Se contenter de regarder les logs ne semble pas suffisant

  • Cette affaire montre les risques d’une centralisation extrême
    Même si les clients Atlas n’ont pas été directement touchés, il est naturel de s’inquiéter si, après l’annonce, le site web ou les canaux de support sont submergés
    Dans ce genre de cas, pour offrir une vraie redondance, il faudrait davantage de fournisseurs MongoDB DBaaS indépendants, mais le changement de licence SSPL les limite fortement
    J’espère que FerretDB parviendra à créer une alternative viable

    • Une « centralisation extrême » ? Attends de voir quand us-East-1 tombera

  • L’avis de sécurité reçu aujourd’hui indiquait que MongoDB enquêtait sur un accès non autorisé à certains systèmes de l’entreprise, et que des métadonnées de comptes clients ainsi que des informations de contact avaient été exposées
    À ce stade, ils disent ne pas avoir connaissance d’une exposition des données stockées par les clients dans MongoDB Atlas
    Ils ont détecté une activité suspecte le mercredi 13 décembre 2023 au soir, heure de l’Est des États-Unis, ont immédiatement déclenché leurs procédures de réponse à incident, et pensent que l’accès a duré un certain temps avant sa découverte
    Ils demandent aux clients de rester vigilants face aux attaques d’ingénierie sociale et de phishing, recommandent, si ce n’est pas déjà fait, d’utiliser une authentification multifacteur résistante au phishing et de changer les mots de passe, et indiquent que des informations supplémentaires seront mises à jour sur mongodb.com/alerts

    • J’ai reçu le même e-mail
      Heureusement, je n’utilise pas vraiment MongoDB Atlas

  • « Vos données sont en sécurité. De toute façon, nous ne les avons jamais écrites sur disque. »

  • Je n’ai jamais utilisé MongoDB, et je me demande pourquoi les gens choisissent MongoDB plutôt qu’une autre base de données

    • C’est très flexible
      Comme on ne développe pas en fonction d’un schéma, par exemple lorsqu’on modifie rapidement des fonctionnalités et des données, on a beaucoup moins à se soucier des migrations
      Pour une startup qui veut avancer vite, c’est un gros avantage
      Les requêtes ressemblent au code applicatif, ce qui évite de se creuser la tête pour traduire ses idées en requêtes SQL et, d’après mon expérience, donne des requêtes moins fragiles
      Les attaques par injection sont aussi moins préoccupantes, sauf à concevoir volontairement une structure dangereuse, et je trouve qu’il est plus facile d’écrire des requêtes complexes qu’en SQL
      Les conversions de type peuvent aussi être gérées dans le code plutôt qu’avec des fonctions SQL inline propres à chaque plateforme comme field_name::timestamp
      Il y a une référence unique pour les requêtes et la façon de développer, et on développe rarement dialecte par dialecte comme en SQL
      Dans la plupart des cas d’usage, ça passe assez bien à l’échelle et plutôt facilement, et comme il n’existe qu’un seul MongoDB, il y a peu de risque de confusion dogmatique autour d’une variante particulière
    • C’était l’un des premiers acteurs à l’époque où tout le monde pensait que les bases de données documentaires NoSQL résoudraient tous les problèmes
    • MongoDB est l’option NoSQL emblématique
      Si vous pensez qu’un schéma flexible est une bonne chose, MongoDB est excellent ; si vous pensez qu’un schéma flexible est une mauvaise chose, il l’est beaucoup moins
      En résumé, c’est à peu près tout
    • Je l’utilise on-premise, plus précisément sur un VPS
      Il est facile d’y stocker et de manipuler des documents JSON
      Si vos données ressemblent à un arbre, cela convient plutôt bien, même pour de gros documents
      Si vous dépendez de relations entre documents, une base SQL est préférable, mais dans beaucoup de cas — en fait dans presque tous les cas ordinaires — les relations façon SQL ne sont pas indispensables
      MongoDB gère aussi les relations, mais c’est un peu plus compliqué
    • C’est assez facile pour démarrer
      MQL est aussi facile à comprendre, et rend MongoDB assez agréable à utiliser
      Pour info, je travaille chez MongoDB

  • Je me demande pourquoi, aujourd’hui, les gens continuent de choisir MongoDB plutôt que Postgres
    Si quelque chose m’échappe, j’aimerais vraiment le savoir ; je ne suis pas non plus opposé aux données JSON en soi et j’utilise souvent des tables jsonb dans Postgres

    • La raison d’utiliser MongoDB, c’est qu’il est facile de démarrer
      Il fait le « travail de base de données » et l’« authentification »
      J’ai renoncé à lutter contre ce courant, et quand je vois MongoDB utilisé au début d’un projet, je le prends désormais immédiatement comme le signe que les développeurs ont encore des roulettes