Plus de 9 300 clés AWS toujours actives sont exposées en ligne : des centaines peuvent donner le contrôle total des comptes

Quatre années de surveillance révèlent des milliers d’identifiants valides

Une analyse de Truffle Security a identifié plus de 9 300 clés d’accès AWS publiées en ligne entre août 2022 et août 2026 et toujours valides. Ces résultats ont été rendus publics le 21 août 2026, après quatre années de surveillance.

Le problème ne tient pas à une vulnérabilité du logiciel AWS, mais à la publication accidentelle d’identifiants permettant de s’authentifier auprès de comptes cloud. Les clés sont apparues dans des dépôts de code, des historiques Git, des jeux de données, des images Docker, des registres et des journaux générés par des systèmes d’intégration continue.

Au total, les chercheurs ont découvert 431 875 secrets AWS. Après déduplication, l’échantillon comprenait 64 024 clés uniques associées à 50 654 comptes AWS.

Le sous-ensemble analysé avec des identifiants complets, et donc vérifiable par une nouvelle authentification, comptait 10 616 clés. 88 % d’entre elles permettaient encore de s’authentifier correctement au 10 août. Ce chiffre indique qu’une part importante des identifiants publiés n’avait pas été révoquée ou remplacée.

Root et AdministratorAccess peuvent transformer une fuite en prise de contrôle

Parmi les clés encore actives, 817 étaient rattachées à des entreprises. Parmi celles-ci, 526 appartenaient à des utilisateurs root AWS, tandis que 242 étaient associées à des utilisateurs IAM disposant de la policy AdministratorAccess.

Ces deux catégories concentrent les privilèges les plus sensibles. L’identité root constitue le niveau d’administration maximal d’un compte et n’est pas soumise aux restrictions qui s’appliquent habituellement aux utilisateurs IAM. De son côté, AdministratorAccess permet de créer, modifier, supprimer et consulter pratiquement toutes les ressources et tous les services du compte.

Selon les chercheurs, 768 clés actives appartenant à ces deux groupes privilégiés permettaient de prendre totalement le contrôle du compte AWS de l’entreprise. Cela ne signifie pas que chaque clé a été utilisée par un attaquant, mais qu’un identifiant public et fonctionnel pouvait offrir un point d’entrée extrêmement large.

Avec un tel niveau d’accès, un intrus peut :

• lire, copier ou supprimer des données stockées dans le cloud ;
• intervenir sur les serveurs, applications, bases de données et configurations ;
• modifier les ressources existantes ou en créer de nouvelles ;
• créer des comptes administratifs frauduleux afin de conserver l’accès ;
• installer des logiciels de minage et faire rapidement augmenter les coûts ;
• altérer les services et les composants de l’infrastructure en ligne.

Le risque ne se limite donc pas au vol de la clé. Un attaquant peut l’utiliser pour modifier l’environnement AWS et rendre son activité malveillante plus difficile à distinguer des opérations administratives normales.

Hugging Face est la principale source individuelle d’exposition

La plateforme à l’origine du plus grand nombre d’expositions est Hugging Face, utilisée pour partager des modèles d’intelligence artificielle, des jeux de données et des applications. Les chercheurs lui ont attribué 8 482 expositions de clés uniques.

Parmi celles-ci, 17,9 % étaient des clés root. La présence d’identifiants AWS dans des contenus publiés sur une plateforme dédiée à l’intelligence artificielle peut s’expliquer par du code de démonstration, des notebooks, des jeux de données, des fichiers de configuration ou des éléments ajoutés au cours du développement.

Une clé publiée dans un projet public doit être considérée comme compromise, même si le dépôt est ensuite rendu privé ou si le fichier est supprimé. Des copies peuvent en effet subsister dans l’historique Git, les forks, les caches, les jeux de données téléchargés ou les systèmes d’indexation.

Les organisations concernées peuvent subir des conséquences différentes selon les ressources présentes dans leurs comptes respectifs : exposition de données, interruption d’applications, modification de l’infrastructure ou coûts imprévisibles liés à des services créés frauduleusement.

Les identifiants anciens et l’insuffisance des contrôles de dépenses amplifient le risque

L’analyse de l’ancienneté, disponible pour 2 903 clés, a établi un âge médian de 1 831 jours, soit environ cinq ans. La clé la plus ancienne existait depuis 17,4 ans.

Seuls 398 éléments, soit 13,7 %, disposaient d’une clé d’accès plus récente associée au même utilisateur. Pour Truffle Security, cela suggère que de nombreux identifiants n’avaient probablement jamais été renouvelés.

Une clé restée active pendant des années accroît la période durant laquelle elle peut être collectée et réutilisée. Par ailleurs, la simple présence d’une clé plus récente ne prouve pas automatiquement que l’ancienne a été révoquée : cette vérification doit être effectuée directement dans les configurations du compte.

La gestion des coûts aggrave encore la situation. Sur 2 754 comptes pour lesquels l’information était lisible, seuls 262 disposaient d’une alerte budgétaire. Sans alertes, un attaquant peut créer des ressources cloud ou lancer des activités très consommatrices sans que le titulaire soit rapidement informé d’une anomalie.

Le contexte opérationnel reste difficile, même lorsque l’organisation dispose d’outils de défense. Le Blue Report 2026, fondé sur 338 millions de simulations réalisées dans les environnements de production des clients, indique que lorsque l’attaquant utilise des identifiants valides, seules 37 % des actions sont bloquées. Une clé correcte peut donc contourner de nombreux contrôles conçus pour détecter les accès non autorisés.

Que doivent faire les titulaires de comptes AWS ?

La priorité consiste à révoquer toute clé apparue dans une source publique et à la remplacer par de nouveaux identifiants, sans se contenter de supprimer le fichier qui la contient. La rotation doit s’accompagner d’une vérification des journaux afin de détecter d’éventuelles authentifications ou modifications suspectes.

Les principales recommandations sont les suivantes :

1. supprimer les clés d’accès root ;
2. répertorier les identifiants IAM selon leur ancienneté et leur dernière utilisation ;
3. révoquer ou renouveler immédiatement ceux qui ont été exposés ;
4. contrôler les utilisateurs, rôles, policies et comptes administratifs récemment créés ;
5. configurer des alertes budgétaires et des seuils de dépenses ;
6. rechercher les clés dans les dépôts, historiques Git, images Docker, jeux de données et journaux ;
7. considérer comme compromis tout identifiant publié, même en l’absence d’abus constaté.

Pour la surveillance future, il est préférable d’utiliser des rôles IAM et des identifiants temporaires, afin de réduire le recours aux clés statiques. Les secrets ne doivent pas être intégrés au code ou aux jeux de données : ils doivent être stockés dans des systèmes dédiés et faire l’objet d’analyses automatiques avant toute publication.

Truffle Security indique avoir limité ses tests à la lecture des métadonnées et avoir averti tous les propriétaires identifiables. On ignore combien de comptes ont effectivement été compromis ou combien d’attaques ont exploité les clés découvertes. Le constat est toutefois suffisant pour considérer tout identifiant exposé comme n’étant plus fiable.