En bref

  • Un attaquant a exploité une GitHub Action mal configurée (vulnérabilité Pwn Request) pour dérober le code source privé de Grafana Labs le 16 mai 2026.
  • L'attaque a ciblé les pipelines CI/CD de la plateforme d'observabilité open source utilisée par des millions d'équipes dans le monde.
  • Grafana Labs a refusé de payer la rançon et a publié un post-mortem complet. Aucune donnée client n'a été compromise.

Comment l'attaquant a pris le contrôle du pipeline CI/CD

Grafana Labs a divulgué le 16 mai 2026 une violation de sécurité significative : un acteur malveillant a obtenu un jeton d'accès privilégié qui lui a permis de pénétrer dans l'environnement GitHub de la société et de télécharger l'intégralité de plusieurs dépôts de code source privés. L'incident s'est conclu par une tentative d'extorsion que la société a catégoriquement refusé de payer. Il met en lumière une classe de vulnérabilités particulièrement insidieuse affectant les pipelines d'intégration continue : les attaques dites Pwn Request.

Tout a commencé par l'activation récente d'une GitHub Action mal configurée dans l'un des dépôts publics de Grafana Labs. Cette action utilisait l'événement déclencheur pull_request_target, une subtilité du système de gestion des workflows de GitHub qui accorde, par conception, un accès aux secrets de production même lorsque la pull request provient d'un fork externe. Cette caractéristique, documentée par GitHub mais souvent mal comprise des équipes DevOps, crée une surface d'attaque connue sous le nom de Pwn Request : un contributeur extérieur peut soumettre une pull request contenant du code malveillant qui s'exécutera dans le contexte sécurisé du dépôt cible, avec accès à ses variables d'environnement et ses secrets CI/CD.

L'attaquant a exploité cette faille avec méthode. Il a d'abord forké un dépôt public de Grafana Labs, puis injecté dans le workflow une commande curl destinée à exfiltrer les variables d'environnement en les chiffrant avec une clé privée sous son contrôle. Les variables d'environnement concernées incluaient des jetons GitHub à hauts privilèges. Pour brouiller les pistes, l'auteur a supprimé son fork immédiatement après l'exfiltration. Armé du token volé, il a ensuite procédé de façon méthodique pour répliquer l'attaque contre quatre dépôts privés supplémentaires de Grafana Labs, téléchargeant au passage l'ensemble du code source accessible.

C'est l'infrastructure de détection préventive de Grafana qui a mis fin à l'intrusion. La société déploie en effet des milliers de canary tokens — des jetons ou références semblant légitimes mais dont le moindre usage déclenche immédiatement une alerte côté défenseur. L'un de ces leurres a été activé par l'attaquant lors de l'accès aux dépôts privés, alertant instantanément l'équipe de sécurité mondiale de Grafana Labs. La réponse a été rapide et coordonnée : les credentials compromis ont été invalidés, la GitHub Action vulnérable a été supprimée, et tous les workflows des dépôts publics ont été temporairement désactivés le temps d'un audit complet des pipelines.

Après avoir téléchargé le code source privé, l'attaquant a tenté de monétiser son accès en se livrant à une extorsion : il a contacté Grafana Labs pour exiger un paiement en échange de la non-divulgation publique du code volé. Grafana Labs a refusé catégoriquement, citant explicitement les recommandations du FBI selon lesquelles payer une rançon ne garantit pas que vous récupérerez des données et que cela offre un incitatif à d'autres de s'impliquer dans ce type d'activité illégale. La position publique de l'entreprise est sans équivoque : elle ne cèdera pas au chantage.

L'investigation post-incident a confirmé que les clients n'ont pas été directement affectés. Aucune donnée client, aucune information personnelle identifiable, et aucun secret d'infrastructure de production n'ont été compromis lors de cet incident. Le code source téléchargé concernait des dépôts privés internes, mais pas les systèmes hébergeant les données des utilisateurs de Grafana Cloud. La société a mené une revue exhaustive de l'ensemble des accès et des secrets potentiellement exposés pour écarter tout risque résiduel.

Grafana Labs a publié un post-mortem détaillé sur son blog officiel, décrivant la chronologie complète de l'attaque, les mécanismes exploités, et les mesures correctives déployées. Parmi celles-ci figurent le renforcement des règles de vérification des pull requests externes, l'adoption des recommandations de StepSecurity pour la sécurisation des GitHub Actions, et l'audit systématique de tous les workflows CI/CD. La société a également renforcé ses procédures de rotation des secrets et étendu son réseau de canary tokens.

