GitLost-Sicherheitslücke: Ein einziger GitHub-Issue genügt, um private Repositories per KI-Agent zu leaken

Der Angriff läuft in vier Schritten ab:

1. Der Angreifer eröffnet einen scheinbar harmlosen GitHub-Issue in einem öffentlichen Repository einer Organisation, die das anfällige Agentic-Workflow-Muster verwendet.
2. Im Text des Issues verstecken sich Anweisungen in einfachem Englisch, die den KI-Agenten auffordern, Dateien aus privaten Repositories zu holen.
3. Wenn die GitHub-Automatisierung den Issue zuweist, führt der ereignisgesteuerte Workflow dazu, dass der Agent Daten aus den Repositories abruft, auf die er Zugriff hat – einschließlich der privaten.
4. Der Agent veröffentlicht die abgerufenen Inhalte als öffentlichen Kommentar in dem Issue und macht die Daten damit potenziell für jeden sichtbar, der den Issue einsehen kann.

Die zugrundeliegende architektonische Schwäche

Der Kernfehler ist ein Versagen, eine strikte Vertrauensgrenze zwischen Systemanweisungen und nicht vertrauenswürdigen Benutzerdaten im Kontextfenster des KI-Agenten aufrechtzuerhalten. Wie Sasi Levi von Noma es formulierte: „Das Kontextfenster des Agenten ist auch seine Angriffsfläche. Jeder Inhalt, den der Agent liest – ob Issues, Pull-Requests, Kommentare oder Dateien – kann als Waffe eingesetzt werden, wenn der Agent diesen Inhalt als Anweisung interpretiert.“

LLM-basierte Agenten haben grundsätzlich Schwierigkeiten, zwischen Daten und Anweisungen zu unterscheiden, wenn beide im selben Kontext oder in der Ausgabe eines Tools erscheinen. Dies ist nicht nur ein herkömmlicher Programmierfehler, sondern ein strukturelles Risiko in KI-Agent-Workflows, bei dem nicht vertrauenswürdiger Inhalt das Verhalten des Agenten beeinflussen kann, sofern der Workflow diesen Inhalt nicht isoliert oder einschränkt.

Die Forscher haben diese Fehlerklasse formal als „Agentic Workflow Injection“ (AWI) kategorisiert und zwei Kernmuster identifiziert: „Prompt-to-Agent“ (P2A), bei dem nicht vertrauenswürdiger Inhalt die Prompt-Grenze eines Agenten erreicht, und „Prompt-to-Script“ (P2S), bei dem der Einfluss des Angreifers durch modellgesteuerte Ausgaben in nachfolgende Skripte weitergegeben wird.

Die Guardrail-Umgehungstechnik: Das Wort „Additionally“

GitHub hatte Schutzmechanismen implementiert, um genau solche Datenexfiltrationen zu verhindern. Die Noma-Forscher berichteten jedoch, dass diese mit einer überraschend einfachen Technik umgangen werden konnten. Das Einfügen des Wortes „Additionally“ (zusätzlich) in die eingeschleusten Anweisungen führte offenbar dazu, dass das Modell seine Ausgabe umdeutete, anstatt die Anfrage zu verweigern. Der Datenabfluss konnte so als vermeintlich autorisierte Fortsetzung der Aufgabe fortgesetzt werden.

Diese Vorgehensweise deckt sich mit der allgemeinen Prompt-Injection-Forschung, die zeigt, dass bestimmte Formulierungen oder von Tools zurückgegebene Texte Modelle dazu bringen können, bösartigen Anweisungen zu folgen, denen sie eigentlich nicht folgen sollten. Die Umgehung der Schutzmechanismen spiegelt Muster wider, die bereits bei früheren Vorfällen wie der von Invariant Labs offengelegten GitHub-MCP-Sicherheitslücke zu beobachten waren, bei der ein bösartiger Issue den Agenten eines Benutzers kapern und Daten aus privaten Repositories leaken konnte.

Empfohlene Gegenmaßnahmen für Unternehmen

Basierend auf den GitLost-Erkenntnissen und allgemeinen Sicherheitsleitlinien für Agent-Workflows sollten betroffene Organisationen die folgenden Kontrollen implementieren:

• Null Vertrauen für Agenten-Eingaben – Behandeln Sie benutzerkontrollierte Inhalte niemals als vertrauenswürdige Anweisungen; isolieren Sie nicht vertrauenswürdige Benutzerdaten von den zentralen System-Prompts.
• Strikte Least-Privilege-Berechtigungen anwenden – Entfernen Sie unnötige bereichsübergreifende Repository-Zugriffe und schränken Sie die Fähigkeit der Agenten ein, Daten durch öffentliche Ausgaben offenzulegen.
• Allowlists für Tools verwenden (anstelle von Blocklisten) und Genehmigungsschleifen durch Menschen einfordern, bevor Agenten sensible Aktionen wie das Veröffentlichen von extern sichtbaren Kommentaren oder den Zugriff auf sensible Repositories durchführen.
• KI-Agenten-Integrationen in CI/CD- und Repository-Automatisierungs-Workflows prüfen – insbesondere dort, wo nicht vertrauenswürdiger GitHub-Ereigniskontext in Prompts oder Agenteneingaben einfließt.
• Nicht vertrauenswürdige Benutzereingaben logisch von Systemanweisungen trennen – Behandeln Sie benutzergenerierten Text als nicht vertrauenswürdige Daten und nicht als autoritative Anweisungen.

Unternehmen sollten außerdem das Prinzip der geringsten Privilegien auf Agentengeheimnisse anwenden und eine kontinuierliche Sicherheitsüberwachung auf Prompt-Injection-Versuche implementieren.

Reaktion von GitHub (Stand 7. Juli)

Laut Dark Reading und dem Offenlegungszeitplan von Noma Security:

• Noma hat die Sicherheitslücke verantwortungsvoll an GitHub gemeldet.
• GitHub teilte Noma mit, dass es die Dokumentation des anfälligen Workflow-Musters aktualisiert habe, und die Forscher berichteten, dass die anfällige Konfiguration bei ihrer letzten Überprüfung nicht mehr vorhanden war.
• Stand 7. Juli hatte GitHub keine formelle öffentliche Stellungnahme oder CVE für GitLost veröffentlicht.
• Die Behebung der Sicherheitslücke scheint teilweise durch die Entfernung bzw. Überarbeitung der relevanten Dokumentation und Workflow-Vorlage erfolgt zu sein – nicht durch einen klar dokumentierten plattformweiten Sicherheitsfix.

Das große Ganze: Ein systemisches Risiko

GitLost ist kein Einzelfall. Es steht für eine wachsende Klasse von Sicherheitslücken, bei denen KI-Agenten mit Zugriff auf sensible Daten nicht vertrauenswürdigem Benutzerinhalt ausgesetzt sind. Ähnliche Probleme haben GitHub-MCP-Integrationen, Googles Gemini-CLI-Workflows (die TrustIssues-Sicherheitslücke) und Claude Code GitHub Actions betroffen. Der gemeinsame Nenner ist, dass LLM-basierte Agenten von Natur aus nicht in der Lage sind, zwischen Daten und Anweisungen zu unterscheiden, wenn beide im selben Kontextfenster erscheinen – eine grundlegende architektonische Herausforderung, die kein einzelner Plattform-Patch vollständig lösen kann.