Skip to content
Hacker Posts

MongoDB : trois CVE dans les outils et drivers, dont une injection SQL

L'avis CERTFR-2026-AVI-1430 corrige trois CVE dans Database Tools, le Java Driver et Laravel MongoDB — dont une injection SQL. Mises à jour en 100.20.0, 5.14.0 et 5.12.0.

Publié le 3 min de lecture
cvemongodbsql-injectionalerte

Le CERT-FR a publié le 30 octobre l'avis CERTFR-2026-AVI-1430 sur de multiples vulnérabilités dans les produits MongoDB. Trois CVE sont concernées, avec des impacts allant de l'atteinte à l'intégrité des données au contournement de la politique de sécurité, en passant par une injection SQL. Les failles ne touchent pas le serveur MongoDB lui-même mais ses outils et bibliothèques clientes.

Produits et versions concernés

Les correctifs portent sur trois composants distincts de l'écosystème MongoDB :

Les trois CVE

L'avis du CERT-FR n'attribue pas publiquement un impact précis à chaque identifiant : il décrit collectivement une atteinte à l'intégrité, un contournement de la politique de sécurité et une injection SQL. Reportez-vous aux bulletins éditeur liés ci-dessus pour le détail composant par composant avant de prioriser.

Le point qui mérite l'attention : une injection SQL dans l'écosystème d'une base NoSQL. Elle ne concerne pas le moteur documentaire, mais la couche outil/driver — typiquement un chemin où une entrée non neutralisée est concaténée dans une requête côté client ou côté outil d'administration. C'est un rappel que « NoSQL » ne met pas à l'abri des classes d'injection classiques dès lors qu'une bibliothèque construit des requêtes à partir de chaînes.

État de l'exploitation

Aucune exploitation en conditions réelles n'est mentionnée dans l'avis à ce stade, et les failles ne figurent pas au catalogue des vulnérabilités activement exploitées. L'avis reste une mise à jour de sécurité à planifier, pas une alerte d'urgence.

Que faire

  1. Mettez à jour les composants concernés : Database Tools en 100.20.0, Java Driver en 5.14.0, Laravel MongoDB en 5.12.0.
  2. Inventoriez vos dépendances. Ces bibliothèques arrivent souvent de façon transitive (pipelines de sauvegarde, applications Laravel, services JVM) — un scan de dépendances repère les versions vulnérables plus sûrement qu'un inventaire manuel.
  3. Auditez les chemins de requête côté application là où une entrée utilisateur alimente la construction d'une requête via le driver, en particulier pour le volet injection SQL.
  4. Surveillez les bulletins éditeur liés par le CERT-FR pour la correspondance exacte CVE / composant.

Contexte

Ce n'est pas le serveur de base de données qui est en cause ici, mais sa périphérie — outils en ligne de commande, driver JVM, intégration framework. C'est là que se logent désormais une bonne partie des vulnérabilités « base de données » : non dans le moteur durci, mais dans les couches d'accès qui l'entourent et que les équipes suivent moins étroitement. Traitez les drivers et outils d'une base comme du code applicatif à patcher, pas comme des dépendances d'infrastructure qu'on fige et qu'on oublie.

Articles liés