Rapport d'incident de sécurité : Compromission de l'action GitHub xygeni-action

Préface

Le 3 mars 2026, Xygeni a détecté une activité suspecte affectant le dépôt utilisé pour publier l'action GitHub xygeni/xygeni-action. Cette activité provenait d'identifiants compromis associés à un jeton de mainteneur et à une application GitHub installée sur le dépôt.

Lors de l'incident, un attaquant a tenté d'introduire du code malveillant dans le dépôt par le biais d'une série de pull requestsCes tentatives ont été bloquées par les règles de protection des branches existantes, empêchant ainsi la fusion du code dans la branche principale du dépôt.

Cependant, l'attaquant a ensuite exploité une autre faille en déplaçant l'étiquette v5 modifiable pour qu'elle référence un élément malveillant. commit créé au cours de la pull request Les workflows référençant xygeni/xygeni-action@v5 pourraient donc récupérer le code compromis sans aucune modification visible de leurs définitions de workflow.

La manipulation de l'étiquette a été identifiée le 9 mars suite à des signalements de la communauté. L'étiquette compromise a été immédiatement retirée et les procédures de réponse aux incidents ont été mises en œuvre.

Notre enquête a permis de déterminer ce qui suit :

• Aucun code malveillant n'a été intégré à la branche principale du dépôt.
• Il n’y a pas de limite de temps pour le tournoi. Cependant, si vous restez inactif pendant une longue période, vous serez déconnecté de BBO et la partie sera perdue. Aucune preuve de compromission de la plateforme SaaS Xygeni ou les données clients.
• La fenêtre d'exposition était limitée aux flux de travail faisant référence à xygeni/xygeni-action@v5 entre 3er mars et 9 mars 2026.
• L'étiquette compromise a été définitivement supprimée et ne sera pas recréée.

Suite à la découverte de la manipulation des étiquettes, Xygeni a mis en œuvre de nombreuses améliorations de sécurité dans ses référentiels et ses processus de publication, notamment :

• Suppression de l'étiquette compromise et instructions de migration vers Références épinglées SHA.
• Application de libération de l'immuabilité à travers les référentiels.
• Renforcement des permissions du dépôt et de l'accès des contributeurs.
• Obligatoire signé cryptographiquement commits pour les responsables de la maintenance.
• Restriction de l'accès en écriture à un groupe limité de responsables de la maintenance et d'administrateurs.

Nous publions ce rapport afin d'assurer la transparence concernant cet incident, de partager les enseignements tirés et de contribuer au renforcement des pratiques de sécurité au sein de l'écosystème GitHub Actions.

Bien que l'attaque ait exploité une vulnérabilité connue de GitHub Actions concernant les étiquettes modifiables, cet incident souligne également l'importance d'une protection complète des dépôts, d'une gestion rigoureuse des identifiants et d'une défense en profondeur. CI/CD .

La transparence et la collaboration sont essentielles pour améliorer la résilience de la chaîne d'approvisionnement logicielle.

Aperçu des incidents

Ce rapport documente l'enquête menée sur un incident de sécurité ayant affecté le public xygeni/xygeni-action Dépôt GitHub Action.

Le 3 mars 2026, un attaquant a utilisé des identifiants compromis associés à l'automatisation du dépôt pour introduire du code malveillant à travers une série de pull request tentatives. La charge utile contenait un implant de commande et de contrôle déguisé en système de télémétrie de scanner.

Les règles de protection des branches du dépôt ont empêché avec succès la fusion du code malveillant dans le dépôt. succursale principaleCependant, l'attaquant a ensuite manipulé le mutable v5 Étiquette, en le redirigeant vers un commit contenant la charge utile injectée. Étant donné que de nombreux flux de travail font référence à GitHub Actions à l'aide d'étiquettes de version majeures, ceci empoisonnement par étiquette flux de travail en aval autorisés référençant xygeni/xygeni-action@v5 récupérer le code compromis sans aucune modification visible de leur configuration de flux de travail.

En tant que fournisseur de software supply chain security outillageXygeni exploite une infrastructure qui s'intègre directement au développement pipelines et CI/CD Les projets dans ce domaine sont fréquemment la cible d'attaques visant à compromettre les outils de développement largement utilisés afin d'atteindre les environnements en aval.

