Des milliers de clés AWS publiquement exposées sont toujours actives

Les résultats publiés en août 2026 par Truffle Security dressent le portrait d’un problème de sécurité cloud à la fois massif et remarquablement persistant. Entre août 2022 et août 2026, les chercheurs ont recensé 431 875 occurrences de secrets AWS dans des dépôts publics, des historiques Git, des jeux de données, des images Docker, des registres de conteneurs et des journaux d’intégration continue. Après déduplication et vérification, l’ensemble représentait 64 024 clés AWS uniques. 145

Le chiffre le plus préoccupant ne concerne toutefois pas seulement le volume des fuites, mais leur durée de vie : parmi les 10 616 paires d’identifiants complètes testées le 10 août 2026, 9 308 — environ 88 % — ont encore permis une authentification réussie. 145

Des identifiants parfois capables de prendre le contrôle d’un compte AWS

L’ensemble vérifié comprenait 10 625 identifiants root, 48 744 clés associées à des utilisateurs IAM et 4 655 clés qui n’ont pas pu être classées. Les identifiants root représentaient 16,6 % des clés uniques. 1

Truffle Security a par ailleurs identifié 817 clés actives liées à des entreprises, dont :

• 526 clés root, le niveau d’accès le plus élevé dans un compte AWS ;
• 242 clés d’utilisateurs IAM dotées de AdministratorAccess, une politique pouvant donner le contrôle complet du compte ;
• 768 identifiants au total susceptibles de permettre à un attaquant de prendre le contrôle complet d’un compte AWS d’entreprise ;
• 130 clés root actives rattachées à des comptes de gestion AWS Organizations, dont la compromission pourrait potentiellement affecter les comptes membres de toute une organisation. 13

Dans un sous-ensemble composé d’utilisateurs IAM dont les politiques pouvaient être énumérées, 976 utilisateurs sur 1 157 — soit 84 % — disposaient de AdministratorAccess. Cent quarante-quatre autres avaient IAMFullAccess. Truffle Security précise que cette proportion doit être considérée comme indicative : les utilisateurs autorisant l’énumération de leurs politiques ne représentent pas nécessairement l’ensemble des utilisateurs IAM dont les clés ont fuité. 1

Combien de comptes AWS sont concernés ?

Les éléments fournis font apparaître deux totaux qui semblent correspondre à des périmètres différents. Un résumé associe les 64 024 clés à 9 945 comptes AWS distincts, tandis que le résumé du rapport source mentionne 50 654 comptes AWS distincts. Les documents disponibles n’expliquent pas l’écart entre ces deux chiffres ; ils ne doivent donc pas être considérés comme interchangeables. 1

Le niveau de risque est néanmoins clair : des centaines de clés actives étaient liées à des entreprises et 768 pouvaient donner un contrôle complet d’un compte AWS professionnel. 13

Hugging Face, principale source individuelle

Hugging Face arrive en tête des sources identifiées, avec 8 482 clés AWS uniques et actives réparties dans 3 394 jeux de données publics. Les identifiants root représentaient 17,9 % de ces clés, la plus forte proportion observée parmi les sources suivies. 125

Le fonctionnement des données publiques peut amplifier ce type d’exposition. Des instantanés de code contenant des secrets peuvent être intégrés à des jeux de données d’entraînement, puis réutilisés dans plusieurs jeux de données dérivés. Supprimer une clé du dépôt d’origine ne garantit donc pas la disparition de toutes ses copies. 1

Ce résultat centré sur AWS s’inscrit dans une analyse plus large menée par Truffle Security sur Hugging Face. L’entreprise affirme avoir examiné 7,6 pétaoctets et 187 millions de fichiers, pour identifier 221 303 identifiants actifs et uniques dans 6 003 jeux de données. Ces chiffres couvrent tous les types d’identifiants, et pas uniquement les clés AWS. 6

Des clés souvent anciennes et rarement renouvelées

Parmi 2 903 clés actives dont la date de création pouvait être lue, l’âge médian atteignait 1 831 jours, soit environ cinq ans. La moitié d’entre elles avaient plus de cinq ans ; la plus ancienne avait 17,4 ans. Seules 25 clés, soit 0,9 %, avaient été créées au cours des 30 jours précédents. 1

Seules 398 de ces 2 903 clés — 13,7 % — disposaient d’une clé de remplacement plus récente. Cela laisse penser que la plupart n’avaient pas été renouvelées, remplacées ou supprimées après leur exposition. 1

