RoguePilot : comment des instructions cachées dans les GitHub Issues permettent le détournement de dépôts via Copilot

Une nouvelle classe d’exploitation des outils de développement

La promesse des assistants de codage IA a toujours reposé sur une hypothèse de confiance implicite : que les suggestions de code, les explications et les actions produites par ces outils sont alignées sur l’intention du développeur. GitHub Copilot, l’assistant de codage IA le plus largement adopté avec plus de 20 millions d’utilisateurs cumulés à la mi-2025 et plus de 1,3 million d’abonnés payants, est devenu profondément intégré dans les flux de travail de développement professionnel à travers plus de 50 000 organisations, dont 90 % des entreprises du Fortune 100.

Cette hypothèse de confiance a volé en éclats en février 2026 lorsque le Research Pod d’Orca Security a publié ses conclusions sur « RoguePilot », une classe de vulnérabilité démontrant comment des instructions malveillantes cachées dans les GitHub Issues pouvaient détourner les capacités d’agent de Copilot au sein de GitHub Codespaces, exfiltrer des identifiants GITHUB_TOKEN privilégiés et réaliser la prise de contrôle complète d’un dépôt — le tout sans que le développeur n’effectue d’action explicitement risquée.

Cette découverte représente un moment charnière à l’intersection du développement assisté par l’IA et de la sécurité de la chaîne d’approvisionnement logicielle. Elle prouve que la consommation passive de contenu non fiable — le simple lancement d’un Codespace depuis un GitHub Issue — peut être transformée en vecteur d’attaque actif avec des conséquences graves.

La chaîne d’attaque : du commentaire caché à la prise de contrôle du dépôt

L’attaque RoguePilot exploite une caractéristique fondamentale de la façon dont GitHub Copilot traite le contexte au sein des Codespaces. Lorsqu’un développeur lance un Codespace depuis un GitHub Issue, Copilot ingère automatiquement la description de l’issue comme prompt pour générer une réponse initiale. Ce flux de travail fiable du développeur devient le point d’entrée de l’exploitation.

Étape 1 : implantation de la charge utile

L’attaque commence lorsqu’un adversaire crée ou modifie un GitHub Issue dans un dépôt cible. Les instructions malveillantes sont intégrées dans des balises de commentaire HTML (``) — une syntaxe invisible lors de la visualisation de l’issue via l’interface web de GitHub mais entièrement présente dans le source Markdown brut que Copilot traite.

C’est le coeur de la technique d’injection de prompt passive : la charge utile est invisible pour le développeur humain mais entièrement visible pour l’assistant IA. L’attaquant n’a besoin d’aucune permission spéciale — la création d’issues sur les dépôts publics est ouverte à tous, et les instructions intégrées survivent au pipeline de rendu de GitHub car les commentaires HTML sont du Markdown valide.

Étape 2 : activation de Copilot via le lancement du Codespace

Lorsqu’un développeur lance un Codespace depuis l’issue empoisonnée, Copilot reçoit automatiquement la description de l’issue comme entrée. Les instructions cachées deviennent partie intégrante du contexte opérationnel de Copilot. Parce que les LLM actuels ne peuvent pas distinguer de manière fiable entre les prompts système de confiance et les instructions injectées au sein de leur fenêtre de contexte, les directives malveillantes sont traitées comme des commandes exploitables.

Étape 3 : exploitation des liens symboliques et exfiltration de jetons

L’attaque enchaîne trois techniques distinctes pour réaliser le vol d’identifiants. Premièrement, les instructions injectées dirigent Copilot pour extraire une pull request contrefaite contenant un lien symbolique — un fichier nommé `1.json` qui pointe en réalité vers `/workspaces/.codespaces/shared/user-secrets-envs.json`, un fichier interne contenant le GITHUB_TOKEN privilégié.