Forum

Phase 1 : Le Malveillant Pull Requests (3 mars, 10h22–10h50 UTC)

Le 3 mars 2026 à 10h22 UTC, un attaquant a lancé une attaque rapide et coordonnée contre le dépôt xygeni-action en utilisant deux identités compromises : le jeton d’accès personnel (PAT) d’un mainteneur et la clé privée d’une application GitHub (xygeni-onboarding-app-dev). Au cours des 28 minutes suivantes, trois pull requests ont été créées et fermées, chacune injectant du code shell obscurci dans action.yml.

L'approche de l'attaquant était méthodique et adaptative :

• RP #46 (10:22–10:29 UTC) : Créé par le responsable de la maintenance compromis PAT sous la branche fonction/scanner-télémétrieL'attaquant a tenté une fusion, mais a été bloqué par les règles de protection des branches. La demande de tirage a été fermée sans fusion.
• Reconnaissance (10:39–10:40 UTC) : L’attaquant a testé l’accès à l’application GitHub en créant puis en supprimant immédiatement une branche nommée accès à l'application de testCela a confirmé que l'application disposait d'un accès en écriture au référentiel.
• RP #47 (10:41–10:44 UTC) : Une deuxième tentative utilisant le PAT du responsable de la maintenance, maintenant sous une branche renommée amélioration/télémétrie du scannerNouvelle tentative bloquée par la protection des branches. L'attaquant a essayé d'utiliser l'application GitHub pour approuver la demande de tirage, contournant ainsi l'exigence de deux relecteurs : une identité compromise a approuvé le travail de l'autre. Cette tentative a également échoué.
• RP #48 (10:45–10:49 UTC) : Les rôles ont été inversés — l'application GitHub a créé la PR (envoi) commit 4bf1d4e), et le responsable de la maintenance, PAT, a soumis la demande d'approbation. Celle-ci a également été rejetée par la protection des branches.

Aucune des demandes de fusion n'a été intégrée à la branche principale. Nos règles de protection des branches ont été appliquées : l'exigence de deux approbations, la règle stipulant que la dernière modification doit être approuvée par une personne autre que l'auteur de la demande, et l'interdiction de contourner ces paramètres, l'ensemble de ces mesures bloquant ainsi toute tentative de fusion.

Notre équipe a détecté l'activité anormale lors d'une revue de routine des demandes de fusion et a déclenché une procédure de réponse à l'incident à 12h21 UTC, soit moins de deux heures après la première demande de fusion malveillante. Cette réponse a consisté à supprimer les flux de travail, à préserver le code malveillant pour analyse forensique et à sécuriser le dépôt.

Phase 2 : L'empoisonnement par étiquette

Bien que la protection des branches ait empêché le code malveillant d'atteindre la branche principale, l'attaquant a exploité une autre faille. À l'aide des identifiants compromis de l'application GitHub, il a déplacé l'étiquette v5 modifiable pour pointer vers commit 4bf1d4e — le malicieux commit de la PR #48 qui existait encore dans le magasin d'objets du dépôt même après la suppression de la branche PR.

Point crucial, cette manipulation d'étiquette n'a pas eu lieu immédiatement après les demandes de tirage. Les journaux d'activité des dépôts GitHub ne font pas apparaître les modifications forcées d'étiquettes de la même manière que les opérations sur les branches, ce qui limite la possibilité de reconstituer l'horodatage exact de la modification. Cependant, l'étiquette a été confirmée comme corrompue lorsque la communauté a donné l'alerte le 9 mars.

Voici l'information essentielle : les règles de protection des branches ne protègent pas les étiquettes. commit Une porte dérobée était présente dans la base de données d'objets Git du dépôt, et l'étiquette v5 — référencée par les flux de travail en aval — pouvait y être redirigée silencieusement. Tout flux de travail utilisant xygeni/xygeni-action@v5 extrairait le code compromis, sans qu'aucune modification ne soit visible dans la branche principale ni dans les fichiers de flux de travail des dépôts consommateurs.

