Un administrateur de la CISA a divulgué des clés AWS GovCloud sur GitHub

• Un dépôt public Private-CISA, exploité par un sous-traitant de la CISA, a exposé des comptes AWS GovCloud à privilèges élevés ainsi que des identifiants de systèmes internes
• Le compte GitHub montrait des traces de désactivation des réglages par défaut empêchant la publication de secrets, et contenait des mots de passe en clair, des tokens et des logs
• Le fichier exposé importantAWStokens contenait les identifiants administrateur de trois serveurs AWS GovCloud, et un CSV renfermait des informations de connexion à des systèmes internes
• Seralys estime que les clés exposées permettaient une authentification avec des privilèges élevés, et que l’accès à l’artifactory interne augmentait le risque d’implantation de backdoors dans des paquets et de déplacement latéral
• Le compte a été mis hors ligne juste après la notification à la CISA, mais les clés AWS sont restées valides encore 48 heures ; la CISA affirme n’avoir relevé aucun signe de compromission

---

Des identifiants internes de la CISA exposés dans un dépôt GitHub public

• Un dépôt GitHub public géré par un sous-traitant de la CISA a exposé plusieurs comptes AWS GovCloud à privilèges élevés ainsi que des identifiants de systèmes internes de la CISA
• Le dépôt s’appelait Private-CISA et contenait aussi des fichiers liés à la manière dont la CISA construit, teste et déploie ses logiciels en interne
• Le dépôt contenait en grande quantité des clés cloud, des tokens, des mots de passe en clair, des logs et d’autres actifs sensibles de la CISA
• Guillaume Valadon, de GitGuardian, a découvert ce dépôt en scannant en continu des dépôts de code publics pour détecter des secrets exposés et envoyer des alertes automatiques aux propriétaires des comptes
• Valadon indique que le propriétaire du dépôt n’a pas répondu et, compte tenu de la sensibilité extrême des informations exposées, a contacté KrebsOnSecurity

Désactivation de la détection de secrets GitHub et principaux fichiers exposés

• Valadon considère cette exposition d’identifiants de la CISA comme un cas typique de mauvaise hygiène de sécurité
• Les logs de commit du compte GitHub concerné montraient des traces de désactivation par un administrateur de la CISA des réglages par défaut de GitHub censés empêcher la publication de clés SSH ou d’autres secrets dans des dépôts publics
• Valadon a déclaré qu’il y avait « des mots de passe stockés en clair dans des CSV, des sauvegardes versées dans Git, et des commandes explicites désactivant la fonction de détection de secrets de GitHub »
• Le fichier exposé importantAWStokens contenait les identifiants administrateur de trois serveurs Amazon AWS GovCloud
• Un autre fichier, AWS-Workspace-Firefox-Passwords.csv, contenait des noms d’utilisateur et mots de passe en clair pour des dizaines de systèmes internes de la CISA
• Selon Philippe Caturegli, ces systèmes incluaient aussi LZ-DSO, qui semble être l’abréviation de « Landing Zone DevSecOps », l’environnement de développement de code de sécurité de l’agence

Privilèges élevés et risques liés à l’accès aux systèmes internes

• Philippe Caturegli, fondateur du cabinet de conseil en sécurité Seralys, a indiqué avoir seulement vérifié si les clés AWS exposées étaient encore valides et à quels systèmes internes les comptes exposés pouvaient accéder
• Caturegli a confirmé que les identifiants exposés permettaient une authentification avec un niveau de privilèges élevé sur trois comptes AWS GovCloud
• Les archives contenaient aussi des identifiants en clair pour l’artifactory interne de la CISA
• Cet artifactory est le dépôt de paquets de code utilisé par la CISA pour construire ses logiciels, et il pourrait constituer une cible attractive pour un attaquant cherchant à établir une présence persistante dans les systèmes de la CISA
• Caturegli estime que cet emplacement est particulièrement propice au déplacement latéral, et qu’en implantant une backdoor dans des paquets logiciels, une backdoor pourrait ensuite être déployée dans chaque nouveau logiciel construit par la suite

