Grafana pirate via GitHub Actions : le code source integral vole, la rancon refusee

Ce qui s'est passe : les faits bruts

Vendredi 16 mai 2026, Grafana Labs publie un post-incident review qui fait l'effet d'une bombe dans la communaute open source. Un attaquant non identifie — plus tard revendique par le groupe d'extorsion CoinbaseCartel — a exploite un workflow GitHub Actions mal configure dans le depot public grafana/grafana pour voler un token d'acces privilegie. Avec ce token, l'attaquant a telecharge l'integralite du code source prive de l'entreprise.

Le vecteur d'attaque est precis : un fichier workflow nomme pr-patch-check-event.yml, recemment active, etait configure pour se declencher sur l'evenement pull_request_target. Contrairement a pull_request, ce trigger execute le workflow dans le contexte du depot cible — avec acces complet aux secrets de production — meme quand la pull request provient d'un fork externe. C'est ce que les chercheurs en securite appellent une « Pwn Request ».

L'attaquant a forke le depot Grafana, cree une branche avec un nom specialement concu pour exploiter une injection de script, et exfiltre les tokens GRAFANA_DELIVERY_BOT_APP_ID et GRAFANA_DELIVERY_BOT_APP_PEM en les chiffrant avec sa propre cle privee et en les dumpant dans un fichier. L'exploitation s'est produite lors du tout premier run du workflow declenche par la pull request malveillante — aucun merge ni escalade de privilege supplementaire n'a ete necessaire.

La detection est venue d'un canary token deploye par l'equipe securite de Grafana. Des son declenchement, l'equipe a immediatement invalide tous les credentials compromis, supprime le workflow vulnerable, et desactive tous les workflows publics le temps de l'investigation.

Qui est CoinbaseCartel et pourquoi c'est un signal d'alarme

CoinbaseCartel est un groupe d'extorsion de donnees apparu en septembre 2025. Selon les analyses de The Hacker News, le groupe est evalue comme une ramification des ecosystemes ShinyHunters, Scattered Spider et LAPSUS$ — trois collectifs responsables de certaines des plus grosses breaches de ces cinq dernieres annees (Microsoft, Okta, Uber, T-Mobile).

Le modus operandi est redoutablement simple : pas de ransomware, pas de chiffrement. CoinbaseCartel se concentre exclusivement sur l'exfiltration de donnees et l'extorsion. Ils volent, puis menacent de publier. Le modele economique repose sur la pression reputationnelle plutot que sur la destruction operationnelle. C'est plus discret, plus difficile a detecter, et souvent plus lucratif.

Pour les developpeurs open source, ce qui est preoccupant c'est que CoinbaseCartel cible specifiquement les pipelines CI/CD. Grafana n'est probablement pas leur seule victime. Le fait qu'ils aient exploite une vulnerabilite bien documentee (pull_request_target) suggere qu'ils scannent systematiquement les depots publics a la recherche de workflows mal configures. Votre projet open source pourrait etre le prochain.

Anatomie technique de l'attaque : du fork au vol de code

L'attaque se decompose en cinq etapes chirurgicales. Comprendre cette sequence est essentiel pour tout developpeur qui maintient des workflows GitHub Actions :

1. Reconnaissance : l'attaquant identifie le workflow pr-patch-check-event.yml dans le depot public grafana/grafana. Le trigger pull_request_target est visible en clair dans le fichier YAML. Les secrets references (GRAFANA_DELIVERY_BOT_APP_ID, GRAFANA_DELIVERY_BOT_APP_PEM) sont nommes explicitement.
2. Fork et injection : l'attaquant forke le depot, cree une branche dont le nom contient du JavaScript malveillant concu pour echapper au contexte litteral et executer du code arbitraire pendant le run CI.
3. Exfiltration du token : lors du premier run du workflow, le code injecte dump les variables d'environnement contenant les secrets, les chiffre avec la cle publique de l'attaquant, et les ecrit dans un fichier accessible.
4. Clonage du code source : avec le token obtenu, l'attaquant s'authentifie via l'API GitHub et clone tous les depots prives de l'organisation Grafana Labs.
5. Extorsion : CoinbaseCartel contacte Grafana Labs et exige une rancon en echange de la non-publication du code source vole.

Pourquoi pull_request_target est si dangereux : explication pour developpeurs