Cause première

Notre enquête a conclu que la cause première était la compromission de la clé privée d'une application GitHub (xygeni-onboarding-app-dev) qui avait été installée sur le dépôt.

Cette application GitHub a été initialement créée pour tester l'expérience d'intégration sur la plateforme Xygeni. Elle disposait de droits d'écriture sur le dépôt — des droits qui, avec le recul, étaient plus étendus que nécessaire pour l'usage prévu.

Avec la clé privée d'une application GitHub, un attaquant peut :

• Générez à volonté des jetons d'installation éphémères
• Créer et approuver pull requests
• Push commits via Git sur HTTPS
• Déplacer les étiquettes — l'action cruciale qui a donné à cet incident tout son impact

L'attaquant a utilisé à la fois le jeton d'accès personnel (PAT) compromis du responsable de la maintenance et les identifiants de l'application GitHub dans une tentative coordonnée : lorsqu'une seule identité n'a pas pu contourner les protections, les deux identités ont été utilisées en tandem — l'une pour créer, l'autre pour approuver.

Le vecteur exact d'exfiltration de la clé privée fait toujours l'objet d'une enquête. Les clés privées des applications GitHub (fichiers .pem) peuvent fuiter en raison de flux de travail mal configurés, de machines de développeurs compromises ou d'un stockage de secrets non sécurisé.

Comportement malveillant de la charge utile

Le code injecté était un implant de commande et de contrôle compact. Il était conçu pour fonctionner silencieusement en parallèle du scanner légitime, en s'exécutant en trois phases :

• Enregistrement. L'implant contacte un serveur C2 à l'adresse 91.214.78.178 (déguisé via un DNS générique nip.io sous le nom security-verify.91.214.78.178.nip.io), en envoyant le nom d'hôte, le nom d'utilisateur et la version du système d'exploitation du runner.
• Boucle d'interrogation. Pendant 180 secondes (correspondant aux délais d'expiration typiques des tâches CI), l'implant interroge le serveur C2 toutes les 2 à 7 secondes pour obtenir des commandes à exécuter.
• Exécution des commandes. Toutes les commandes reçues sont exécutées via eval, la sortie étant compressée (zlib), encodée en base64 et exfiltrée vers le serveur C2.

avalées silencieusement, les noms des variables étaient délibérément concis et l'intervalle d'interrogation était aléatoire pour éviter la détection des schémas de trafic.

Si le programme malveillant s'exécutait sur un exécuteur d'intégration continue (CI), l'attaquant aurait eu accès au jeton GitHub, aux secrets du dépôt, au code source et potentiellement aux clés de signature des artefacts. Il aurait également permis l'exécution de commandes sur cet exécuteur s'il avait été lancé dans un flux de travail faisant référence à l'étiquette compromise.

A ce moment, nous avons Aucune preuve que la charge utile ait été exécutée dans un environnement CI client. ou que des secrets aient été exfiltrés grâce à cette opération.

Infrastructure C2