Point critique : bien que Copilot dispose de garde-fous qui l’empêchent de suivre directement des liens, il ne valide pas les liens symboliques au sein de la structure du dépôt. Lorsque Copilot lit le fichier lié symboliquement, il accède sans le savoir au fichier de secrets contenant le jeton.

Le mécanisme d’exfiltration exploite une configuration par défaut de VS Code : `json.schemaDownload.enable` est activé par défaut dans les Codespaces. Les instructions injectées dirigent Copilot pour créer un fichier JSON avec une propriété URL `$schema` qui intègre le GITHUB_TOKEN divulgué comme paramètres de requête pointant vers un serveur contrôlé par l’attaquant. Lorsque VS Code récupère automatiquement l’URL du schéma, le jeton est transmis à l’attaquant.

Étape 4 : prise de contrôle du dépôt

Avec le GITHUB_TOKEN exfiltré — qui est généralement limité au dépôt en cours d’utilisation avec un accès en lecture et en écriture — l’attaquant obtient un contrôle programmatique sur le dépôt. Cela peut inclure la publication de code malveillant, la modification des configurations de pipeline CI/CD, l’accès aux secrets stockés et l’altération des artefacts de publication. La démonstration d’Orca Security a réalisé la prise de contrôle complète du dépôt via cette chaîne.

Pourquoi cette attaque est différente

Les attaques par injection de prompt contre les LLM ne sont pas nouvelles — les chercheurs les ont démontrées depuis les premiers jours des déploiements de grands modèles. Mais RoguePilot est qualitativement différente des démonstrations précédentes à plusieurs égards critiques.

Premièrement, l’attaque est entièrement passive du point de vue de la victime. Le développeur n’a pas besoin de copier-coller du code suspect, de cliquer sur un lien malveillant ou d’effectuer une action autre que son comportement de flux de travail normal. Le simple lancement d’un Codespace depuis une issue malveillante suffit à déclencher la chaîne d’attaque. L’attaque ne nécessitait aucun privilège spécial, aucune exécution de code par la victime et aucune ingénierie sociale au-delà de la création d’un GitHub Issue malveillant — la plaçant fermement à la portée d’acteurs de menaces de faible sophistication.

Deuxièmement, l’attaque exploite un outil auquel les développeurs font implicitement confiance et qui opère avec leurs identifiants. Copilot s’exécute au sein de l’environnement Codespace du développeur avec accès aux variables d’environnement qui incluent des jetons d’authentification. Ce n’est pas une escalade de privilèges au sens traditionnel — c’est une exploitation de la confiance où l’assistant IA devient une menace interne involontaire.

Troisièmement, l’attaque enchaîne plusieurs fonctionnalités apparemment anodines — l’analyse des commentaires HTML, la résolution des liens symboliques et le téléchargement automatique de schémas JSON — en un chemin d’exploitation cohérent. Aucune fonctionnalité n’est une vulnérabilité à elle seule, mais leur combinaison crée une chaîne d’attaque létale.

La réponse de GitHub et le correctif

À la suite de la divulgation responsable par le chercheur d’Orca Security Roi Nisimi, GitHub a répondu rapidement et a travaillé avec le Research Pod d’Orca tout au long du processus de remédiation. La vulnérabilité a été corrigée.

Les mesures d’atténuation ont traité les mécanismes spécifiques exploités par RoguePilot : la traversée par lien symbolique qui permettait l’accès aux fichiers de secrets internes, l’ingestion non contrôlée du contenu des commentaires HTML cachés comme prompts de Copilot, et le comportement de téléchargement de schéma par défaut qui permettait l’exfiltration.

Cependant, les chercheurs en sécurité ont noté que ces mesures d’atténuation traitent le vecteur d’attaque spécifique de RoguePilot sans résoudre le problème sous-jacent : les LLM ne peuvent fondamentalement pas distinguer entre instructions et données au sein de leur fenêtre de contexte. L’approche d’assainissement du contenu repose sur la correspondance de motifs pour identifier les tentatives d’injection, ce qui crée une dynamique adversariale de jeu du chat et de la souris où les attaquants peuvent modifier leurs charges utiles pour échapper à la détection.

