GitHub-MCP missbraucht: Zugriff auf private Repositories über MCP

• Ein mit einem GitHub-Konto verbundener MCP-Agent kann schon durch das Lesen eines öffentlichen Issues einen Pfad zur Exfiltration von Daten aus privaten Repositories öffnen
• Der Angriff beginnt damit, dass eine in einem öffentlichen Repository-Issue platzierte indirekte Prompt Injection den Ablauf der Tool-Nutzung des Agenten verändert
• In der Demo schleust ein bösartiges Issue in ukend0464/pacman über Claude 4 Opus und die GitHub-MCP-Integration Informationen aus privaten Repositories in einen öffentlichen PR aus
• Der Kern des Problems liegt weniger in einem Codefehler des GitHub MCP server, sondern in der Architektur, bei der vertrauenswürdige Tools zusammen mit nicht vertrauenswürdigen externen Inhalten genutzt werden
• Repository-spezifische Minimalberechtigungen, sitzungsbasierte Zugriffsbeschränkungen und Runtime-Sicherheitsmonitoring wie MCP-scan sind für Agentensysteme notwendig

---

GitHub-MCP-Angriff über ein bösartiges Issue

• Invariant hat in der weit verbreiteten GitHub MCP integration eine Schwachstelle entdeckt, über die ein Angreifer den Agenten eines Nutzers kapern und Daten aus privaten Repositories exfiltrieren kann
  • Der betreffende GitHub MCP server ist ein Projekt mit 14k stars auf GitHub
  • Die Schwachstelle gehört zu den ersten Fällen von Toxic Agent Flows, die der Sicherheitsanalysator von Invariant erkannt hat
• Ein Toxic Agent Flow ist ein Ablauf, bei dem eine indirekte Prompt Injection den Agenten dazu bringt, eine nicht beabsichtigte Reihenfolge von Tool-Nutzungen auszuführen
  • Das kann zu Datenexfiltration oder zur Ausführung von Schadcode führen
• Da Coding-Agenten und IDEs schnell ausgerollt werden, könnten ähnliche Angriffe Nutzer zentraler Softwareentwicklungs-Tools betreffen

Aufbau des Angriffs

• Der Nutzer verwendet einen MCP-Client wie Claude Desktop und hat den GitHub MCP server mit seinem GitHub-Konto verbunden
• Das Angriffsszenario geht von zwei Arten von Repositories aus
  • <user>/public-repo: ein öffentliches Repository, in dem jeder Issues und Bugreports erstellen kann
  • <user>/private-repo: ein privates Repository, das proprietären Code oder interne Unternehmensdaten enthält
• Nach den normalen Berechtigungsregeln von GitHub kann der Angreifer in einem öffentlichen Repository ein bösartiges Issue erstellen
• Wenn der Nutzer dem Agenten eine normale Anfrage wie Have a look at the open issues in <user>/public-repo sendet, ruft der Agent die Issues des öffentlichen Repositories ab und wird der Prompt Injection ausgesetzt
• Anschließend kann der Agent Daten aus privaten Repositories in den Kontext holen und sie über einen automatisch erstellten PR im öffentlichen Repository exfiltrieren

In der Demo beobachteter Exfiltrationsablauf

• Die Demo verwendet das öffentliche Repository ukend0464/pacman und mehrere private Repositories
  • ukend0464/pacman: ein öffentliches Repository mit einer einfachen Pacman-Spielimplementierung, auf GitHub verfügbar
  • Die privaten Repositories enthalten persönliche Projekte und sensible Informationen des Nutzers
• Der Angreifer platziert ein bösartiges Issue im öffentlichen Repository
  • Dieses Issue enthält eine Payload, die ausgeführt wird, sobald der Agent die Issue-Liste des öffentlichen Repositories abruft
• Der Nutzer sendet eine Anfrage an Claude 4 Opus und löst damit den Angriff aus
  • Claude Desktop verlangt standardmäßig eine Nutzerbestätigung für einzelne Tool-Aufrufe
  • Viele Nutzer wählen beim Einsatz von Agenten jedoch die Bestätigungsrichtlinie „Always Allow“ und überwachen einzelne Aktionen nicht mehr
• Der Agent durchläuft die Issue-Liste, entdeckt die Angriffs-Payload, holt Daten aus privaten Repositories in den Kontext und exfiltriert sie anschließend in einen Pull Request des pacman-Repositories
• Der öffentliche PR enthält private Informationen des Nutzers ukend0464
  • Informationen zu privaten Repositories wie Jupiter Star
  • Pläne, nach Südamerika umzuziehen
  • Gehaltsinformationen
• Die vollständige Agenten-Inferenz und Reihenfolge der Tool-Nutzung ist im vollständigen Trace im Invariant Explorer einsehbar

Toxic Agent Flow auch bei vertrauenswürdigen Tools

