- Publié le
4 837 comptes GitHub, une seule pull request : le voleur de secrets CI
- Auteurs

- Nom
- AbnAsia.org
- @steven_n_t
Listen in English · 4 837 comptes GitHub, une seule pull request : le voleur de secrets CI
0:00 / 0:00
Watch in English · 4 837 comptes GitHub, une seule pull request : le voleur de secrets CI
Un attaquant a emprunté l’accès en écriture de 4 837 comptes GitHub compromis, l’a testé avec une pull request intitulée « docs: dependency audit notes », et a exécuté un voleur d’identifiants dans au moins 1 806 dépôts. Les secrets qu’il visait sont exactement ceux que votre CI détient déjà.
À partir de mardi, un attaquant a utilisé des identifiants volés pour 4 837 comptes GitHub afin d’implanter un voleur de secrets dans les dépôts où ces comptes pouvaient écrire. Aikido Security a compté au moins 1 806 dépôts où le voleur s’est exécuté. SafeDep, en analysant indépendamment, a compté 8 093 dépôts ayant reçu des commits malveillants sur une fenêtre de seize heures — uniquement les branches par défaut des dépôts publics, donc le nombre réel est plus élevé.
La méthode était monotone et efficace. Chaque attaque commençait par une pull request intitulée docs: dependency audit notes, ouverte depuis une branche nommée wfx-docs, uniquement pour vérifier si le compte pouvait écrire dans le dépôt. Ces pull requests de test sont apparues dans 61 764 dépôts.

Neuf minutes d’accès suffisent
Dans 7 309 dépôts, le voleur d'informations a été ajouté à un workflow existant. Dans 771, il est arrivé sous forme de hook postinstall npm — qui s'exécute aussi sur l'ordinateur portable d'un développeur pendant npm install. L'attaquant annulait généralement le commit en quelques minutes et supprimait les journaux d'exécution, c'est pourquoi l'absence de numéro d'exécution sur le commit malveillant est un meilleur indicateur que tout artefact laissé derrière.
Emprunter un accès en écriture
4 837 comptes volés, testés avec une PR jetable
Ajouter le stealer
une étape supplémentaire dans un workflow existant, ou un hook postinstall npm
Récolter
secrets Actions, GITHUB_TOKEN, jetons OIDC, clés cloud, mémoire du runner
Annuler et nettoyer
commit disparu en quelques minutes, journaux supprimés
Ce qu'il a fallu, et ce qu'il a laissé derrière
Le voleur a collecté les secrets et variables GitHub Actions, le GITHUB_TOKEN du workflow, les jetons OIDC et les jetons d'exécution Actions, les clés pour les services d'IA, ainsi que les fichiers d'identifiants pour AWS, Azure, GCP, Kubernetes, npm, PyPI et SSH. Sur les runners auto-hébergés, il a aussi lu les identifiants cloud depuis les métadonnées d'instance, l'état Docker et les unités systemd.
Certains éléments ont été conçus pour survivre à une rotation : ils peuvent réécrire la politique de confiance d’un rôle AWS pour ouvrir ce rôle à n’importe quel compte AWS, et ajouter des identifiants d’identité fédérée préfixés wfx-ci- à des applications Azure AD, afin qu’un dépôt compromis puisse se connecter à Azure sans aucun secret stocké. C’est pourquoi la réponse n’est pas « faites tourner le jeton », mais « partez du principe que l’ensemble du workflow était contrôlé par l’attaquant ».
Stupide, et entièrement évitable
Rien ici n’était un zero-day. C’était un accès en écriture plus un runner de workflow, les deux choses que chaque dépôt possède déjà.
Le conseil d’Aikido est sans ambiguïté : tout compte ayant ouvert l’une des pull requests de test est compromis, même si le voleur n’a jamais été exécuté ; révoquez donc ses jetons, ses autorisations OAuth, ses clés SSH et ses sessions, activez la 2FA, et faites tourner tous les secrets et variables que le dépôt peut lire. Toute personne ayant exécuté npm install sur un commit affecté doit considérer cette machine comme compromise.
ABN Asia développe des logiciels pour les organisations qui ne peuvent pas se permettre de servir de cas d’école. Cela signifie que les fichiers de workflow sont relus comme du code de production, que les secrets sont limités au job qui en a besoin plutôt qu’à l’ensemble du dépôt, que l’on utilise des identifiants OIDC à courte durée de vie plutôt que des clés cloud à longue durée de vie, que l’on épingle et relit chaque dépendance, et que la détection associe un nom à l’alerte.
Vous n’obtenez pas seulement un logiciel — vous obtenez un logiciel sécurisé. Si votre CI détient des identifiants donnant accès à quoi que ce soit d’important, parlez-nous : [email protected].
Source : The Hacker News, 12 novembre 2026, rapportant des analyses d’Aikido Security et de SafeDep.
Veuillez noter que la version française est assistée par Ai, des erreurs mineures peuvent donc exister.
Auteur
Ai-Banking-NetworkSecurity (ABN), ABN ASIA a été fondée par des personnes ayant des racines profondes dans le milieu académique, avec une expérience professionnelle aux États-Unis, aux Pays-Bas, en Hongrie, au Japon, en Corée du Sud, à Singapour et au Vietnam. ABN ASIA est l'endroit où l'académie et la technologie rencontrent l'opportunité. Avec nos solutions de pointe et nos services de développement logiciel compétents, nous aidons les entreprises à se développer et à s'imposer sur la scène mondiale. Notre engagement : Plus vite. Mieux. Plus fiable. Dans la plupart des cas : moins cher également.
N'hésitez pas à nous contacter chaque fois que vous avez besoin de services informatiques, de conseils en matière de numérique, de solutions logicielles prêtes à l'emploi, ou si vous souhaitez nous envoyer des demandes de propositions (RFP). Vous pouvez nous contacter à l'adresse [email protected]. Nous sommes prêts à vous aider avec tous vos besoins technologiques.

© ABN ASIA