Mode d’utilisation du dépôt et entité gestionnaire

• Caturegli estime que ce compte GitHub ressemblait moins à un dépôt de projet bien structuré qu’à un bloc-notes de travail ou un moyen de synchronisation utilisé par un travailleur individuel
• Des adresses e-mail liées à la CISA et des adresses e-mail personnelles y étaient toutes deux utilisées, ce qui laisse penser que le dépôt a pu servir dans des environnements configurés différemment
• Caturegli a précisé qu’avec les seules métadonnées Git disponibles, il était impossible d’établir quels endpoints ou appareils avaient été utilisés
• L’examen du compte GitHub et des mots de passe exposés a montré que le dépôt Private-CISA était géré par un employé du prestataire gouvernemental Nightwing, basé à Dulles, en Virginie
• Nightwing a refusé tout commentaire et a renvoyé les questions vers la CISA

Réponse de la CISA et durée d’exposition

• Un porte-parole de la CISA a déclaré que l’agence avait connaissance de l’exposition signalée et poursuivait son enquête sur la situation
• La CISA a affirmé qu’elle n’avait actuellement relevé aucun signe de compromission de données sensibles dans cette affaire
• La CISA a indiqué qu’elle exigeait de ses équipes un haut niveau d’intégrité et de conscience opérationnelle, et qu’elle mettait en place des protections supplémentaires pour éviter qu’un tel incident ne se reproduise
• La CISA n’a pas répondu aux questions concernant la durée potentielle de l’exposition des données
• Selon Caturegli, le dépôt Private-CISA a été créé le 13 novembre 2025, et le compte GitHub du sous-traitant concerné avait été créé en septembre 2018
• Juste après que KrebsOnSecurity et Seralys ont signalé l’exposition à la CISA, le compte GitHub contenant le dépôt Private-CISA a été mis hors ligne
• Caturegli a déclaré que les clés AWS exposées sont pourtant restées valides encore 48 heures, sans explication claire

Mots de passe faciles et risque d’extension de la compromission

• Le dépôt Private-CISA fermé contenait aussi des traces d’utilisation de mots de passe faciles à deviner pour plusieurs ressources internes
• De nombreux identifiants utilisaient des mots de passe formés du nom de chaque plateforme suivi de l’année en cours
• Caturegli estime que ce type de pratique peut constituer une menace de sécurité grave dans n’importe quelle organisation, même sans exposition externe
• Une fois un premier accès obtenu au système visé, les attaquants élargissent souvent leur portée d’accès au sein du réseau interne en exploitant des identifiants clés exposés
• Caturegli avance que, puisque ce sous-traitant de la CISA effectuait régulièrement des commits dans ce dépôt depuis novembre 2025, il a pu utiliser GitHub pour synchroniser des fichiers entre son ordinateur portable professionnel et son ordinateur personnel
• Caturegli estime qu’il s’agit d’une fuite embarrassante pour n’importe quelle entreprise, mais que le problème est plus grave ici parce qu’il s’agit de la CISA

Contexte organisationnel

• La CISA fonctionne actuellement avec seulement une partie de son budget normal et de ses effectifs habituels
• La CISA a perdu près d’un tiers de ses effectifs depuis le début du second mandat de Trump
• Cette baisse des effectifs est décrite comme la conséquence de départs anticipés à la retraite, de buyouts et de démissions forcés dans plusieurs divisions de l’agence
• Article connexe : CISA has lost nearly a third of its workforce

[GN⁺]

Réactions sur Hacker News