Cette limitation n’est pas propre à GitHub Copilot. En août 2025, une vulnérabilité critique distincte (CVE-2025-53773) a démontré que la capacité de GitHub Copilot à modifier les fichiers de configuration de projet pouvait être exploitée pour l’exécution de code à distance via l’injection de prompt, créant potentiellement ce que les chercheurs ont appelé des « ZombAIs » — des machines de développement compromises contrôlées par l’IA et intégrées à des botnets. De plus, les chercheurs de Legit Security ont découvert la vulnérabilité « CamoLeak » (CVSS 9.6) dans Copilot Chat, qui permettait l’exfiltration de données de dépôts privés par injection de prompt.

Le risque systémique : l’injection de prompt à travers la chaîne d’outils de développement

RoguePilot n’est pas une vulnérabilité isolée — c’est le symptôme d’un risque systémique qui affecte l’ensemble de la chaîne d’outils de développement assisté par l’IA. À mesure que les assistants de codage IA deviennent plus capables et plus profondément intégrés dans les flux de travail de développement, la surface d’attaque croît proportionnellement.

Considérons la trajectoire des outils de codage IA. Les premières versions offraient une simple complétion de code — une capacité relativement peu risquée car la sortie était toujours revue par le développeur avant utilisation. Les outils de génération actuelle comme Copilot Workspace, Cursor et Windsurf opèrent comme des agents pouvant lire des fichiers, exécuter des commandes terminal, modifier du code dans plusieurs fichiers et interagir avec des services externes. Chacune de ces capacités représente un vecteur d’exploitation potentiel si le raisonnement de l’agent peut être manipulé.

Le problème s’étend au-delà de GitHub Copilot. Trail of Bits a publié une recherche en août 2025 démontrant des attaques par injection de prompt pouvant tromper Copilot pour insérer des portes dérobées malveillantes dans les logiciels open source via des descriptions d’issues soigneusement rédigées. En octobre 2025, ils ont en outre démontré le passage de l’injection de prompt à l’exécution de code à distance sur plusieurs plateformes d’agents IA, révélant des anti-patterns de conception qui permettaient des attaques par injection d’arguments contournant les protections d’approbation humaine.

La chaîne d’outils de développement est particulièrement attrayante pour les attaquants car elle se situe à l’intersection de cibles de haute valeur — code source, identifiants, configurations d’infrastructure — et d’environnements de haute confiance où les développeurs s’attendent à ce que leurs outils travaillent en leur nom. Des paquets npm malveillants ont été découverts dissimulant des charges utiles d’injection de prompt dans les fichiers README et la documentation, ciblant les outils assistés par l’IA qui lisent les métadonnées des paquets. Un environnement de développement compromis peut se propager en cascades dans les déploiements de production, faisant de cela un risque critique pour la chaîne d’approvisionnement.

Défendre le flux de travail de développement assisté par l’IA

La divulgation de RoguePilot a catalysé une conversation plus large sur la sécurisation du développement assisté par l’IA. Plusieurs stratégies défensives ont émergé, bien que le domaine reste naissant.

Restriction de portée et rotation des jetons

La défense la plus immédiatement actionnable est de minimiser les permissions et la durée de vie des jetons accessibles dans les environnements de développement. Le GITHUB_TOKEN devrait être limité aux permissions minimales requises pour la tâche en cours, et les organisations devraient mettre en place des politiques de rotation et d’expiration automatiques. Les jetons d’accès personnels à granularité fine (fine-grained personal access tokens), introduits par GitHub en bêta publique en octobre 2022 et passés en disponibilité générale en mars 2025, devraient remplacer les jetons classiques partout où c’est possible.

Isolation du contexte

