Analyste renseignement sur les menaces
31 544 lignes du cloud de l’État en fuite — les 4 questions que j’ai posées à nos 12 clients le lendemain matin
TL;DR
- Le 22 août 2026, une publication repérée sur un forum cybercriminel expose des données issues de cloud.numerique.gouv.fr, plateforme rattachée à la DINUM. Volume revendiqué : 31 544 lignes réparties sur au moins 12 fichiers CSV.
- Le fichier le plus grave n’est pas celui qu’on croit. dinum_transaction.csv documente commandes, abonnements et marchés publics : bénéficiaires, fournisseurs, montants, dates, statuts.
- Un second fichier expose des contributeurs de projets logiciels publics : identifiants, adresses e-mail, noms, localisations, organisations de rattachement. C’est une base de ciblage prête à l’emploi.
- Le contexte technique compte : début août 2026, l’éditeur Metabase a révélé une faille zero-day critique d’injection SQL activement exploitée pour compromettre des instances et accéder aux données auxquelles elles étaient connectées.
- La leçon n’est pas « l’État s’est fait pirater ». Elle est : un outil de visualisation connecté à une base de production est un accès à cette base, et il n’est presque jamais inventorié comme tel.
Samedi matin, une publication apparaît sur un forum fréquenté par des cybercriminels. Elle est signée d’un pseudonyme, 0xSec, et elle revendique un ensemble de données provenant de cloud.numerique.gouv.fr, une plateforme rattachée à la Direction interministérielle du numérique.
Le volume est modeste au regard des fuites qui font les gros titres : 31 544 lignes, réparties sur au moins douze fichiers CSV. Aucun mot de passe, aucune donnée bancaire de particulier, aucun numéro de sécurité sociale. Sur l’échelle des catastrophes médiatiques, cette fuite ne pèse rien.
C’est précisément pour cette raison qu’elle mérite d’être regardée de près. Ce qui a fuité n’est pas spectaculaire — c’est exploitable, et la différence entre les deux est le sujet de cet article.
Ce qui a réellement fuité, fichier par fichier
Trois fichiers structurent l’essentiel de la valeur de cette fuite, et l’ordre dans lequel on les lit change complètement l’évaluation du risque.
dinum_administration.csv référence des organismes publics avec leurs numéros SIREN et SIRET, leurs formes juridiques, leurs implantations géographiques et leurs rattachements administratifs. Pris isolément, ce fichier est presque de la donnée ouverte : l’essentiel de ces informations est publiquement consultable. Sa valeur pour un attaquant n’est pas dans son contenu mais dans sa structure — il donne le périmètre exact des entités présentes sur la plateforme.
Un journal de commits expose les contributeurs à des projets logiciels gouvernementaux : identifiants de développeurs, adresses e-mail, noms, localisations, organisations d’affiliation. C’est une base de ciblage prête à l’emploi pour du hameçonnage ciblé, et elle est d’autant plus efficace que les personnes concernées ont une raison légitime de recevoir des messages techniques d’inconnus.
dinum_transaction.csv est le plus grave, et de loin. Il contient les détails de transactions, commandes, abonnements et marchés publics : bénéficiaires, fournisseurs, montants, dates et statuts. Autrement dit, la cartographie de qui achète quoi, à qui, pour combien et à quel moment.
Notre avis d’expert (1/3)
La question que tout le monde pose est « est-ce grave ». C’est la mauvaise question, parce qu’elle appelle une réponse en volume et que le volume est ici trompeur. La bonne question est « qu’est-ce que ça permet de faire ensuite ». Un fichier de transactions avec bénéficiaires, fournisseurs et montants est le carburant exact de la fraude au virement : il donne le nom du fournisseur légitime, le montant plausible, le rythme de facturation et l’interlocuteur. Une demande de changement de coordonnées bancaires envoyée avec ces éléments franchit les contrôles humains, parce qu’elle est cohérente avec ce que la comptabilité s’attend à voir.
Le vecteur probable, et pourquoi il vous concerne directement
Le contexte technique publié autour de cette fuite renvoie à un élément précis. Début août 2026, l’éditeur Metabase a révélé qu’une faille zero-day critique de type injection SQL était activement exploitée pour compromettre des instances et accéder aux données auxquelles elles étaient connectées.
Metabase est un outil de visualisation et d’exploration de données. Sa fonction même est de se connecter à des bases de production pour permettre à des utilisateurs non techniques de construire des tableaux de bord. C’est un excellent outil, largement déployé, y compris dans des PME françaises de toutes tailles.
Et c’est là que se situe l’angle mort, qui n’a rien de spécifique à l’État. Un outil de visualisation connecté à une base de production est un accès à cette base. Il détient des identifiants de lecture, souvent larges, parfois posés une fois en 2022 par une personne qui a quitté l’entreprise depuis. Dans les inventaires que nous auditons, il apparaît dans la catégorie « outils métier », à côté du logiciel de notes de frais, et jamais dans la catégorie « composants ayant accès aux données clients ».
Sur les 34 audits de périmètre que nous avons menés depuis janvier, 29 comportaient au moins un outil de visualisation ou de reporting exposé sur Internet, et dans 21 cas les identifiants de connexion à la base utilisaient un compte disposant de droits de lecture sur l’intégralité du schéma.
Ce que l’inventaire déclare vs ce que l’outil peut réellement lire — 34 audits de périmètre
Notre avis d’expert (2/3)
Le réflexe défensif après ce genre d’actualité est de vérifier la version de l’outil cité et de passer à autre chose. C’est nécessaire et très insuffisant, parce que le nom de l’outil changera au prochain incident. Le problème structurel est que la couche « outils qui lisent vos données » n’a pas de propriétaire dans la plupart des organisations. Elle n’appartient pas tout à fait à la DSI, qui ne l’a pas déployée, ni au métier, qui ne sait pas ce qu’elle expose. Tant que personne n’en est responsable nommément, elle ne sera ni inventoriée, ni corrigée, ni surveillée.
Savez-vous quels outils lisent aujourd’hui votre base de production ?
Nous cartographions les accès applicatifs réels à vos données, réduisons les droits au strict nécessaire et posons la surveillance. Audit de périmètre en 5 jours.
Discutons-enLes 4 questions que j’ai envoyées à nos 12 clients sous contrat
Dimanche matin, un courriel de quatre questions. Aucune n’exige un outil, un budget ou une réunion. Les quatre réponses tiennent sur une page et se réunissent en deux heures.
1. Quels outils tiers sont connectés à vos bases de production, et depuis quand ?
Pas « quels outils utilisez-vous », qui produit une liste d’applications métier. La question porte sur la connexion technique à la base : visualisation, reporting, sauvegarde tierce, connecteur de synchronisation, outil d’analyse produit, plateforme d’automatisation.
La bonne façon de l’obtenir n’est pas de demander au métier. C’est de lire les connexions actives sur le serveur de base de données et de remonter chaque adresse source. Sur les douze retours, trois listes déclaratives étaient incomplètes, et dans un cas un connecteur mis en place pour une expérimentation abandonnée en 2024 lisait toujours la base tous les quarts d’heure.
2. Ces outils sont-ils accessibles depuis Internet ?
Question binaire, réponse vérifiable en cinq minutes depuis un réseau extérieur. Un outil de reporting interne n’a en général aucune raison d’avoir une interface publique : il devrait exiger un accès au réseau de l’entreprise.
Quand la réponse est « oui, parce que les commerciaux consultent les tableaux de bord en déplacement », le problème n’est pas la mobilité mais la réponse apportée à la mobilité. C’est le cas d’usage type d’un accès réseau conditionnel, sujet que nous traitons dans notre méthode d’architecture zero trust pour PME.
3. Avec quels droits se connectent-ils ?
La réponse par défaut, dans 21 de nos 34 audits, est « un compte qui lit tout ». Presque toujours pour une raison compréhensible : au moment de l’installation, restreindre les droits demandait de savoir quelles tables seraient utilisées, ce que personne ne savait encore.
Le correctif est peu coûteux et rarement fait : un compte dédié par outil, en lecture seule, restreint aux vues et tables effectivement utilisées. Comptez une demi-journée par outil, en s’appuyant sur les requêtes réellement exécutées au cours des trente derniers jours plutôt que sur une discussion théorique.
4. Sauriez-vous dire ce qui a été lu, et quand ?
C’est la question qui décide de tout dans les quarante-huit heures qui suivent un incident. Si un outil connecté est compromis, la seule chose qui compte est de déterminer le périmètre exact de ce qui a été consulté.
Sans journalisation des requêtes côté base, la réponse honnête est « tout ce que le compte pouvait lire », et c’est cette réponse qui déclenche une notification de violation large plutôt que ciblée. Sur nos douze clients, quatre pouvaient répondre précisément. Les huit autres ont activé la journalisation dans la semaine ; c’est une modification de configuration, pas un projet.
Chemin d’attaque type — d’une faille dans un outil de visualisation à la fraude au virement
Pourquoi ce n’est pas un problème d’administration publique
Il serait confortable de ranger cette actualité dans la catégorie « failles du secteur public ». Ce serait une erreur d’analyse, pour une raison simple : rien dans le mécanisme décrit n’est spécifique à l’État.
Une plateforme mutualisée, un outil de visualisation connecté à des données réelles, des identifiants larges posés au démarrage, une vulnérabilité dans un composant tiers, et un export structuré qui sort. Ce scénario décrit avec autant de précision une PME de cinquante personnes qu’une direction interministérielle.
La différence, et elle joue contre vous, est que l’État dispose d’équipes capables de détecter et de qualifier l’incident. Sur les périmètres PME que nous auditons, une compromission d’outil de reporting a une probabilité élevée de n’être jamais détectée — non par négligence, mais parce que la journalisation qui permettrait de la voir n’est pas activée.
Le volet développement de ce sujet — dépendances, chaîne d’approvisionnement logicielle, hygiène des postes d’ingénierie — est traité en détail par nos confrères de D-Open. Et si vos données alimentent désormais des agents d’intelligence artificielle disposant d’accès applicatifs, les équipes de Plug-Tech documentent régulièrement ce périmètre, qui multiplie précisément le type d’accès dont il est question ici.
Notre avis d’expert (3/3)
Une prévision que nous assumons : dans les dix-huit mois, les outils de visualisation et d’automatisation connectés aux bases de production deviendront le premier vecteur documenté de fuite de données en PME française, devant le hameçonnage et devant le rançongiciel. La raison est structurelle et non conjoncturelle. Ces outils se multiplient parce qu’ils créent de la valeur, ils sont installés par des équipes métier hors du circuit d’homologation, et ils détiennent par construction des droits de lecture larges. C’est la définition d’une surface d’attaque qui croît plus vite que sa gouvernance. La contre-mesure n’est ni coûteuse ni technique : un inventaire nommé, un propriétaire désigné, et des droits réduits par outil.
Pour aller plus loin
Si votre organisation entre dans le champ de la directive NIS2, la cartographie des accès applicatifs aux données est une exigence explicite et non une bonne pratique optionnelle : notre audit de périmètre NIS2 couvre ce point. Sur la suite immédiate d’un incident avéré, notre méthode de plan de réponse à incident en 7 étapes détaille les premières quarante-huit heures.
Questions fréquentes
Que contient exactement la fuite du 22 août 2026 ?
Une publication signée 0xSec, repérée le 22 août 2026, expose des données issues de cloud.numerique.gouv.fr, plateforme rattachée à la DINUM : 31 544 lignes réparties sur au moins douze fichiers CSV. Les trois plus significatifs sont dinum_administration.csv (organismes publics, SIREN et SIRET, formes juridiques, implantations), un journal de commits exposant des contributeurs de projets logiciels publics (identifiants, e-mails, noms, localisations, organisations) et dinum_transaction.csv, qui documente commandes, abonnements et marchés publics avec bénéficiaires, fournisseurs, montants, dates et statuts.
Pourquoi un fichier de transactions est-il plus dangereux qu’un fichier de mots de passe ?
Un mot de passe se change, et son vol déclenche une réaction immédiate et bien rodée. Un fichier de transactions ne se change pas. Il donne le nom du fournisseur légitime, le montant plausible, le rythme de facturation et l’interlocuteur — exactement les quatre éléments qui rendent une demande de changement de coordonnées bancaires crédible auprès d’une comptabilité. C’est le carburant de la fraude au virement, et sa durée de validité se compte en années, pas en heures.
Mon entreprise utilise un outil de reporting connecté à sa base. Que faire en priorité ?
Trois actions, dans cet ordre, en une demi-journée. Vérifiez depuis un réseau extérieur si l’interface de l’outil est accessible sans passer par votre réseau d’entreprise ; si oui, restreignez l’accès. Vérifiez la version installée et sa date de dernière mise à jour. Puis regardez avec quel compte l’outil se connecte à la base : si ce compte peut lire l’intégralité du schéma, créez un compte dédié en lecture seule restreint aux tables réellement utilisées au cours des trente derniers jours. Cette dernière action seule transforme une compromission totale en incident circonscrit.
Faut-il notifier la CNIL si un outil connecté est compromis ?
Dès qu’une violation de données à caractère personnel est susceptible d’engendrer un risque pour les personnes concernées, la notification à l’autorité de contrôle intervient dans les meilleurs délais et si possible sous 72 heures. Le point décisif n’est pas juridique mais technique : sans journalisation des requêtes côté base, vous ne pouvez pas délimiter ce qui a été lu, et la notification porte alors sur l’ensemble de ce que le compte compromis pouvait atteindre. C’est la raison pratique pour laquelle activer la journalisation avant l’incident change l’ampleur de la déclaration — et son coût de réputation.
Une demi-journée par outil aujourd’hui, ou une notification large plus tard.
Nous cartographions les accès applicatifs réels à vos données, réduisons les droits, activons la journalisation et vous laissons un inventaire avec un propriétaire nommé. Audit de périmètre en 5 jours.
Discutons-enou appelez-nous au +33 6 32 64 24 80