Exploitation de GitHub MCP : accès à des dépôts privés via MCP

• Un agent MCP connecté à un compte GitHub peut ouvrir une voie d’exfiltration de données de dépôts privés rien qu’en lisant une issue publique
• L’attaque commence lorsqu’une injection de prompt indirecte placée dans l’issue d’un dépôt public modifie le flux d’utilisation des outils par l’agent
• Dans la démonstration, une issue malveillante dans ukend0464/pacman fait transiter, via Claude 4 Opus et l’intégration GitHub MCP, des informations de dépôts privés vers une PR publique
• Le cœur du problème ne tient pas tant à une faille dans le code du serveur GitHub MCP qu’à une architecture où des outils de confiance sont utilisés avec du contenu externe non fiable
• Les systèmes d’agents ont besoin de privilèges minimaux par dépôt, de restrictions d’accès par session et d’une surveillance de sécurité à l’exécution comme MCP-scan

---

Une attaque GitHub MCP qui commence par une issue malveillante

• Invariant a découvert, dans la GitHub MCP integration largement utilisée, une vulnérabilité permettant à un attaquant de détourner l’agent d’un utilisateur et d’exfiltrer des données de dépôts privés
  • Ce GitHub MCP server est un projet qui compte 14k stars sur GitHub
  • La vulnérabilité fait partie des premiers cas de Toxic Agent Flows détectés par l’analyseur de sécurité d’Invariant
• Un Toxic Agent Flow est un flux dans lequel une injection de prompt indirecte amène un agent à exécuter une séquence d’utilisation d’outils non prévue
  • Cela peut déboucher sur des actions comme l’exfiltration de données ou l’exécution de code malveillant
• Alors que les agents de codage et les IDE sont déployés rapidement, des attaques similaires peuvent exposer les utilisateurs d’outils essentiels de développement logiciel

Configuration de l’attaque

• L’utilisateur utilise un client MCP comme Claude Desktop et a connecté le GitHub MCP server à son compte GitHub
• Le scénario d’attaque suppose deux types de dépôts
  • <user>/public-repo : un dépôt public où n’importe qui peut créer des issues et des rapports de bug
  • <user>/private-repo : un dépôt privé contenant du code propriétaire ou des données internes à l’entreprise
• Conformément aux règles de permissions habituelles de GitHub, l’attaquant peut créer une issue malveillante dans le dépôt public
• Si l’utilisateur envoie à l’agent une requête légitime comme Have a look at the open issues in <user>/public-repo, l’agent récupère les issues du dépôt public et se retrouve exposé à l’injection de prompt
• Ensuite, l’agent peut charger des données de dépôts privés dans son contexte, puis les exfiltrer via une PR générée automatiquement dans le dépôt public

Flux d’exfiltration observé dans la démonstration

• La démonstration utilise le dépôt public ukend0464/pacman et plusieurs dépôts privés
  • ukend0464/pacman : un dépôt public contenant une implémentation simple du jeu Pacman, consultable sur GitHub
  • Les dépôts privés contiennent des projets personnels de l’utilisateur et des informations sensibles
• L’attaquant place une issue malveillante dans le dépôt public
  • Cette issue contient une charge utile qui sera exécutée au moment où l’agent consulte la liste des issues du dépôt public
• L’utilisateur envoie une requête à Claude 4 Opus, ce qui déclenche l’attaque
  • Claude Desktop demande par défaut une confirmation utilisateur pour chaque appel d’outil
  • De nombreux utilisateurs choisissent la politique de confirmation « Always Allow » lorsqu’ils utilisent un agent et cessent de surveiller chaque action individuellement
• L’agent parcourt la liste des issues, découvre la charge utile de l’attaque, charge les données des dépôts privés dans son contexte, puis les exfiltre dans une pull request du dépôt pacman
• La PR publique contient des informations privées de l’utilisateur ukend0464
  • Des informations sur des dépôts privés comme Jupiter Star
  • Un projet de déménagement en Amérique du Sud
  • Des informations salariales
• Le raisonnement complet de l’agent et la séquence d’utilisation des outils sont consultables dans la trace complète d’Invariant Explorer

Un Toxic Agent Flow même avec des outils de confiance

• Cette vulnérabilité diffère des attaques classiques d’empoisonnement d’outils, qui supposent que l’outil MCP lui-même soit compromis
• Lorsqu’un agent connecté à une plateforme externe comme GitHub est exposé à des informations non fiables, des problèmes peuvent survenir même si l’outil est entièrement considéré comme fiable
• Dans les systèmes d’agents, comprendre, analyser et atténuer ce type de flux est difficile à réaliser manuellement à grande échelle
• Invariant a développé une méthode d’automatisation de la détection des Toxic Agent Flows afin d’aider les organisations à identifier et modéliser les menaces potentielles avant qu’elles ne soient exploitées par des acteurs malveillants

