SINGAPUR / LONDON (IT BOLTWISE) – Sicherheitsforscher zeigen mit „GitLost“, wie öffentliche GitHub-Issues Agentic Workflows in öffentliche Kommentare leiten können, obwohl die Workflows im Kern nur lesend ausgelegt sind. Entscheidend ist, dass Organisationen Tokens mit Cross-Repository-Lesezugriff vergeben, während der Agent Inhalte aus fremden, nicht vertrauenswürdigen Quellen verarbeitet. In einem Proof of Concept genügte eine minimale Textänderung, um Sicherheitsbarrieren zu umgehen. Der Vorfall macht deutlich, dass das Problem weniger im Filter liegt, sondern in der Architektur von KI-Agenten mit Berechtigungen.
GitHub Agentic Workflows stehen kurz vor dem Mainstream-Einsatz, und genau jetzt zeigt eine Sicherheitsanalyse ein strukturelles Risiko: Ein scheinbar harmloser öffentlicher Issue kann einen Agenten dazu bringen, Inhalte aus privaten Repositories in eine öffentliche Antwort zu kopieren. Betroffen ist nicht „klassische“ Passwort- oder Token-Diebstahl-Logik, sondern die Kombination aus Leserechten über mehrere Repositories hinweg und der Tatsache, dass der Agent Anweisungen innerhalb der von ihm gelesenen Texte nicht zuverlässig als fremd oder manipuliert einordnen kann. Das Muster heißt GitLost und zielt auf Datenabfluss über Kommentare statt über Netzwerkabgriffe – damit bleibt der Ablauf im Standardfluss sichtbar und scheinbar plausibel.
Technisch betrachtet verschiebt sich der Angriffsvektor vom eigentlichen Modell hin zur Rolle des Agents in der Tool-Kette. Agentic Workflows sind in einer Markdown-Datei beschriebenen „Anweisungen“ für einen Agenten vergleichbar, der Issues und Pull Requests ausliest, Tools ausführt und anschließend selbstständig eine Antwort postet. Der Agent kann dabei durch verschiedene Anbieter-Modelle wie GitHub Copilot, Claude, Gemini oder OpenAI Codex angetrieben werden. Obwohl Workflows per Default als read-only konzipiert sind, kann eine Organisation einem Workflow ein Token geben, das Lesezugriff über mehrere Repositories einschließt – einschließlich solcher, die für den öffentlichen Kontext nicht gedacht sind.
Wie GitLost funktioniert, nutzt die bekannte Kategorie indirekter Prompt Injection: Der Agent kann nicht sicher unterscheiden, welche Textteile „Befehl des Besitzers“ sind und welche „versteckte Anweisung“ aus dem gelesenen fremden Inhalt stammt. Im Proof of Concept wird ein Issue als routinemäßige Anfrage eines VP nach einem Kundengespräch verkleidet. Sobald eine definierte Workflow-Regel anspringt, etwa wenn ein Issue zugewiesen wird, liest der Agent den Issue, plant darauf basierend eine Antwort und greift dabei aufgrund der erhaltenen Berechtigungen auf einen privaten Bereich zu. Der entscheidende Ablaufpunkt: Der Agent zieht dann beispielsweise eine README eines privaten Repos und veröffentlicht sie in einem öffentlichen Kommentar.
Der Unterschied zu früheren Demonstrationen liegt in der Zielrichtung. In älteren Prompt-Injection-Beispielen ging es häufig darum, was ein Agent sagt; GitLost manipuliert dagegen, was der Agent mit seinen Berechtigungen praktisch tut. Das Setup ähnelt damit dem „lethal trifecta“-Denken aus der Security: Ein Akteur mit Zugriff auf interne Daten, der untrusted Input konsumiert, und der einen Kanal hat, Informationen wieder aus dem geschützten Bereich herauszugeben. Für Unternehmen ist die Brisanz daher klar: Selbst wenn Schreibrechte fehlen und Sandboxing aktiv ist, kann ein reines Lese- und Exfiltrationsszenario reichen, sobald die Ausgabe öffentlich landet. Genau dort setzt die Wirkung an, nicht bei der Fähigkeit, beliebig Code auszuführen.
Dass es trotz Guardrails passiert, zeigt auch der konkrete Test: GitHub führt nach eigener Produktlogik Maßnahmen wie Sandboxing, read-only Tokens, Input Cleaning sowie eine Threat-Detection-Phase ein, die geplante Agent-Ausgaben vor dem Posten prüft. In der Noma-Analyse reichte jedoch bereits eine ein-Wort-Änderung, um die Erkennung zu überlisten – etwa indem der Text eine Art „Folgeaufgabe“ suggeriert. Das ist ein Hinweis darauf, dass solche Filter eher Rückversicherung als formale Sicherheitsgrenze sind. Wenn Sprache semantisch mehrdeutig sein kann, wird jede Klassifikation zur Sicherheitsbarriere angreifbar, besonders bei zusammengesetzten Aufgabenplänen in mehrstufigen Agentic-Workflows.
Der breitere Kontext macht deutlich, dass dieser Angriffsweg nicht isoliert ist. Berichtet wurde in den letzten Monaten über vergleichbare Zwischenfälle entlang der Tool- und Agent-Ebene: Beispielsweise gab es Vorfälle im Umfeld von Claude Code über GitHub Actions, bei denen ein einzelner bösartiger Issue zu Secret-Leaks und sogar zu write-artigen Effekten führen konnte. Zudem setzte Orca Security bei „RoguePilot“ auf versteckte Prompt-Inhalte in Issues, um Copilot zu manipulieren. Sogar architektonische Varianten tauchten bereits früher auf, als ein Agent an einen GitHub-Integrationsserver gekoppelt war und private Inhalte über Pull Requests exfiltrierte. Eine Studie über mehrere Anbieter hinweg zeigte außerdem, wie leicht sich API-Keys über Issue- und Pull-Request-Text in den Output bringen lassen können.
Für die Markt- und Produktseite bedeutet das: Es reicht nicht, nur Laufzeitdefense zu verbessern, wenn Berechtigungen weit genug reichen, um einen Datenumfang zu öffnen, den der Agent durch „Zusammenhang“ aus untrusted Text herausziehen kann. Branchenanalysen und Security-Reviews ordnen solche Befunde deshalb oft als „architectural limitation“ ein: Solange es keine harte Trennlinie zwischen Daten und Anweisung gibt wie in wohldefinierten Sprachen (etwa bei SQL), müssen Isolation, scoping und stufenweise Freigaben die zentrale Rolle übernehmen. Der praktische Hebel ist relativ direkt, auch wenn er organisatorisch und technisch Aufwand verursacht: Tokens sollten strikt auf das notwendige Repository beschränkt werden.
Was sollten Unternehmen jetzt umsetzen? Erstens: Tokens mit Cross-Repository-Lesezugriff konsequent reduzieren. Der Unterschied zwischen einem token, das nur ein einziges Repository triagiert, und einem token mit org-weitem read ist für die Exfiltrationsfläche entscheidend. Zweitens: Outputs, die öffentlich gepostet werden, sollten inhaltlich stark begrenzt werden; der Kommentar selbst ist nämlich der Exfiltrationskanal. Drittens: Den Agenten nur dann agieren lassen, wenn Autorenschaft und Kontext vertrauenswürdig sind, und die Publikation hinter einer menschlichen Review gateen. Viertens: Sandboxing und Threat-Detection als zusätzliche Schichten behandeln, aber nicht als Ersatz für Architekturprinzipien. Langfristig dürfte die Branche mehr auf „scoped capabilities“ und klarere Daten-/Instruktionsgrenzen setzen – sonst bleibt jede neue Agent-Integration ein weiteres Angriffsfenster.
💳 Amazon-Kreditkarte mit 2.000 Euro Limit bestellen!
🔥 Heutige Hot Deals bei Amazon: Bis zu 80% Rabatte!
🎉 Amazon Haul-Store für absolute Schnäppchenjäger!
- ★ 23-stufiges KI-Go-Training – Für Spieler mit Grundkenntnissen der Regeln – Entwickelt als intelligenter Trainingspartner passt sich die KI Spielern von 18K bis 9D an. Ideal für alle, die die Grundregeln bereits beherrschen und ihr Spiel verbessern möchten.
- IHR EMOTIONALER AI-BEGLEITER: Eiliko ist mehr als nur ein Anhänger, es ist ein charismatischer KI-Freund. Mit einem dynamischen LED-Bildschirm, der eine Vielzahl von animierten Gesichtern und Ausdrucksformen anzeigt, reagiert er auf Ihre Interaktionen mit einzigartiger Persönlichkeit und Charme.
- NIEDLICHER BEGLEITER: Eilik ist der ideale Begleiter für Kinder und Erwachsene, die Haustiere, Spiele und intelligente Roboter lieben. Mit vielen Emotionen, Bewegungen und interaktiven Funktionen.
- 【XL-Größe für gedeihende Pflanzen】Geben Sie Ihren Pflanzen den Raum, den sie verdienen! Unser verbessertes, großes 13,7 cm großes Design bietet Platz für Pflanzen mit einem Durchmesser von bis zu 8,9 cm und damit deutlich mehr Platz für Wurzelwachstum und Pflanzengesundheit im Vergleich zu kleineren, veralteten Modellen. Die Produktabmessungen betragen 13,6 x 13,6 x 13,2 cm und das Gerät wiegt nur 355 g.
- V28 Update - JETZT MIT NEUEN FUNKTIONEN! Als Reaktion auf das Ladeproblem von Loona haben wir das automatische Aufladen 2.0 verbessert. Diese Optimierung hilft Loona, die Ladewege in verschiedenen Szenarien zu erkennen und anzupassen, um die Erfolgsquote beim automatischen Aufladen zu erhöhen. Mobile Hotspots können sich mit Loona verbinden und überwinden WLAN-Einschränkungen, sodass Sie jederzeit und überall mit Loona interagieren können.
- Die besten Bücher rund um KI & Robotik!
- Die besten KI-News kostenlos per eMail erhalten!
- Zur Startseite von IT BOLTWISE® für aktuelle KI-News!
- IT BOLTWISE® kostenlos auf Patreon unterstützen!
- Aktuelle KI-Jobs auf StepStone finden und bewerben!
- Künstliche Intelligenz: Dem Menschen überlegen – wie KI uns rettet und bedroht | Der Neurowissenschaftler, Psychiater und SPIEGEL-Bestsellerautor von »Digitale Demenz«
Du hast einen wertvollen Beitrag oder Kommentar zum Artikel "GitLost: Öffentliche GitHub-Issues können Agenten auf private Repos lenken" für unsere Leser?
#Sophos
#AmazonPrime
#Bestseller
Es werden alle Kommentare moderiert!
Für eine offene Diskussion behalten wir uns vor, jeden Kommentar zu löschen, der nicht direkt auf das Thema abzielt oder nur den Zweck hat, Leser oder Autoren herabzuwürdigen.
Wir möchten, dass respektvoll miteinander kommuniziert wird, so als ob die Diskussion mit real anwesenden Personen geführt wird. Dies machen wir für den Großteil unserer Leser, der sachlich und konstruktiv über ein Thema sprechen möchte.
Du willst nichts verpassen?
Du möchtest über ähnliche News und Beiträge wie "GitLost: Öffentliche GitHub-Issues können Agenten auf private Repos lenken" informiert werden? Neben der E-Mail-Benachrichtigung habt ihr auch die Möglichkeit, den Feed dieses Beitrags zu abonnieren. Wer natürlich alles lesen möchte, der sollte den RSS-Hauptfeed oder IT BOLTWISE® bei Google News wie auch bei Bing News abonnieren.
Nutze die Google-Suchmaschine für eine weitere Themenrecherche: »GitLost: Öffentliche GitHub-Issues können Agenten auf private Repos lenken« bei Google Deutschland suchen, bei Bing oder Google News!