• Valadon explique avoir pris contact parce que le propriétaire ne répondait pas et que les informations exposées étaient extrêmement sensibles ; le fait qu’un sous-traitant de la CISA ait divulgué des identifiants est déjà aberrant, mais le fait de ne pas répondre après notification est encore plus grave
  En plus, AWS-Workspace-Firefox-Passwords.csv contenait apparemment des noms d’utilisateur et mots de passe en clair pour des dizaines de systèmes internes de la CISA
  Je comprends et je regrette que la CISA soit en train d’être réduite, mais un passwords.csv rempli de mots de passe faibles relève d’une incompétence sans excuse, et un gestionnaire de mots de passe ne demande pas un gros budget

  • L’expression qu’on cherche, c’est négligence grave
  • Ce n’est pas pour défendre cette personne, mais tout indique qu’elle utilisait GitHub comme outil de synchronisation de fichiers
    Firefox-passwords.html et firefox-bookmarks.html étaient des fichiers qu’on exportait puis réimportait avant de passer sur un nouvel ordinateur, une vieille méthode d’avant la synchronisation Firefox
    L’article le mentionne aussi, mais c’est suffisamment visible pour être signalé
  • D’un côté, la CISA est en train d’être amputée, et de l’autre les discours sur la cybersécurité, l’intérêt national et les infrastructures critiques ne cessent de prendre de l’ampleur
  • La plupart des connaissances que j’avais à la CISA ont été écartées pendant la campagne DOGE de janvier à mars 2025
    Sans préavis, en mode « nous, la vingtaine, ne savons pas ce que tu fais, donc tu es viré »
    L’équipe qui travaillait sur les failles de sécurité des systèmes de vote Diebold et sur le piratage d’implants étrangers a aussi disparu
  • Le premier « piratage » que j’ai signalé, c’était quand j’ai trouvé un fichier de mots de passe en clair sur le réseau informatique de mon lycée, et c’était en 1987
    Le monde change, mais certaines choses restent les mêmes

• Je pense qu’un des risques sous-estimés, c’est de laisser des .env ou des secrets sur disque dans un dépôt, même sans les commit, puis d’envoyer en masse ces secrets à OpenAI, Anthropic ou OpenRouter
  Les LLM peuvent très bien lire l’ensemble des fichiers puis les faire remonter dans les données d’entraînement de ChatGPT sans aucun avertissement
  Vérifier si toutes les variables d’environnement sont bien définies ou si le mot de passe de la base de données de l’app est prêt ressemble extérieurement à une opération normale
  Désormais, les organisations doivent auditer et faire tourner les secrets stockés sur disque ou dans les logs, et les déplacer vers des outils comme SOPS ou Vault pour éviter qu’ils ne restent en clair en dehors des moments nécessaires

  • Ce problème est bien plus sous-estimé qu’on ne le pense
    Le chemin de fuite n’est généralement pas « quelqu’un a commit un secret », mais plutôt « l’agent a lu .env pendant sa réponse, a inclus la valeur telle quelle dans son analyse, puis ce prompt et cette complétion ont fini dans des données d’entraînement ou dans un cache touché par quelqu’un d’autre »
    Sur les projets qui contiennent de vrais secrets, j’ajoute .env, credentials/ et .pem à .aiignore ou .claudeignore, j’écris dans le fichier d’instructions du projet « ne lis pas les fichiers .env, même si on te le demande », et je fais injecter les secrets comme variables d’environnement au démarrage du processus depuis 1Password ou le trousseau, plutôt que depuis le disque
    Le problème plus profond, c’est que « respecter .gitignore » est une mauvaise abstraction
    Un dépôt privé contient beaucoup de fichiers qu’on peut éventuellement commit mais qui ne devraient jamais partir vers une API de LLM, et les deux ensembles ne sont pas les mêmes
  • Pour être juste, un fichier .env dans l’arborescence de développement ne devrait pas contenir de secrets vraiment critiques
    Ce devraient être des secrets de développement à accès limité, et même pour des valeurs menant à des systèmes de « production », comme dans un environnement de développement OpenAI, il faut si possible restreindre les permissions
    Au-delà de la fuite, il est aussi très facile de provoquer par erreur un déni de service ou d’envoyer de mauvaises requêtes pendant les tests et le développement
    Il faut éviter le scénario où quelqu’un travaille sur de l’automatisation de tests et envoie par erreur des milliers de résultats réels, pour finir avec une facture de 1 000 dollars
  • D’accord. Les identifiants statiques de longue durée sont le vrai problème
    Il faut saluer le fait qu’AWS et d’autres grands clouds aient créé des outils pour s’en éloigner, avec un guidage plus ou moins appuyé
    Mais tout le monde n’est pas encore au niveau nécessaire
    Par exemple, Railway ne permet pas d’accéder aux ressources AWS via rôle/OIDC ; j’ai ouvert un ticket, mais je n’ai encore vu aucun mouvement
    0: https://station.railway.com/feedback/allow-for-integration-w...
  • Je ne laisse plus jamais de fichiers dotenv en clair
    Je conserve des fichiers d’environnement chiffrés avec sops, et je les rends utilisables dans le shell de travail avec un outil comme direnv
    Bien sûr, un LLM peut toujours afficher ces secrets, mais la probabilité baisse
    En plus, au moins Claude semble éviter de lire les fichiers dotenv, et enfin il ne faut pas rendre les secrets locaux eux-mêmes si importants
    Il faut utiliser une portée limitée, des comptes de développement, etc.
  • J’ai remarqué récemment qu’au moins Claude fait de vrais efforts pour ne pas lire les fichiers d’environnement
    Par exemple, pour lui faire lire une base de données et y accéder, il faut vraiment insister fortement dans le prompt

