Une mauvaise configuration critique dans Amazon Web Services (AWS) CodeBuild aurait pu permettre la prise de contrôle complète des propres référentiels GitHub du fournisseur de services cloud, y compris son SDK AWS JavaScript, mettant ainsi en danger tous les environnements AWS.
La vulnérabilité a été nommée dans le code. Violation du code par la société de sécurité cloud Wiz. AWS a résolu le problème en septembre 2025 suite à une divulgation responsable le 25 août 2025.
“En exploitant CodeBreach, les attaquants auraient pu injecter du code malveillant pour lancer une compromission à l'échelle de la plateforme, affectant potentiellement non seulement les innombrables applications qui dépendent du SDK, mais aussi la console elle-même, menaçant tous les comptes AWS”, ont déclaré les chercheurs Yuval Avrahami et Nir Ohfeld dans un rapport partagé avec The Hacker News.
La faille, a noté Wiz, est le résultat d'une faiblesse dans les pipelines d'intégration continue (CI) qui aurait pu permettre à des attaquants non authentifiés de violer l'environnement de construction, de divulguer des informations d'identification privilégiées telles que les jetons d'administrateur GitHub, puis de les utiliser pour apporter des modifications malveillantes au référentiel compromis, créant ainsi une voie pour les attaques de la chaîne d'approvisionnement.
En d’autres termes, le problème sape les filtres webhook introduits par AWS pour garantir que seuls certains événements déclenchent une génération de CI. Par exemple, AWS CodeBuild peut être configuré pour déclencher une génération uniquement lorsque les modifications de code sont validées dans une branche spécifique ou lorsqu'un ID de compte GitHub ou GitHub Enterprise Server (également appelé ACTOR_ID ou Actor ID) correspond au modèle d'expression régulière. Ces filtres protègent contre les demandes d’extraction non fiables.
La mauvaise configuration a affecté les référentiels GitHub open source suivants, gérés par AWS, qui sont configurés pour exécuter des builds sur des demandes d'extraction :
- aws-sdk-js-v3
- aws-lc
- fournisseur-de-crypto-amazon-corretto
- awslabs/open-data-journalisation
Les quatre projets, qui ont implémenté un filtre ACTOR_ID, ont subi un « défaut fatal » en n'incluant pas deux caractères de garantie (c'est-à-dire les ancres ^ et $ de fin) nécessaires pour produire une correspondance exacte d'expression régulière (regex). Au lieu de cela, le modèle d'expression régulière permettait à tout ID utilisateur GitHub qui était une superchaîne d'un ID approuvé (par exemple, 755743) de contourner le filtre et de déclencher la génération.
Étant donné que GitHub attribue des identifiants d'utilisateur numériques de manière séquentielle, Wiz a déclaré qu'il pouvait prédire que les nouveaux identifiants d'utilisateur (actuellement à 9 chiffres) “éclipseraient” l'identifiant à six chiffres d'un mainteneur de confiance environ tous les cinq jours. Ces informations, ainsi que l'utilisation des applications GitHub pour automatiser la création d'applications (qui, à leur tour, créent un utilisateur de bot correspondant), ont permis de générer un identifiant cible (par exemple, 226755743) en déclenchant des centaines d'enregistrements de nouveaux utilisateurs de bot.
Armé de l'ID d'acteur, un attaquant peut désormais déclencher une build et obtenir les informations d'identification GitHub du projet CodeBuild aws-sdk-js-v3, un jeton d'accès personnel (PAT) appartenant à l'utilisateur aws-sdk-js-automation, qui dispose de tous les privilèges d'administrateur sur le référentiel.
L'attaquant peut exploiter cet accès élevé pour envoyer du code directement vers la branche principale, approuver les demandes d'extraction et divulguer les secrets du référentiel, ouvrant ainsi la voie à des attaques sur la chaîne d'approvisionnement.
« Les expressions régulières de référentiel précédemment configurées pour les filtres webhook AWS CodeBuild destinés à limiter les ID d'acteur de confiance étaient insuffisantes, permettant à un ID d'acteur acquis de manière prévisible d'obtenir des autorisations administratives sur les référentiels concernés », a déclaré AWS dans un avis publié aujourd'hui.
“Nous pouvons confirmer qu'il s'agissait de mauvaises configurations spécifiques au projet dans les filtres d'ID d'acteur webhook pour ces référentiels et non d'un problème dans le service CodeBuild lui-même.”
Amazon a également déclaré avoir résolu les problèmes identifiés, en plus de mettre en œuvre des mesures d'atténuation supplémentaires telles que des rotations d'informations d'identification et des étapes pour protéger les processus de construction contenant des jetons GitHub ou toute autre information d'identification en mémoire. En outre, il a souligné qu’il n’avait trouvé aucune preuve que CodeBreach ait été exploité dans la nature.
Pour atténuer ces risques, il est essentiel que les contributions non fiables ne déclenchent pas de canaux CI/CD privilégiés en activant la nouvelle porte de build Pull Request Comment Approval, d'utiliser les exécuteurs hébergés par CodeBuild pour gérer les déclencheurs de build via les workflows GitHub, de garantir que les modèles d'expression régulière dans les filtres webhook sont épinglés, de générer un PAT unique pour chaque projet CodeBuild, de limiter les autorisations PAT au minimum requis et d'envisager l'utilisation d'un compte GitHub dédié sans privilèges pour l'intégration de CodeBuild.
« Cette vulnérabilité est un exemple classique de la raison pour laquelle les adversaires ciblent les environnements CI/CD : une faille subtile et facilement négligée qui peut être exploitée pour avoir un impact massif », ont noté les chercheurs de Wiz. « Cette combinaison de complexité, de données non fiables et d'informations d'identification privilégiées crée une tempête parfaite pour les violations à fort impact qui ne nécessitent pas d'accès préalable. »
Ce n’est pas la première fois que la sécurité du pipeline CI/CD est soumise à un examen minutieux. L'année dernière, une enquête Sysdig a détaillé comment les flux de travail GitHub Actions non sécurisés associés au déclencheur pull_request_target pourraient être exploités pour divulguer le GITHUB_TOKEN privilégié et obtenir un accès non autorisé à des dizaines de projets open source grâce à l'utilisation d'une seule demande d'extraction provenant d'un fork.
Une analyse similaire en deux parties d'Orca Security a révélé un pull_request_target non sécurisé dans des projets de Google, Microsoft, NVIDIA et d'autres sociétés Fortune 500 qui auraient pu permettre aux attaquants d'exécuter du code arbitraire, de divulguer des secrets sensibles et de transmettre du code malveillant ou des dépendances vers des branches de confiance. Le phénomène a été nommé pull_request_nightmare.
“En abusant des flux de travail mal configurés déclenchés via pull_request_target, les adversaires pourraient passer d'une requête d'extraction non fiable à une exécution de code à distance (RCE) sur des coureurs hébergés sur GitHub ou même auto-hébergés”, a noté le chercheur en sécurité Roi Nisimi.
“Les workflows GitHub Actions qui utilisent pull_request_target ne devraient jamais vérifier du code non fiable sans une validation appropriée. Une fois qu'ils le font, ils risquent d'être complètement compromis.”