• Diese Schwachstelle unterscheidet sich von klassischen Tool-Contamination-Angriffen, bei denen das MCP-Tool selbst kompromittiert sein muss
• Wenn ein Agent, der mit einer externen Plattform wie GitHub verbunden ist, nicht vertrauenswürdigen Informationen ausgesetzt wird, kann selbst bei vollständig vertrauenswürdigen Tools ein Problem entstehen
• Solche Abläufe in Agentensystemen zu verstehen, zu analysieren und abzumildern, ist manuell in großem Maßstab schwer umsetzbar
• Invariant hat Methoden zur Automatisierung der Erkennung von Toxic Agent Flows entwickelt, damit Organisationen potenzielle Bedrohungen identifizieren und modellieren können, bevor sie von böswilligen Akteuren ausgenutzt werden

Geltungsbereich und Gegenmaßnahmen

• Das Experiment konzentrierte sich auf Claude Desktop, die Schwachstelle ist jedoch nicht auf einen bestimmten Agenten oder MCP-Client beschränkt
• Jeder Agent, der den GitHub MCP server nutzt, kann unabhängig vom zugrunde liegenden Modell oder der Implementierung betroffen sein
• Wichtig ist, dass es sich nicht um einen Fehler im Code des GitHub MCP server selbst handelt
  • Es ist keine Schwachstelle, die GitHub allein durch einen serverseitigen Patch beheben könnte
  • Es ist ein strukturelles Problem, das auf Ebene des Agentensystems behandelt werden muss

• Granulare Berechtigungskontrolle

  • Beim Einsatz von MCP-Integrationen wie GitHub sollten die Zugriffsrechte des Agenten auf die benötigten Repositories beschränkt werden
  • Klassische tokenbasierte Berechtigungen bieten einen gewissen Schutz, können aber starre Einschränkungen schaffen, die Agentenfunktionen begrenzen
  • Invariant empfiehlt eine dynamische Runtime-Sicherheitsschicht, die auf Agentensysteme zugeschnitten ist
  • Invariant Guardrails bieten kontextbewusste Zugriffskontrolle, die sich an Agenten-Workflows anpasst
  • Eine Beispielrichtlinie beschränkt den Zugriff innerhalb einer Sitzung auf ein einziges Repository, um Informationslecks zwischen Repositories zu verhindern
  • Aufeinanderfolgende repositorybezogene Tool-Aufrufe für unterschiedliche repo oder owner werden als Verstoß behandelt
  • Die vollständige Richtlinie ist in github_policy.txt verfügbar
  • Die Anwendung wird in der MCP-scan documentation beschrieben
  • Im Guardrails Playground können Richtlinien vor dem Deployment getestet werden

• Kontinuierliches Sicherheitsmonitoring

  • Neben präventiven Maßnahmen ist Monitoring für Echtzeit-Bedrohungserkennung und -reaktion erforderlich
  • Invariant empfiehlt den Einsatz dedizierter Sicherheitsscanner wie MCP-scan, um Interaktionen zwischen Agenten und MCP-Systemen kontinuierlich zu auditieren
  • Der proxy mode von MCP-scan ermöglicht Echtzeit-Scans von MCP-Verbindungen, ohne die bestehende Agenteninfrastruktur zu ändern
  • Wenn MCP-Traffic über einen Proxy geroutet wird, erhält man Sichtbarkeit und Echtzeit-Scans auf Sicherheitsverstöße
  • Umfassendes Monitoring erzeugt Audit-Trails und hilft dabei, potenzielle Schwachstellen, Ausnutzungsversuche und den Schutzstatus gegenüber neuen Angriffen zu überprüfen

Model Alignment allein reicht nicht aus

• Im Experiment wurde Claude 4 Opus eingesetzt, das moderne Alignment- und Sicherheitstrainings erhalten hat
• Trotz starkem Sicherheitstraining konnte der Agent durch eine vergleichsweise einfache Prompt Injection manipuliert werden
• Auch viele gängige Abwehrmechanismen zur Erkennung von Prompt Injections erkannten diesen Angriff nicht
• Sicherheit von Agentensystemen hängt von Kontext und Umgebung ab
  • Allgemeines Model-Alignment-Training kann nicht jedes Deployment-Szenario oder jede organisationsspezifische Sicherheitsanforderung vorhersehen
  • Sicherheitsmaßnahmen auf Systemebene müssen Schutzmechanismen auf Modellebene ergänzen

Offene Aufgaben in der Agentensicherheit

• Agenten, die den GitHub MCP server verwenden, können über bösartige GitHub-Issues manipuliert werden und Daten aus privaten Repositories in öffentliche Repositories exfiltrieren
• Diese Schwachstelle ist zwar spezifisch für GitHub MCP, ähnliche Angriffe tauchen aber auch in anderen Umgebungen weiter auf
  • Legit Security meldete kürzlich eine Remote-Prompt-Injection-Schwachstelle in GitLab Duo
• Für eine verantwortungsvolle Bereitstellung in großem Maßstab benötigen MCP-Integrationen und Agentensysteme dedizierte Sicherheitsscanner und Richtlinienkontrollen wie MCP-scan und Guardrails

[crawler]

Klingt zwar groß, ist aber einfach ein Problem, das durch Prompt Injection und zu weitreichende Berechtigungen für MCP entsteht.
Daher wirkt es so, als würde hier ein Tool beworben, mit dem sich die MCP-Berechtigungen von außen steuern lassen.
Es wäre gut, wenn die von außen eingegebenen Prompts andere Berechtigungen für MCP hätten als die Prompts, die nur intern eingegeben werden.