Les environnements de développement devraient imposer des limites strictes entre contenu fiable et non fiable. Les assistants IA devraient traiter le contenu externe — issues, documentation, code tiers — dans des contextes sandboxés n’ayant pas accès aux identifiants ou aux ressources sensibles. Les liens symboliques au sein des dépôts devraient être validés pour empêcher la traversée vers des fichiers système internes. C’est architecturalement complexe mais essentiel pour la sécurité à long terme.

Analyse du contenu pour les instructions cachées

Les organisations devraient mettre en place des outils d’analyse qui examinent le contenu brut des issues, des PR et de la documentation à la recherche de charges utiles d’injection cachées — incluant les commentaires HTML, les caractères de largeur nulle, les techniques d’obfuscation Unicode et autres méthodes de contenu invisible. Plusieurs outils ont émergé après RoguePilot spécifiquement à cette fin, dont des scanners open source intégrables dans les pipelines CI/CD.

Validation humaine pour les actions à fort impact

Les assistants de codage IA devraient exiger une confirmation humaine explicite avant d’exécuter des actions ayant des implications significatives en matière de sécurité — notamment l’accès aux identifiants, la modification des configurations CI/CD, la publication de code sur des branches protégées et l’interaction avec des services externes. Le coût en commodité de ces étapes de confirmation est minimal comparé au risque qu’elles atténuent.

Politique organisationnelle et sensibilisation

Les équipes de sécurité doivent mettre à jour leurs modèles de menaces pour tenir compte des outils de développement assistés par l’IA. La recherche de Snyk sur la sécurité du code IA a révélé que plus de 56 % des développeurs signalaient que le code généré par l’IA introduisait parfois ou fréquemment des problèmes de sécurité, mais que seulement 10 % analysaient la majeure partie du code généré par l’IA. Les organisations devraient auditer quels outils sont en usage, quelles permissions ils ont, quel contenu ils traitent et quelles actions ils peuvent effectuer. La formation à la sécurité des développeurs devrait être mise à jour pour couvrir les risques d’injection de prompt dans les outils IA — une catégorie que la plupart des programmes de formation actuels n’abordent pas.

Les implications plus larges

RoguePilot marque un tournant dans la façon dont la communauté de la sécurité pense le développement assisté par l’IA. Les gains de commodité et de productivité des assistants de codage IA sont réels et significatifs — mais ils s’accompagnent d’un profil de risque fondamentalement nouveau auquel les pratiques de sécurité de l’industrie ne se sont pas encore adaptées.

La vulnérabilité soulève également des questions de responsabilité. Lorsqu’un assistant IA, agissant sur des instructions malveillantes cachées, exfiltre des identifiants conduisant à une fuite, qui en porte la responsabilité ? Le développeur qui a utilisé l’outil ? Le fournisseur de l’outil qui n’a pas empêché l’injection ? La plateforme qui a hébergé le contenu malveillant ? Ces questions deviendront de plus en plus urgentes à mesure que le développement assisté par l’IA deviendra la norme plutôt que l’exception.

Pour l’instant, la conclusion pratique est claire : les assistants de codage IA devraient être traités comme des outils puissants mais potentiellement manipulables, nécessitant la même gouvernance de sécurité appliquée à tout autre composant de l’infrastructure de développement. L’ère où on les considérait comme de simples accélérateurs de productivité inoffensifs est révolue.

Sources et lectures complémentaires

• RoguePilot: Exploiting GitHub Copilot for a Repository Takeover — Orca Security
• RoguePilot Flaw in GitHub Codespaces Enabled Copilot to Leak GITHUB_TOKEN — The Hacker News
• GitHub Issues Abused in Copilot Attack Leading to Repository Takeover — SecurityWeek
• Prompt Injection Engineering for Attackers: Exploiting GitHub Copilot — Trail of Bits
• GitHub Token Security Best Practices: Automatic Token Authentication — GitHub Docs
• Introducing Fine-Grained Personal Access Tokens for GitHub — GitHub Blog