La leçon opérationnelle est simple : tout secret apparu dans un contenu public doit être considéré comme définitivement compromis, même si le fichier ou la ligne concernée a ensuite été modifié. L’historique Git, les images de conteneurs, les artefacts de paquets et les jeux de données publics peuvent conserver les anciennes versions. 1

Peu d’alertes budgétaires face au risque de minage clandestin

Les contrôles de dépenses étaient eux aussi peu répandus. Sur 2 754 comptes dont les paramètres pouvaient être lus, seuls 262 — 9,5 % — avaient configuré une alerte budgétaire. Le seuil médian de ces alertes était de 8 dollars. 12

Cela signifie que 90,5 % des comptes lisibles ne présentaient aucune alerte budgétaire détectable. Des identifiants encore utilisables pourraient ainsi servir à lancer du minage de cryptomonnaies ou d’autres charges de calcul avant que l’entreprise ne remarque une hausse anormale de sa facture cloud. 12

Les comptes dont les données de dépenses étaient accessibles avaient consommé au total 420 631 dollars en juillet 2026. Cinquante d’entre eux avaient dépensé plus de 1 000 dollars ce mois-là, et neuf plus de 10 000 dollars. Ces montants décrivent les comptes observés ; ils ne prouvent pas que ces dépenses résultaient d’un abus d’identifiants. 1

La mise en quarantaine AWS ne désactive pas forcément la clé immédiatement

Truffle Security a indiqué avoir observé AWS appliquer la politique AWSCompromisedKeyQuarantine à des clés IAM exposées. Cette politique limite les actions possibles avec une clé détectée, mais ne désactive pas nécessairement l’authentification sur-le-champ. 1

Parmi les clés IAM actives examinées, 929 sur 7 590 — soit 12 % — étaient associées à cette politique. Cent douze autres utilisaient une version plus ancienne, dont AWS a cessé l’application en 2023. Selon les observations de Truffle Security, certaines clés restaient donc utilisables malgré des signalements d’exposition anciens. 1

Une politique de quarantaine doit ainsi être considérée comme un signal d’exposition, et non comme la preuve que le secret a été définitivement retiré. L’organisation doit identifier le propriétaire de la clé, vérifier ses permissions, puis la révoquer ou la renouveler. 1

Une méthode de vérification limitée aux identifiants complets

Truffle Security précise n’avoir retesté que les paires d’identifiants pour lesquelles elle disposait de tous les éléments nécessaires. Pour analyser les comptes et les privilèges, les chercheurs ont utilisé des appels IAM en lecture seule, une clé à la fois. Ils n’ont pas publié les secrets eux-mêmes et ont informé tous les propriétaires qu’ils ont pu identifier. 15

Cette méthode est importante pour interpréter le taux de 88 % : il s’applique au sous-ensemble de paires complètes retestées, et non à l’ensemble des occurrences publiques ni à tous les secrets partiels découverts pendant le scan. 14

Les mesures à prendre par les organisations

Les résultats soutiennent une liste d’actions immédiates :

1. Supprimer les clés d’accès root. Truffle Security estime qu’elles n’ont pas d’usage opérationnel légitime. 1
2. Inventorier toutes les clés d’accès IAM, notamment dans les dépôts, l’historique Git, les journaux de CI, les images, les registres, les artefacts de paquets et les jeux de données publiés. 1
3. Révoquer ou renouveler immédiatement les identifiants exposés. Effacer une copie visible ne suffit pas si le secret subsiste dans l’historique ou dans des artefacts dérivés. 1
4. Fixer une durée de vie maximale et imposer le renouvellement des clés. Les identifiants anciens et inutilisés doivent être supprimés plutôt que conservés indéfiniment. 1
5. Configurer des alertes budgétaires. Même un seuil bas, par exemple 10 dollars, peut fournir un premier signal en cas de dépenses non autorisées. 1
6. Surveiller la présence de AWSCompromisedKeyQuarantine et traiter cette politique comme un indice d’exposition nécessitant une investigation. 1
7. Mettre en place une détection continue des secrets dans le code source, son historique, les systèmes de build, les artefacts de conteneurs, les registres et les jeux de données publics. 1

L’avertissement central de l’étude est qu’une exposition publique n’est pas une fuite ponctuelle. Sans révocation, renouvellement et surveillance, une clé AWS peut rester pendant des années une porte d’accès fonctionnelle vers une infrastructure cloud.