Cet incident survient dans un contexte de sensibilisation croissante aux risques liés aux pipelines CI/CD. StepSecurity avait publié dès 2023 des analyses approfondies sur les attaques de type Pwn Request, et plusieurs incidents similaires avaient touché d'autres projets open source majeurs. Selon les chercheurs de cette société, ce pattern de misconfiguration reste largement répandu dans des milliers de dépôts publics populaires. Le cas Grafana illustre que même des entreprises ayant investi dans des mécanismes de détection sophistiqués peuvent être ciblées, mais qu'une réponse préparée et rapide peut limiter considérablement l'impact final.

Pourquoi les pipelines CI/CD sont devenus la frontière critique de la sécurité

L'incident Grafana s'inscrit dans une tendance alarmante touchant l'ensemble de l'écosystème DevOps : la compromission des pipelines CI/CD comme vecteur d'attaque principal contre la chaîne d'approvisionnement logicielle. En 2025 et 2026, plusieurs incidents de grande envergure ont démontré que les environnements de build constituent un point d'entrée privilégié pour des attaquants cherchant à atteindre des cibles en aval à grande échelle. Un attaquant qui compromet le pipeline d'une bibliothèque ou d'un outil largement distribué peut potentiellement infecter des millions de systèmes sans jamais attaquer directement les victimes finales.

La vulnérabilité de type Pwn Request illustre parfaitement les défis de sécurité propres aux environnements open source. Par nature, ces projets doivent accepter des contributions extérieures, ce qui crée une tension fondamentale entre ouverture et sécurité. GitHub a documenté ce risque et fourni des recommandations pour l'atténuer, mais la complexité des configurations de workflow fait que de nombreuses équipes reproduisent involontairement ce pattern dangereux. La surface d'attaque est considérable : les GitHub Actions sont omniprésentes dans l'écosystème open source moderne.

Pour les entreprises utilisatrices de Grafana — l'outil étant déployé dans la majorité des environnements cloud modernes pour le monitoring et l'observabilité — cet incident rappelle l'importance d'une stratégie de sécurité en profondeur qui ne repose pas uniquement sur la confiance accordée aux fournisseurs de logiciels tiers. Les principes de Zero Trust s'appliquent aussi aux outils de monitoring. La transparence dont Grafana Labs a fait preuve en publiant un post-mortem complet, en refusant de payer et en communiquant immédiatement, constitue un modèle de gestion de crise que la communauté de la sécurité salue unanimement.

La tentative d'extorsion qui a suivi le vol représente une évolution préoccupante des tactiques cybercriminelles. Traditionnellement associée aux ransomwares ciblant les données opérationnelles, l'extorsion s'étend désormais au code source propriétaire. La valeur d'un tel code est double : il peut révéler des vulnérabilités exploitables dans les produits commerciaux, et sa publication non autorisée peut causer un préjudice commercial et réputationnel considérable. Face à cette menace émergente, disposer d'une politique de non-paiement documentée et validée par la direction avant qu'un incident ne survienne est devenu une nécessité organisationnelle.

Ce qu'il faut retenir

  • L'événement déclencheur pull_request_target dans GitHub Actions expose les secrets CI/CD aux forks externes : toute organisation utilisant ce pattern doit auditer ses workflows immédiatement.
  • Les canary tokens ont permis à Grafana de détecter l'intrusion en temps réel, illustrant la valeur des mécanismes de détection trompeurs (deception technology) dans une stratégie de défense en profondeur.
  • Refuser de payer en cas d'extorsion liée au code source, communiquer de façon transparente et publier un post-mortem détaillé : les réponses de Grafana Labs constituent un modèle à suivre pour toute organisation.

Comment vérifier si mes GitHub Actions sont vulnérables à une attaque Pwn Request ?

Auditez tous vos workflows déclenchés par l'événement pull_request_target et vérifiez s'ils accèdent à des secrets ou effectuent des opérations privilégiées. Les outils de StepSecurity (action-security et harden-runner) permettent de scanner automatiquement vos dépôts GitHub à la recherche de ce pattern dangereux. En règle générale, préférez l'événement pull_request (sans _target) qui s'exécute dans un contexte isolé sans accès aux secrets.

Besoin d'un accompagnement expert ?

Ayi NEDJIMI vous accompagne sur vos projets cybersécurité et IA.

Prendre contact