Le code d’attaque est sorti le 26
l’incident a eu lieu le 27.
L’affaire a circulé comme un piratage historique. Elle mêlait un incident confirmé et des revendications jamais prouvées. Derrière le vacarme, une vulnérabilité corrigée quelques jours plus tôt a laissé des dizaines de milliers de serveurs ouverts pendant la semaine la plus creuse de l’année.
Ce qui est établi, ce qui ne l’est pas
La distinction s’est confirmée avec le temps, et elle mérite d’être posée avant tout le reste.
- Fermeture d’urgence des serveurs du jeu de tir en ligne le 27 décembre 2025 : confirmé par l’éditeur.
- Injection massive de monnaie virtuelle sur les comptes de joueurs : confirmé, avec annulation des transactions postérieures à une heure donnée.
- Vol de neuf cents gigaoctets de données internes : revendiqué, jamais prouvé, qualifié de largement exagéré par des sources spécialisées.
- Vol de code source remontant aux années 1990 : revendiqué par un groupe, jamais confirmé.
- Compromission de données d’utilisateurs : revendiquée par un autre groupe, jamais confirmée.
Un groupe criminel qui revendique un vol massif a tout intérêt à gonfler ses chiffres : la revendication sert à faire pression sur la victime et à se constituer une réputation auprès de ses pairs. L’absence de preuve n’établit pas l’absence de vol, mais elle interdit de présenter une revendication comme un fait. Beaucoup de reprises ont franchi cette limite, et le chiffre de neuf cents gigaoctets a circulé partout comme une donnée acquise.
Une entreprise attaquée communique de son côté avec ses propres contraintes juridiques et commerciales. Entre une revendication intéressée et un communiqué prudent, le lecteur n’a souvent aucune source neutre. Le dire vaut mieux que de trancher.
La cause, et ce qu’on n’en sait pas
Une vulnérabilité rendue publique huit jours avant l’incident a très vite été désignée comme la cause probable. Aucune preuve formelle ne l’établit.
L’éditeur ne s’est jamais prononcé sur le vecteur d’intrusion. Aucune analyse technique publique ne relie l’incident à cette faille précise. L’hypothèse repose entièrement sur la concordance des dates, ce qui la rend plausible et intéressante, mais ne la démontre pas.
Ce type de raccourci est fréquent après un incident médiatisé. Une vulnérabilité spectaculaire vient d’être annoncée, une grande entreprise tombe dans la foulée, et le lien s’impose de lui-même dans les esprits. Il arrive qu’il soit exact. Il arrive aussi que l’intrusion remonte à plusieurs semaines et emprunte un chemin banal, un identifiant volé ou un accès distant mal protégé, révélé bien plus tard par le rapport d’investigation.
Cette prudence ne réduit pas l’intérêt du dossier, elle le déplace. La faille en question est réelle, documentée, et son calendrier de publication enseigne quelque chose d’utile indépendamment de ce qui est arrivé à cet éditeur. C’est cette partie-là qui vaut le détour, et elle se transpose à n’importe quelle infrastructure, y compris celle d’une petite entreprise.
Une ligne de code manquante
Référencée CVE-2025-14847, surnommée MongoBleed par analogie avec une faille célèbre de 2014, elle affecte les serveurs de base de données MongoDB et porte un score de gravité de 8,7 sur 10.
Le mécanisme est d’une simplicité déconcertante. Pour économiser de la bande passante, le protocole réseau de MongoDB permet de compresser les messages. Le serveur lit alors la taille annoncée dans l’en-tête du message, réserve un espace mémoire correspondant, puis décompresse. Un attaquant qui déclare une taille supérieure à la réalité obtient un espace trop grand, et le serveur lui renvoie ce qui traînait déjà dans cette portion de mémoire.
Ce qui traîne dans la mémoire d’un serveur de base de données, ce sont des mots de passe, des clés d’interface de programmation, des jetons de session, des fragments de requêtes récentes. En répétant l’opération, un attaquant reconstitue progressivement de larges portions de cette mémoire. L’attaque est distante, ne demande aucune authentification et aucune interaction : il suffit d’atteindre le port réseau du serveur.
Le surnom n’est pas anodin. En 2014, une faille du même type touchait la bibliothèque de chiffrement qui sécurise une part considérable du web : même mécanisme de taille annoncée non vérifiée, même fuite de mémoire, mêmes secrets exposés. Douze ans plus tard, la leçon n’avait manifestement pas été généralisée. Ce genre d’erreur ne relève pas de la négligence d’un développeur isolé mais d’un angle mort de conception : faire confiance à une valeur fournie par un interlocuteur non authentifié reste l’une des sources d’erreur les plus récurrentes de l’informatique en réseau.
Le correctif tient littéralement en une ligne. Il consiste à calculer la taille réelle du message décompressé au lieu de faire confiance à la valeur annoncée par l’interlocuteur. Cette ligne manquait depuis 2017, et affectait donc la quasi-totalité des versions publiées pendant plus de huit ans. Une inattention de cette nature dans un composant utilisé par des centaines de milliers d’organisations rappelle que la sophistication d’une attaque tient rarement à celle de la faille exploitée, à l’inverse des scénarios d’ingénierie sociale élaborés que nous décrivions à propos de la technique ClickFix et de ses faux écrans Windows.
Neuf jours décisifs
Tout se joue entre le 19 et le 29 décembre 2025, en pleine période de congés, quand les équipes techniques sont réduites au minimum.
- Mai 2017 : la vulnérabilité est introduite dans le code, sans être détectée. Elle affectera toutes les versions publiées jusqu’en décembre 2025.
- 19 décembre 2025 : l’éditeur de la base de données publie un avis de sécurité et les versions corrigées. Les instances gérées dans son offre infogérée sont mises à jour automatiquement ; les serveurs auto-hébergés demandent une intervention manuelle.
- 26 décembre 2025 : un code d’exploitation fonctionnel est publié sur une plateforme de partage de code, à la portée de n’importe qui.
- 27 décembre 2025 : l’éditeur de jeux ferme en urgence les serveurs de son jeu de tir en ligne après une injection massive de monnaie virtuelle.
- 29 décembre 2025 : l’agence américaine de cybersécurité inscrit la faille à son catalogue des vulnérabilités activement exploitées, ce qui oblige les agences fédérales à corriger sans délai. L’autorité française confirme également une exploitation dans la nature.
La séquence se lit d’elle-même. Huit jours entre le correctif et l’incident. Mais surtout un seul jour entre la publication du code d’attaque et cet incident. Ce n’est plus une fenêtre, c’est une porte laissée ouverte pendant que tout le monde était à table.
La distinction entre offre infogérée et serveur auto-hébergé a créé deux populations très inégales. Les premiers étaient protégés sans rien faire. Les seconds ne l’étaient qu’à condition qu’un administrateur lise l’avis pendant ses congés et intervienne.
Combien de serveurs, vraiment
Les estimations publiées à la fin décembre 2025 divergent fortement, et cet écart mérite d’être exposé plutôt que moyenné.
Une plateforme de recensement des équipements exposés dénombrait environ 87 000 instances vulnérables directement accessibles depuis l’internet public. Une autre équipe de recherche en comptait près de 146 000. Certaines analyses ont avancé un chiffre supérieur à 200 000. Une étude portant sur les environnements infonuagiques concluait que 42 % d’entre eux hébergeaient au moins une instance à risque.
Ces écarts ne traduisent pas une incompétence des uns ou des autres. Ils reflètent des méthodes différentes : périmètre de balayage, définition de la vulnérabilité retenue, moment de la mesure sur une population qui se corrigeait de jour en jour. Un chiffre isolé, cité sans sa source ni sa date, ne veut rien dire dans ce domaine.
L’ordre de grandeur, lui, est constant : plusieurs dizaines de milliers de bases de données accessibles depuis internet. C’est le fait le plus dérangeant du dossier, indépendamment de la faille elle-même. Une base de données n’a aucune raison légitime d’être joignable depuis n’importe où dans le monde. Sa place est derrière l’application qui l’interroge, sur un réseau fermé. Cette exposition, souvent héritée d’une installation par défaut jamais reconfigurée, transforme chaque vulnérabilité nouvelle en incident potentiel immédiat.
La fenêtre qui suit le correctif
Voilà l’enseignement transposable, et il va à l’encontre de l’intuition la plus répandue.
Le moment le plus dangereux pour un système n’est pas celui où la faille est inconnue. C’est la période qui suit immédiatement la publication du correctif. Un correctif rend publique l’existence du problème, décrit le composant concerné, et fournit aux attaquants la carte exacte de ce qu’ils doivent chercher. Comparer la version corrigée à la précédente suffit souvent à reconstituer l’attaque.
Dans le cas présent, sept jours ont séparé le correctif du code d’exploitation public, et un seul jour ce code de l’incident. Pendant que des dizaines de milliers de serveurs attendaient une intervention humaine, l’outil pour les attaquer circulait librement.
La conséquence pratique est inconfortable. Repousser une mise à jour de sécurité pour ne rien casser pendant une période sensible revient à laisser ouverte la porte dont l’adresse vient d’être publiée. Les périodes de congés, précisément choisies pour ne pas toucher aux systèmes, sont aussi celles que les attaquants privilégient, pour la même raison exactement.
Ce que cela change pour votre site
Vous n’administrez probablement pas de serveur MongoDB. Le mécanisme, lui, se reproduit à l’identique sur un site d’entreprise ordinaire.
- Une extension corrigée aujourd’hui est une extension dont la faille est publique aujourd’hui. Les sites mis à jour dans la semaine passent au travers ; ceux qui attendent le trimestre figurent sur une liste que n’importe qui peut constituer automatiquement.
- Supprimer les extensions inutilisées plutôt que les désactiver : un composant désactivé mais présent sur le serveur reste attaquable.
- Vérifier qu’aucune base de données n’est joignable depuis internet, et que les interfaces d’administration ne le sont pas davantage.
- Distinguer ce qui est mis à jour automatiquement par l’hébergeur de ce qui relève de vous. C’est cette frontière qui a séparé les protégés des exposés en décembre 2025.
- Disposer d’une sauvegarde permettant de revenir à un état antérieur daté, comme l’a fait l’éditeur en annulant les transactions postérieures à une heure précise.
Un ordre de grandeur aide à situer l’enjeu pour une petite structure. Un site sous gestion de contenu classique embarque couramment entre quinze et quarante extensions, développées par autant d’équipes différentes, avec des rythmes de correction très inégaux. Chacune est une porte potentielle, et chacune publie ses correctifs à son propre calendrier. Personne ne peut suivre cela manuellement : la question n’est donc pas de savoir surveiller, mais d’avoir décidé qui s’en charge et à quelle fréquence.
Le dernier point est celui qui a réellement limité les dégâts dans cette affaire. La capacité à restaurer proprement un état connu vaut, dans un incident, davantage que n’importe quel outil de détection. Elle suppose que les sauvegardes existent, qu’elles soient datées, et qu’une restauration ait déjà été testée au moins une fois. Le même réflexe a permis à d’autres entreprises de refuser une extorsion, comme la plateforme qui a refusé de céder à une demande de trois millions de dollars.
C’est le sujet de notre page sur la sauvegarde et la sécurité, complétée par la supervision et les mises à jour, et par notre offre de dépannage serveur lorsque l’incident est déjà survenu.
Ce qu’on nous demande le plus souvent.
Les 900 gigaoctets ont-ils été volés ?
Rien ne le prouve. Le chiffre est une revendication de groupe criminel, jamais étayée et qualifiée de largement exagérée par des sources spécialisées. L’éditeur n’a confirmé qu’un incident sur son jeu de tir en ligne, avec injection de monnaie virtuelle.
La faille MongoBleed est-elle à l’origine de l’incident ?
Aucune preuve ne l’établit. L’éditeur ne s’est jamais prononcé sur le vecteur d’intrusion. L’hypothèse repose sur la proximité des dates, ce qui la rend plausible sans la démontrer.
En quoi consiste cette vulnérabilité ?
Le serveur se fie à la taille annoncée d’un message compressé, réserve un espace mémoire trop grand et renvoie ce qui s’y trouvait : mots de passe, clés d’interface, jetons de session. L’attaque est distante et ne demande aucune authentification.
Combien de serveurs étaient exposés ?
Les estimations vont d’environ 87 000 à plus de 200 000 selon la méthode et le moment de la mesure. L’ordre de grandeur, constant, est de plusieurs dizaines de milliers de bases de données accessibles depuis internet, ce qui n’aurait jamais dû être le cas.
Pourquoi la période après un correctif est-elle risquée ?
Parce que le correctif rend la faille publique et indique où chercher. Ici, sept jours ont séparé le correctif du code d’exploitation diffusé publiquement, et un seul jour ce code de l’incident.
Que faire concrètement sur son propre site ?
Appliquer les mises à jour de sécurité dans les jours qui suivent, supprimer les extensions inutilisées plutôt que les désactiver, vérifier qu’aucune base ni interface d’administration n’est accessible depuis internet, et tester une restauration de sauvegarde.
- Avis de sécurité publié par MongoDB le 19 décembre 2025 relatif à la vulnérabilité CVE-2025-14847 et versions corrigées associées.
- Base de données nationale des vulnérabilités et analyses techniques publiées par plusieurs éditeurs de sécurité sur le mécanisme de la faille et son correctif.
- Catalogue des vulnérabilités activement exploitées de l’agence américaine de cybersécurité, inscription du 29 décembre 2025, et alerte de l’autorité française.
- Relevés d’exposition publiés fin décembre 2025 par plusieurs plateformes de recensement des équipements accessibles sur internet.
- Communications de l’éditeur de jeux relatives à la fermeture de ses serveurs le 27 décembre 2025 et à l’annulation des transactions.
- Analyses de la presse spécialisée mettant en doute l’ampleur des revendications de vol de données.
WY-Créations conçoit des sites internet et construit des stratégies de visibilité pour les artisans, les TPE, les PME et les professions libérales depuis 2018. Les revendications des groupes criminels sont signalées comme telles et distinguées des faits confirmés par les entreprises concernées. Pour aller plus loin : la sauvegarde et la sécurité ou à propos de l’agence.
Qui applique vos mises à jour de sécurité, et sous quel délai ?
La question n’est pas de savoir si votre site sera visé, mais combien de jours s’écoulent entre la publication d’un correctif et son application.