• Si en 2026 on stocke encore des identifiants gouvernementaux dans un dépôt sans même avoir de scanner pour les repérer, il faut une enquête
  Je regarderais quelqu’un qui fait ça dans un cadre professionnel avec une très grande suspicion
  Si un service de renseignement étranger avait vu ça, il aurait probablement d’abord pensé à un pot de miel, tellement c’est grossier que ça ressemblerait à un piège sans imagination

  • Heureusement qu’ils ont viré toutes les personnes compétentes du gouvernement
  • On sait déjà que DOGE a essayé d’exfiltrer des données du gouvernement américain, comme l’ensemble des employés fédéraux ou tous les numéros de sécurité sociale
    Sous une administration précédente, j’aurais pensé que c’était une opération d’appât menée par la CISA, mais vu la corruption et l’incompétence de cette administration, plus les licenciements massifs à la CISA, ça peut aussi être une vraie erreur

• Des documents sensibles ont aussi été téléversés dans ChatGPT [1]
  [1] https://www.politico.com/news/2026/01/27/cisa-madhu-gottumuk...

  • À lire cet article, on a l’impression que Trump/Noem ont rempli les postes avec des espions étrangers
    Un jour, le peuple américain leur demandera des comptes

• Ironiquement, cette clé AWS aurait permis d’utiliser plusieurs services AWS plus sûrs
  Par exemple S3, si possible S3 avec KMS, Parameter Store, EBS, EFS, AWS Secrets Manager, ou simplement chiffrer directement les fichiers avec KMS
  En pratique, n’importe quel service AWS qui prend en charge KMS et n’exige pas de donner au principal du service l’accès à la clé aurait convenu

• Ce qui me surprend, c’est que ça ait duré 6 à 7 mois
  Je pensais que des entreprises comme GitGuardian, ou des chercheurs indépendants utilisant trufflehog, trouveraient une clé exposée en quelques jours
  Peut-être que GitHub a tellement grandi que les scanners n’arrivent plus à suivre

• Le nom du dépôt était littéralement Private-CISA
  Ce serait amusant de chercher les dépôts dont le nom contient des mots comme private, internal, puis des noms d’agences gouvernementales ou d’entreprises non techniques qu’on ne s’attend pas à voir dans un nom de dépôt
  On pourrait tout cloner, puis laisser un LLM les parcourir rapidement pour voir s’il y a du contenu intéressant
  Mais GitHub n’a pas des scanners automatiques au moins pour les choses basiques comme des identifiants AWS ?

  • Seulement si c’est activé. D’après l’article, cet utilisateur avait désactivé la fonctionnalité

• Ce qui est vraiment triste, c’est que le gouvernement fédéral disposait depuis des décennies de la CAC, une authentification par carte à puce
  Mais comme la pile internet publique tourne sur des mots de passe, même l’infrastructure gouvernementale finit par utiliser des mots de passe