Une faille de la chaîne logistique dans l’automatisation des compilations AWS aurait pu permettre à des attaquants de détourner des dépôts GitHub de confiance et d’injecter du code malveillant dans des composants logiciels AWS largement utilisés.
Les chercheurs de Wiz ont déclaré que le problème, baptisé CodeBreach, créait un chemin entre une seule pull request et des workflows CI/CD privilégiés — avec un impact potentiel à très grande échelle sur les applications en aval.
Les chercheurs ont «… identifié un problème de configuration affectant les dépôts GitHub open source gérés par AWS suivants, qui aurait pu entraîner l’introduction de code inapproprié », a déclaré AWS dans son avis de sécurité.
Ils ont ajouté : « Aucun code inapproprié n’a été introduit dans les dépôts concernés pendant cette activité de recherche en sécurité, et ces activités n’ont eu aucun impact sur les environnements des clients AWS ni sur les services ou l’infrastructure AWS. »
Au cœur du risque de chaîne logistique CodeBreach
Wiz a indiqué que CodeBreach exposait un risque de chaîne logistique dans quatre dépôts AWS : aws/aws-sdk-js-v3, aws/aws-lc, corretto/amazon-corretto-crypto-provider et awslabs/open-data-registry.
Le problème ne se limitait pas à un seul projet : il résidait dans la possibilité que des attaquants détournent une automatisation CI/CD de confiance pour injecter du code malveillant en amont, puis laissent cette compromission se propager en aval au gré des compilations et mises à jour habituelles.
Le scénario le plus grave concernait le SDK JavaScript d’AWS, largement utilisé dans les environnements cloud et fréquemment intégré aux applications via des gestionnaires de paquets comme npm.
Si des attaquants parvenaient à falsifier ce SDK, ils pourraient potentiellement empoisonner les mises à jour que les développeurs et les systèmes de production consomment automatiquement, transformant les mises à niveau normales des dépendances en canal de distribution furtif pour du code malveillant.
Sur le plan technique, Wiz a attribué la cause première à une faille de contrôle d’accès dans les filtres de webhooks d’AWS CodeBuild liés au paramètre ACTOR_ID.
Ces filtres sont censés garantir que seules des identités GitHub de confiance peuvent déclencher des compilations privilégiées, en particulier dans les workflows exécutés avec des autorisations élevées ou ayant accès à des secrets sensibles.
Cependant, Wiz a constaté que les expressions régulières utilisées dans ces filtres n’étaient pas ancrées, c’est-à-dire qu’il leur manquait les ancres de début^ et $de fin nécessaires à une correspondance stricte et exacte.
Ce détail était important, car un motif non ancré peut correspondre à davantage d’éléments que prévu.
Au lieu d’autoriser les compilations uniquement lorsque l’ACTOR_ID correspondait à un identifiant utilisateur approuvé précis, le filtre pouvait également correspondre à tout identifiant utilisateur GitHub contenant une sous-chaîne approuvée.
Les chercheurs ont montré comment des attaquants pouvaient exploiter ce mécanisme au moyen de ce qu’ils ont appelé des événements d’éclipse — des cas où un identifiant numérique GitHub nouvellement créé et plus long finit par contenir comme sous-chaîne l’identifiant court de six à sept chiffres d’un ancien mainteneur.
GitHub attribuant les identifiants de manière séquentielle et en créant environ 200 000 nouveaux identifiants par jour, Wiz a indiqué que ces chevauchements se produisaient assez souvent pour être exploitables, les conditions d’éclipse apparaissant environ tous les cinq jours pour les identifiants ciblés.
Preuve de concept (PoC)
Dans une preuve de concept visant aws/aws-sdk-js-v3, Wiz a démontré comment une pull request malveillante pouvait déclencher une compilation privilégiée et exécuter une charge utile dissimulée dans l’environnement de compilation.
La charge utile a ensuite vidé la mémoire des processus afin d’extraire un jeton d’accès personnel GitHub (PAT) associé au compte aws-sdk-js-automation — malgré le renforcement de la sécurité mis en place après l’incident Amazon Q de 2025.
Wiz n’a pas poursuivi l’escalade jusqu’à son terme après avoir confirmé l’impact et a signalé le problème de manière responsable à AWS le 25 août 2025.
Les chercheurs ont indiqué que le PAT récupéré disposait de droits étendus à fort impact, notamment repo et admin:repo_hook, ce qui aurait pu permettre à un attaquant d’inviter des collaborateurs, d’élever ses privilèges et de pousser directement vers des branches protégées.
Le même jeton donnait également accès à des dépôts privés connexes, élargissant le périmètre potentiel de l’attaque au-delà d’un seul projet open source et créant les conditions d’une compromission plus vaste de la chaîne logistique à l’échelle de l’écosystème.
AWS a corrigé le problème, renouvelé les identifiants exposés et mis en place des mesures de protection supplémentaires pour éviter qu’il ne se reproduise.
Renforcer les pipelines CI/CD
Les incidents de chaîne logistique comme CodeBreach montrent comment de petites failles de confiance dans les systèmes CI/CD peuvent rapidement devenir des vecteurs de compromission à fort impact.
Lorsque les systèmes de compilation s’exécutent avec des autorisations élevées, un seul contournement peut exposer les identifiants d’automatisation et permettre des modifications de code non autorisées en amont.
L’objectif est de réduire la confiance implicite dans les déclencheurs de compilation, de limiter ce à quoi les workflows non fiables peuvent accéder et d’améliorer la visibilité sur les comportements anormaux des pipelines.
- Ancrer les expressions régulières des filtres de webhooks (avec ^ et $) afin d’imposer des correspondances d’identité exactes et d’empêcher les contournements par identifiant d’acteur.
- Utiliser des identifiants à durée de vie courte et aux privilèges précis (OIDC lorsque c’est possible) et éviter les droits PAT étendus et persistants dans les workflows CI/CD.
- Exiger des étapes d’approbation explicites pour les pull requests et veiller à ce que les compilations de PR non fiables s’exécutent sans accès aux secrets ni aux variables privilégiées.
- Séparer les pipelines de mise en production de confiance des workflows de contribution non fiables et exécuter les compilations sur des runners isolés et éphémères afin de limiter le périmètre de l’attaque.
- Surveiller les journaux de compilation et la télémétrie des runners pour détecter les exécutions inhabituelles, l’extraction de mémoire, l’utilisation abusive de jetons et les modifications non autorisées des dépôts (par exemple les hooks, les invitations et les pushes).
- Renforcer l’intégrité de la chaîne logistique avec des branches protégées, des revues obligatoires, des commits signés et la traçabilité ou la signature des artefacts afin de réduire les risques en aval.
- Tester et répéter les procédures de réponse aux incidents CI/CD (par exemple la révocation des jetons, l’isolement des runners, la rotation des clés et les procédures de reconstruction) afin de garantir un confinement rapide en cas de compromission des identifiants d’automatisation.
Ces contrôles contribuent à empêcher les abus de CI/CD, à protéger les identifiants d’automatisation et à limiter le périmètre des attaques de la chaîne logistique.
Quand l’automatisation des compilations devient un vecteur d’attaque
CodeBreach rappelle que la sécurité de la chaîne logistique repose souvent sur de petites hypothèses de confiance au sein des pipelines CI/CD, là où se rejoignent l’automatisation, les contrôles d’identité et les secrets.
Même lorsqu’aucun impact client n’est confirmé, ce scénario montre à quelle vitesse une porte de contrôle de compilation mal configurée peut transformer une activité ordinaire de pull request en exposition d’identifiants et en risque de compromission en amont.
Les organisations devraient y voir une invitation à valider la logique de filtrage des webhooks, à réduire les privilèges des jetons, à isoler les compilations non fiables et à renforcer de bout en bout les contrôles d’intégrité des mises en production.
C’est ce même principe de réduction de la confiance implicite et d’application d’une vérification stricte qui explique l’adoption de solutions zero trust.