Une vulnérabilité critique de GitHub Copilot Chat (CVSS 9,6) permettait à des attaquants d’aspirer des secrets et du code source depuis des dépôts privés, et même de guider les réponses de Copilot au moyen d’instructions malveillantes.
GitHub a déjà publié un correctif pour cette vulnérabilité.
En identifiant la fuite, le chercheur en sécurité Omer Mayraz a déclaré que la vulnérabilité « … permettait l’exfiltration furtive de secrets et de code source depuis des dépôts privés ».
Quand l’assistance devient dangereuse
Copilot Chat s’exécute avec les autorisations de l’utilisateur qui pose les questions.
Cela signifie qu’une injection de prompt réussie peut lire des dépôts privés, suggérer du code compromis et faire fuiter des données, sans déclencher les contrôles traditionnels du trafic sortant.
Pour les organisations logicielles qui adoptent des assistants IA pour la revue de code et le triage des demandes de fusion, il s’agit d’un risque direct pour la propriété intellectuelle et les identifiants cloud.
Au cœur de l’attaque
L’attaque a commencé par la dissimulation d’un prompt contrôlé par l’attaquant dans la description d’une demande de fusion, à l’aide de la fonctionnalité de « commentaires invisibles » de GitHub.
Bien que ce contenu ne soit pas visible dans l’interface utilisateur normale, Copilot Chat ingère tout de même le contexte du dépôt et de la demande de fusion (y compris les métadonnées masquées) lors de la génération de ses réponses.
Comme Copilot répond en utilisant les autorisations de l’utilisateur qui l’interroge, toute instruction intégrée à ce contexte invisible pouvait influencer le comportement de l’assistant pour n’importe quel développeur ayant ouvert la demande de fusion ou interrogé Copilot à son sujet.
En bref, un attaquant pouvait influencer les réponses de l’assistant destinées à d’autres utilisateurs sans que ceux-ci ne voient jamais le texte malveillant.
Accès aux données
Copilot tient compte du contexte et fonctionne avec les privilèges de la personne qui l’utilise. Il peut donc accéder au contenu de dépôts privés lorsqu’un utilisateur autorisé lui demande de l’aide.
L’attaque exploitait ce modèle de privilèges : le prompt injecté demandait à Copilot de rechercher des éléments sensibles (par exemple des clés ou des descriptions de vulnérabilités) dans les dépôts accessibles à la victime, puis d’intégrer ces informations à sa sortie ou de les encoder afin de pouvoir les exfiltrer.
Contourner le proxy Camo
La fuite directe de données vers un domaine externe arbitraire au moyen d’une balise <img> ou d’un script standard est généralement bloquée par la politique de sécurité du contenu (CSP) de GitHub.
GitHub atténue le risque lié à l’inclusion d’images tierces en acheminant les requêtes d’images externes via un proxy Camo : lorsqu’un contenu Markdown ou autre contenu de dépôt référence une image externe, GitHub réécrit l’URL de l’image en une URL camo.githubusercontent.com qui inclut une signature cryptographique.
Le service Camo ne récupère le contenu en amont que lorsque l’URL signée est validée comme provenant de GitHub, ce qui empêche les attaquants de créer librement des adresses forçant un navigateur à contacter un serveur qu’ils contrôlent.
Plutôt que de tenter de publier directement des URL externes arbitraires, l’attaquant avait préparé un ensemble d’URL de proxy pré-signées que GitHub accepterait.
Chaque URL pré-signée pointait vers un pixel transparent 1×1 inoffensif, hébergé sur une infrastructure contrôlée par l’attaquant.
En constituant un dictionnaire de telles URL de proxy signées — une par caractère ou symbole que l’attaquant prévoyait d’utiliser — l’adversaire a créé des briques pouvant être combinées en séquence dans la sortie générée par Copilot.
Encoder les données
Le prompt injecté contraignait Copilot à produire une sortie référençant les URL de proxy pré-signées dans un ordre particulier, afin d’encoder le contenu du dépôt.
En substance, Copilot « dessinait » du texte en émettant un flux de références d’images ; lorsque le navigateur de la victime affichait la réponse de l’assistant, il récupérait les images via le proxy Camo de GitHub.
Comme chaque récupération via le proxy aboutissait finalement sur l’hébergement de l’attaquant, le schéma et l’ordre des requêtes transmettaient effectivement les données volées à l’attaquant — une petite requête par caractère — sans laisser de données dans les journaux de serveur classiques ni dans des éléments visibles de l’interface.
Technique d’évasion
Pour éviter la mise en cache et faire en sorte que chaque récupération corresponde à des données fraîches, les attaquants ajoutaient des paramètres de requête éphémères aux URL pré-signées afin que chaque requête soit récupérée plutôt que servie depuis le cache.
L’utilisation de fragments d’URL ou de lectures côté client plutôt que de paramètres de requête classiques réduisait encore le risque de voir le contenu exfiltré apparaître dans les journaux d’accès traditionnels des serveurs, car les fragments sont traités au niveau du client (le navigateur) et non envoyés à l’origine dans les requêtes HTTP.
La technique combinait plusieurs failles défensives : l’ingestion par Copilot du contexte masqué du dépôt, les privilèges d’exécution de l’assistant, la réécriture par un CDN ou un proxy de confiance (qui faisait ressembler les requêtes à une activité GitHub normale) et la propension du navigateur à récupérer de nombreuses petites ressources invisibles.
Ensemble, ces éléments produisaient un canal discret capable d’exfiltrer du contenu sensible sans afficher de sortie manifestement malveillante au développeur.
Réduire les risques des attaques assistées par l’IA
Pour réduire le risque de vulnérabilités similaires assistées par l’IA, les organisations devraient adopter une approche à plusieurs niveaux combinant contrôle des accès, protection des identités, supervision et formation des développeurs.
- Restreindre les accès et les autorisations : Limitez l’utilisation de Copilot aux équipes et dépôts nécessaires, appliquez le principe du moindre privilège, et désactivez les fonctionnalités non vérifiées comme le rendu d’images ou de HTML.
- Renforcer la gestion des identités et des secrets : Imposez l’authentification multifacteur, faites régulièrement tourner les secrets et surveillez les accès non autorisés ou l’utilisation abusive de clés.
- Superviser, détecter et réagir : Suivez l’activité de Copilot, examinez les anomalies et intégrez les scénarios de compromission de l’IA à vos plans de réponse aux incidents.
- Formez les développeurs et sécurisez les processus de travail des développeurs : Apprenez aux développeurs à considérer le contenu des demandes de fusion comme non fiable, à vérifier le code généré par l’IA et à bloquer le rendu externe non vérifié.
Ensemble, ces mesures aident les organisations à réduire leur exposition, à renforcer leur supervision et à garantir que le développement assisté par l’IA reste à la fois innovant et sécurisé.
Quand l’IA devient une surface d’attaque
CamoLeak illustre une évolution plus large : à mesure que les outils d’IA fusionnent avec les plateformes de développement, le contexte devient une surface d’attaque.
Des contrôles autrefois limités au rendu Markdown ou aux proxys d’images peuvent devenir des canaux d’exfiltration de données lorsqu’ils sont orchestrés par un agent.
Les entreprises devraient évaluer les assistants IA comme n’importe quelle intégration privilégiée — cartographier les flux de données, limiter les capacités (en particulier l’utilisation d’outils et le rendu) et donner la priorité aux mesures d’atténuation rapides pilotées par les fournisseurs.
À mesure que les plateformes d’IA évoluent, même des fonctionnalités de présentation apparemment limitées peuvent devenir des vecteurs de compromission à fort impact si elles ne sont pas rapidement verrouillées.
L’IA continue de brouiller la frontière entre automatisation de confiance et menace potentielle. En effet, les mêmes technologies qui améliorent la productivité des développeurs alimentent aussi une nouvelle vague de tromperie — notamment avec l’essor des hypertrucages générés par l’IA.