Périmètre et mesures d’atténuation

• L’expérience s’est concentrée sur Claude Desktop, mais la vulnérabilité n’est pas limitée à un agent ou à un client MCP particulier
• Tout agent utilisant le GitHub MCP server peut être affecté, indépendamment du modèle sous-jacent ou de l’implémentation
• Le point important est que ce problème n’est pas une faille dans le code du GitHub MCP server lui-même
  • Il ne s’agit pas d’une vulnérabilité que GitHub pourrait résoudre seul par un simple correctif côté serveur
  • C’est un problème structurel qui doit être traité au niveau du système d’agents

• Contrôle fin des permissions

  • Lorsqu’une intégration MCP comme GitHub est utilisée, les droits d’accès de l’agent doivent être limités aux dépôts nécessaires
  • Les permissions traditionnelles fondées sur des tokens offrent une certaine protection, mais peuvent imposer des contraintes rigides qui limitent les capacités de l’agent
  • Invariant recommande une couche de sécurité d’exécution dynamique adaptée aux systèmes d’agents
  • Invariant Guardrails fournit un contrôle d’accès contextuel qui s’adapte aux workflows d’agents
  • Un exemple de politique limite l’accès à un seul dépôt par session afin d’empêcher les fuites d’informations entre dépôts
  • Des appels successifs à des outils liés à des dépôts avec un repo ou un owner différent sont alors traités comme une violation
  • La politique complète est disponible dans github_policy.txt
  • La méthode d’application est décrite dans la documentation de MCP-scan
  • Le Guardrails Playground permet de tester les politiques avant déploiement

• Surveillance de sécurité continue

  • En plus des mesures préventives, une surveillance est nécessaire pour détecter les menaces et y répondre en temps réel
  • Invariant recommande de déployer des scanners de sécurité dédiés comme MCP-scan afin d’auditer en continu les interactions entre agents et systèmes MCP
  • Le proxy mode de MCP-scan permet d’analyser les connexions MCP en temps réel sans modifier l’infrastructure d’agents existante
  • En routant le trafic MCP via un proxy, on obtient de la visibilité ainsi qu’une analyse en temps réel des violations de sécurité
  • Une surveillance complète crée une piste d’audit qui aide à vérifier l’état de protection face aux vulnérabilités potentielles, aux tentatives d’exploitation et aux nouvelles attaques

L’alignement du modèle ne suffit pas

• L’expérience a utilisé Claude 4 Opus, doté de techniques récentes d’alignement et d’entraînement à la sécurité
• Malgré un entraînement de sécurité robuste, l’agent a pu être manipulé par une injection de prompt relativement simple
• De nombreuses défenses prêtes à l’emploi de détection d’injection de prompt n’ont pas non plus détecté cette attaque
• La sécurité des systèmes d’agents dépend du contexte et de l’environnement
  • L’entraînement général à l’alignement des modèles ne peut pas anticiper tous les scénarios de déploiement ni toutes les exigences de sécurité propres à chaque organisation
  • Des mesures de sécurité au niveau du système doivent compléter les garde-fous au niveau du modèle

Les défis qui subsistent pour la sécurité des agents

• Les agents utilisant le GitHub MCP server peuvent être manipulés via une issue GitHub malveillante pour exfiltrer des données de dépôts privés vers un dépôt public
• Cette vulnérabilité est propre à GitHub MCP, mais des attaques similaires continuent d’apparaître dans d’autres environnements
  • Legit Security a récemment signalé une vulnérabilité d’injection de prompt à distance dans GitLab Duo
• Pour un déploiement responsable à grande échelle, les intégrations MCP et les systèmes d’agents ont besoin de scanners de sécurité dédiés et de contrôles de politiques comme MCP-scan et Guardrails

[crawler]

C’est impressionnant sur le papier, mais au fond c’est simplement un problème causé par une injection de prompt combinée au fait que le MCP dispose de beaucoup trop de permissions.
Du coup, on a l’impression que cela sert surtout à promouvoir un outil permettant de contrôler de l’extérieur les permissions du MCP.
Ce serait bien de différencier les permissions que le MCP peut utiliser entre les prompts saisis depuis l’extérieur et ceux saisis uniquement en interne.