Pour comprendre la gravite de cette faille, il faut comprendre la difference fondamentale entre deux triggers GitHub Actions qui semblent similaires mais qui ont des implications de securite radicalement differentes.

pull_request (securise) : le workflow s'execute dans le contexte du fork. Il n'a aucun acces aux secrets du depot cible. Un contributeur externe ne peut pas lire vos variables d'environnement, vos tokens, ni vos cles API. C'est le comportement par defaut et c'est celui que vous devriez utiliser 99% du temps.

pull_request_target (dangereux) : le workflow s'execute dans le contexte du depot cible — le votre. Il a acces complet aux secrets de production. GitHub a cree ce trigger pour des cas d'usage specifiques (etiquetage automatique de PR, commentaires de bienvenue, etc.) ou le workflow a besoin d'ecrire dans le depot cible. Le probleme : des que le workflow execute du code provenant de la PR (checkout du code du fork, evaluation d'expressions contenant des donnees controlees par l'attaquant), c'est game over.

Dans le cas de Grafana, le workflow faisait exactement cela : il checkoutait le code du fork pour verifier les patches, tout en ayant acces aux secrets de production. C'est comme donner les cles de votre coffre-fort a un inconnu en lui demandant de verifier que la serrure fonctionne.

Le plus preoccupant : selon une analyse de StepSecurity, cette vulnerabilite est documentee comme dangereuse depuis 2020. GitHub lui-meme a publie des avertissements. Les chercheurs de JFrog ont publie des analyses detaillees. Et pourtant, en 2026, l'un des projets open source les plus populaires au monde tombe dans le piege.

Impact sur l'ecosysteme open source : bien au-dela de Grafana

L'incident Grafana n'est pas un cas isole. C'est le symptome d'un probleme systemique dans la facon dont les projets open source gerent leur securite CI/CD. Voici pourquoi chaque mainteneur de projet open source devrait se sentir concerne :

Les workflows sont publics par defaut. Sur un depot public GitHub, vos fichiers .github/workflows/ sont visibles par le monde entier. Un attaquant peut analyser votre configuration CI/CD, identifier les triggers dangereux, reperer les secrets references, et construire une attaque sur mesure — sans jamais interagir avec votre depot. La reconnaissance est passive et indetectable.

Selon Wiz, seulement 3,9% des depots epinglent 100% de leurs actions tierces par SHA de commit. Cela signifie que 96% des projets sont vulnerables a une compromission de n'importe quelle action tierce qu'ils utilisent. Si l'action actions/checkout@v4 etait compromise demain (par exemple via un tag mutable pointe vers un commit malveillant), la quasi-totalite de l'ecosysteme serait touchee.

Rappelons qu'en mars 2026, une attaque supply chain via PyPI a touche LiteLLM, volant des credentials developpeur via un paquet malveillant. Le pattern est identique : exploiter la confiance implicite dans la chaine de dependances. Et en mai, l'incident Mini Shai-Hulud sur TanStack npm a compromis 169 paquets et 518 millions de telechargements. La supply chain est le nouveau champ de bataille.

La reponse de Grafana : un modele de gestion de crise

Il faut le dire : la reponse de Grafana Labs a ete exemplaire. Pas de tentative de minimisation, pas de communication evasive. Un post-incident review public, detaille, technique, avec des actions concretes. C'est le standard que tout projet open source devrait viser.

Voici ce que Grafana a mis en place apres la detection :

• Invalidation immediate de tous les credentials compromis.
• Suppression du workflow vulnerable et desactivation de tous les workflows publics.
• Deploiement de Zizmor — un outil d'analyse statique open source developpe par William Woodruff — sur tous les depots pour detecter les workflows vulnerables. Grafana sponsorise desormais le projet.
• Integration de Trufflehog pour scanner les secrets exposes dans l'historique Git.
• Deploiement de Gato-X pour auditer les permissions GitHub Actions.
• Migration des credentials vers des vaults dedies avec separation des privileges.
• Separation de l'organisation GitHub open source des depots prives.
• Deploiement de Semgrep sur tous les depots pour l'analyse statique continue.

Le refus de payer la rancon est egalement un signal fort. En citant les recommandations du FBI, Grafana Labs envoie un message clair : payer alimente l'ecosysteme criminel et ne garantit pas la non-publication des donnees. C'est la posture recommandee par l'ANSSI en France et par l'ENISA au niveau europeen.