Le serveur C2 était hébergé chez Partner Hosting LTD (AS215826), dont l'adresse de domiciliation est 71-75 Shelton Street, Covent Garden, Londres – une adresse de bureau virtuel couramment utilisée. L'infrastructure était récente (le sous-réseau avait été modifié pour la dernière fois seulement 5 jours avant l'attaque) et l'adresse IP était déjà associée à des RAT, des voleurs d'informations et des chargeurs dans les flux de renseignements sur les menaces. L'infrastructure et les outils utilisés indiquent qu'un attaquant compétent connaît bien les techniques employées. CI/CD environnements.

Évaluation de l'exposition

Observations clés

Les étiquettes modifiables représentent un risque connu, mais l'inertie est puissante.

L'écosystème GitHub Actions présente un problème bien connu : les étiquettes modifiables. Lorsqu'un utilisateur fait référence à une action (@v5), il part du principe que l'étiquette pointe vers du code sûr. Or, toute personne disposant d'un accès en écriture peut modifier de force une étiquette. Il s'agit du principal vecteur d'attaque de la chaîne d'approvisionnement de GitHub Actions, et nous le savions ; pourtant, notre documentation continuait de diriger les utilisateurs vers @v5.

La protection des branches n'est pas une protection des étiquettes

Nos règles de protection des branches ont fonctionné exactement comme prévu. Elles ont empêché la fusion du code malveillant dans la branche principale. Mais l'attaquant n'avait pas besoin de fusionner ; il lui suffisait d'un commit dans le dépôt (que toute branche de demande de tirage fournit) et la possibilité de déplacer une étiquette. La protection des branches nous donnait une fausse impression de sécurité totale.

Les nouvelles fonctionnalités ne protègent pas rétroactivement

GitHub a introduit libération de l'immuabilité En octobre 2025, une fonctionnalité empêchant la modification des étiquettes associées aux versions a été ajoutée. Nous l'avions anticipée, mais nous n'en avions pas pleinement saisi les implications.

• Il protège uniquement les étiquettes associées aux versions GitHub, et non les étiquettes autonomes.
• Elle n'est pas rétroactive : les versions existantes créées avant l'activation de cette fonctionnalité restent modifiables.
• Les règles de protection des étiquettes (une fonctionnalité distincte) doivent être configurées indépendamment.

Si nous avions activé l'immuabilité des versions et veillé à ce que l'étiquette v5 soit associée à une version protégée, l'empoisonnement de l'étiquette aurait échoué.

Des portées d'application GitHub trop permissives

L'application GitHub disposait de droits d'écriture supérieurs à ses besoins opérationnels. Dans une organisation complexe comportant de nombreuses applications, bots et intégrations, il est facile que les autorisations s'accumulent au-delà des exigences. Chaque autorisation supplémentaire représente une surface d'attaque supplémentaire.

Corrections au registre public

Le rapport des chercheurs a joué un rôle déterminant pour alerter la communauté, et nous apprécions leur réactivité. Cependant, notre enquête interne a révélé certains détails qui diffèrent de leur version des faits :

• Chronologie de l'empoisonnement par étiquetteLe rapport du chercheur situe le déplacement de l'étiquette v5 aux alentours de 10h49 UTC le 3 mars, immédiatement après la fermeture des demandes de tirage. Notre enquête n'a pas permis de confirmer cet horaire : les opérations de force de modification d'étiquettes ne sont pas enregistrées dans le journal d'activité des dépôts GitHub. Nous savons toutefois que l'étiquette a été corrompue à un moment donné après l'action malveillante. commit a été créé avant que la communauté ne le découvre le 9 mars.
• Le commit n'a pas été « signé avec l'adresse électronique d'un responsable de la maintenance ». Le rapport du chercheur décrit le premier acte malveillant commit comme « signé avec l'adresse e-mail d'un responsable de maintenance », mais cela confond les métadonnées d'auteur Git avec la signature cryptographique — ce sont des choses fondamentalement différentes. commit n'était pas signé cryptographiquement. L'attaquant a simplement modifié le champ auteur Git en y indiquant l'adresse e-mail d'un autre mainteneur — une opération que n'importe qui peut effectuer, car les métadonnées d'auteur Git sont autodéclarées et non authentifiées. commit a été envoyé à l'aide du jeton d'accès personnel (PAT) compromis du responsable de la maintenance ; le responsable de la maintenance dont l'adresse électronique a été utilisée n'a pas été compromise et n'apparaît dans le journal d'activité du dépôt qu'à partir de 12 h 21 UTC en tant que membre de l'équipe de réponse aux incidents.
• Les identités impliquéesLe chercheur a décrit l'identité du responsable de la maintenance et le bot de l'application GitHub comme des preuves d'« identifiants volés plutôt que d'une action interne ». Nous pouvons confirmer que le jeton d'accès personnel (PAT) classique du responsable de la maintenance et la clé privée de l'application GitHub ont été compromis. Les deux ont été utilisés par le même attaquant externe. La demande de tirage n° 48 apparaît sous un utilisateur fantôme car elle a été créée par l'installation de l'application GitHub, et non par un compte humain supprimé.
• Le nombre de dépôts concernésLe rapport du chercheur mentionnait plus de 137 dépôts utilisant @v5. Notre analyse des résultats de recherche de code sur GitHub n'a pas confirmé ce chiffre. Lors de notre dernière analyse, nous n'avons trouvé aucun dépôt public utilisant activement xygeni/xygeni-action@v5 dans des flux de travail exécutables. Les références identifiées correspondaient à des exemples de documentation dans les dépôts Xygeni, qui ont depuis été mis à jour. En pratique, la plupart des clients utilisent le téléchargement du scanner via l'interface de ligne de commande et la fonctionnalité d'analyse gérée de Xygeni, qui invoque l'action en interne et utilise une version validée en interne avec un SHA épinglé, non affectée par la manipulation des étiquettes. Étant donné que la recherche de code sur GitHub n'indexe que les dépôts publics, nous ne pouvons pas déterminer avec certitude si des dépôts privés ont pu référencer l'étiquette. D'après les informations disponibles, l'exposition réelle en aval semble être nettement inférieure à celle initialement rapportée.

[Cette section sera mise à jour au fur et à mesure que notre enquête progressera.]

Actions de réponse

Réponse immédiate (3 mars)

• Les demandes de fusion malveillantes ont été signalées et bloquées (la protection des branches a empêché la fusion).
• Le code malveillant a été extrait et conservé pour analyse forensique.
• Le domaine et l'adresse IP du serveur C2 ont été enregistrés comme indicateurs de compromission.
• L'application GitHub compromise (xygeni-onboarding-app-dev) a été supprimée du dépôt.
• Tous les PAT des contributeurs ont été mis en rotation.
• Les journaux d'audit du dépôt ont été examinés ; aucune preuve de fusions non autorisées antérieures n'a été trouvée.

Conseils de remédiation

Mesures correctives (9-10 mars)

• L'étiquette v5 compromise a été supprimée.
• immuabilité de la libération a été activé pour le dépôt et appliqué globalement à tous les dépôts appartenant à Xygeni
• Les règles de protection des succursales ont été renforcées, notamment par l'obligation de signature. commits (Xygeni utilise du matériel commit (signature)
• L'étiquette v5 n'a pas été recréée intentionnellement, afin de bien montrer qu'elle avait été compromise et d'encourager la migration vers des références SHA-épinglées.
• La documentation a été mise à jour pour faire référence à l'intégralité commit SHA (13c6ed2797df7d85749864e2cbcf09c893f43b23) correspondant à la version 6.4.0
• Les actions GitHub ont été temporairement désactivées sur le dépôt par mesure de précaution.
• Les autorisations d'écriture étaient restreintes : seuls deux responsables désignés et deux administrateurs de dépôt conservaient l'accès en écriture.

Pour les utilisateurs de xygeni-action

Si vous utilisiez xygeni/xygeni-action@v5, vous devriez :

• Mise à jour immédiate votre flux de travail à épingler au coffre-fort commit SHA :

uses: xygeni/xygeni-action@13c6ed2797df7d85749864e2cbcf09c893f43b23

• Auditez vos journaux CI pour toute connexion sortante vers 91.214.78.178 ou security-verify.91.214.78.178.nip.io pendant la période comprise entre le 3 et le 9 mars 2026.
• Faites tourner tous les secrets qui ont été exposés aux coureurs CI pendant cette période.
• Vous pouvez également utiliser un Téléchargement et vérification directs du scanner

Pourquoi nous n'avons pas fait de déclaration publique le 3 mars

C'est une question à laquelle nous devons une réponse honnête.

Le 3 mars, lorsque notre équipe a réagi aux demandes de fusion malveillantes, l'évaluation a conclu que l'attaque avait été entièrement contenue au stade des demandes de fusion. Les règles de protection des branches ont fonctionné correctement. Aucun code malveillant n'a été fusionné dans la branche principale. Aucun exécuteur d'intégration continue n'a exécuté la charge utile. Le jeton d'accès personnel compromis a été remplacé, l'application GitHub a été supprimée et les journaux d'audit du dépôt n'ont révélé aucune trace de fusions non autorisées antérieures. L'incident a été classé comme étant de gravité moyenne (P2) — une tentative d'intrusion bloquée.

Sur la base de cette évaluation, aucune divulgation publique n'a été jugée nécessaire. Rétrospectivement, cette évaluation était incomplète.

Ce qui nous a échappé, c'est l'empoisonnement de l'étiquette. L'étiquette v5 avait été discrètement déplacée pour pointer vers le dispositif malveillant. commitmais cela n'était pas visible dans les mêmes journaux d'audit que nous examinions. Les journaux d'activité des dépôts GitHub présentent les modifications d'étiquettes différemment des opérations sur les branches, ce qui a rendu la modification moins visible lors de l'enquête initiale. Notre réponse à l'incident s'est concentrée sur le vecteur d'attaque visible — le pull requests et la branche principale — et n'a pas vérifié si les étiquettes avaient été altérées.

Avec le recul, c'est là l'un des principaux enseignements de cet incident : on ne peut divulguer ce que l'on ignore. Notre réaction du 3 mars a été rapide et efficace face à la menace visible. Mais l'attaquant disposait d'un second vecteur, plus furtif, qui est resté indétecté pendant six jours, jusqu'à ce que la communauté le découvre.

Divulgation publique (9 mars)

Le 9 mars 2026, des membres de la communauté ont ouvert un débat. #54Des chercheurs ont remis en question le code malveillant et l'étiquette v5 compromise. Ils ont publié une analyse détaillée qui a contribué à sensibiliser l'ensemble de l'écosystème.

Nous tenons à souligner le rôle du chercheur dans la diffusion de l'alerte et la fourniture de conseils pratiques aux utilisateurs concernés. Nous souhaitons également clarifier certains points de son rapport, sur lesquels notre enquête interne a abouti à des conclusions différentes ; ces points sont abordés dans la section « Corrections ».

Leçons pour l'écosystème

• Actions d'épinglage par SHA, et non par étiquetteLes étiquettes modifiables représentent la principale surface d'attaque de l'écosystème GitHub Actions. action@ dans tous les flux de production.
• Comprendre les limites de chaque fonction de sécuritéLa protection des branches protège les branches. La protection des étiquettes protège les étiquettes. L'immuabilité des versions protège les versions. Ces protections ne sont pas interchangeables, et les failles entre elles constituent précisément le terrain d'action des attaquants.
• Vérifiez sans relâche les autorisations des applications GitHub.Chaque application installée disposant d'un accès en écriture représente un vecteur potentiel de déplacement latéral. Appliquez le principe du moindre privilège, alternez les clés de chiffrement et vérifiez régulièrement les applications installées sur les répertoires critiques.
• Considérez les exécuteurs CI comme des environnements hostilesLa surveillance du trafic sortant du réseau, les processus éphémères et l'isolation des secrets ne sont pas optionnels pour les référentiels dans la chaîne d'approvisionnement logicielle.
• Les nouvelles fonctionnalités de sécurité nécessitent une adoption proactiveL'immuabilité des versions de GitHub était disponible depuis des mois avant cet incident. Les fonctionnalités désactivées n'offrent aucune protection : la sécurité n'est pas activée par défaut.
• Non signé commitLes individus peuvent avoir de fausses identités.. Git commit auteur et commitLes champs ter sont auto-déclarés — n'importe qui peut leur attribuer n'importe quelle valeur. Sans chiffrement commit avec la signature (GPG, SSH ou S/MIME), il n'y a aucune garantie qu'un commit L'auteur du message était en réalité la personne qui prétendait l'être. Dans cet incident, l'attaquant a désigné l'auteur du premier message malveillant. commit à l'adresse électronique d'un autre responsable, créant ainsi une fausse attribution. Nécessite une signature. commitLes règles de protection des branches éliminent ce vecteur.
• La complexité augmente la surface d'attaque.L'interaction entre les jetons d'accès personnels (PAT), les applications GitHub, les règles de protection des branches, la sémantique des étiquettes et l'immuabilité des versions a créé un environnement où l'attaquant a trouvé des failles qu'aucune de ces fonctionnalités ne couvrait individuellement. Simplifiez autant que possible. Comprenez l'ensemble du modèle de menace, même lorsque cela s'avère impossible.

Indicateurs de compromission (IOC)