Ce que ca signifie pour vous : plan d'action immediat

Vous maintenez un projet open source sur GitHub ? Vous gerez des workflows CI/CD pour votre entreprise ? Voici les six actions a executer cette semaine :

1. Auditez tous vos workflows pour pull_request_target. Une recherche grep -r "pull_request_target" .github/workflows/ suffit. Si vous en trouvez, demandez-vous : ce workflow execute-t-il du code provenant de la PR ? Si oui, c'est une Pwn Request. Remplacez par pull_request ou isolez l'execution du code non fiable.
2. Installez Zizmor (pip install zizmor) et executez-le sur tous vos depots. C'est l'outil que Grafana a adopte post-incident. Il detecte les pull_request_target dangereux, les actions non epinglees, les injections de script, et plus.
3. Epinglez toutes vos actions tierces par SHA de commit. Remplacez actions/checkout@v4 par actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11. Un tag est mutable, un SHA ne l'est pas.
4. Configurez permissions: read-all par defaut dans vos workflows et n'accordez que les permissions specifiques necessaires a chaque job.
5. Deployez des canary tokens dans vos depots prives. C'est ce qui a sauve Grafana. Un fichier piege qui alerte quand il est accede.
6. Activez OIDC pour vos acces cloud au lieu de stocker des cles AWS/GCP/Azure dans les secrets GitHub.

Pour aller plus loin, consultez notre guide detaille configurer un pipeline CI/CD GitHub Actions securise en 7 etapes.

Predictions : ce qui va changer dans les 12 prochains mois

L'incident Grafana va accelerer plusieurs tendances deja en cours dans l'ecosysteme GitHub Actions :

1. GitHub va durcir les defauts de securite. La roadmap securite GitHub Actions 2026 prevoit deja une section dependencies: dans les fichiers YAML de workflow qui verrouillera toutes les dependances directes et transitives par SHA de commit — l'equivalent de go.sum pour vos workflows. C'est une reponse directe a ce type d'incident. On s'attend aussi a ce que pull_request_target soit marque comme « deprecated » ou au minimum affiche un avertissement visible dans l'interface GitHub.

2. Les outils d'audit CI/CD vont exploser. Zizmor, Gato-X, StepSecurity Harden-Runner — ces outils etaient confidentiels il y a six mois. L'incident Grafana va les propulser dans le mainstream. On predit que d'ici fin 2026, les organisations matures auront une etape Zizmor dans leur CI au meme titre qu'un linter ou un scanner de vulnerabilites.

3. Les groupes d'extorsion vont intensifier le ciblage CI/CD. CoinbaseCartel a demontre que c'est plus simple et plus rentable que le ransomware traditionnel. Attendez-vous a ce que d'autres groupes adoptent la meme methode : scan de workflows publics, exploitation de pull_request_target, exfiltration de code source, extorsion. Les projets open source populaires seront les cibles prioritaires.

4. La separation des organisations GitHub va devenir la norme. Grafana a separe son organisation open source de ses depots prives. C'est une pratique que nous recommandons depuis longtemps. Un token compromis dans un depot public ne doit jamais pouvoir acceder aux depots prives. La compartimentation est la base de la defense en profondeur.

Questions frequentes

Conclusion : la securite CI/CD n'est plus optionnelle

L'incident Grafana du 16 mai 2026 est un tournant. Un fichier YAML mal configure, un trigger dangereux, et en quelques minutes, l'integralite du code source d'une entreprise valorisee a plus de 6 milliards de dollars est entre les mains d'un groupe criminel. Pas besoin de zero-day, pas besoin de vulnerabilite inedite. Juste un workflow GitHub Actions avec pull_request_target et un attaquant qui sait lire la documentation.

La bonne nouvelle : les outils existent. Zizmor, Trufflehog, Gato-X, StepSecurity Harden-Runner. La remediation est concrete et faisable en une journee pour la plupart des projets. La question n'est pas technique, elle est organisationnelle : traitez-vous vos workflows CI/CD avec le meme serieux que votre code de production ?

Si la reponse est non, c'est le moment de changer. Avant que CoinbaseCartel — ou le prochain groupe — ne trouve votre pull_request_target avant vous.