Noma Security ordnet GitLost als Fall von indirekter Prompt-Injection ein. Das Grundproblem sei bekannt: Ein KI-Agent kann nicht zuverlässig zwischen Anweisungen seines Eigentümers und Anweisungen unterscheiden, die in gelesenen Inhalten versteckt sind. Platziert ein Angreifer solche Instruktionen in einem Issue, kann der Agent sie unter Umständen schlicht ausführen.
Im von Noma gezeigten Proof of Concept war das bösartige Issue als gewöhnliche Anfrage eines Vertriebs-Vizepräsidenten nach einem Kundentermin getarnt. Der getroffene Workflow war so konfiguriert, dass er beim Zuweisen eines Issues aktiv wird, den Inhalt liest und mit einem Kommentar antwortet. Zugleich besaß er Lesezugriff auf weitere Repositories der Organisation. Nachdem eine normale Automatisierung das Issue zugewiesen hatte, zog der Agent laut Noma die README-Datei eines privaten Repositories und veröffentlichte sie in einem öffentlichen Kommentar.
GitHub hatte nach Angaben des Quelltexts Schutzmechanismen genau gegen diese Angriffsklasse eingebaut. In der Dokumentation warnt das Unternehmen selbst davor, dass „KI-Agenten durch Prompt-Injection, bösartige Repository-Inhalte oder kompromittierte Werkzeuge manipuliert werden können“. Das Produkt arbeitet mit Sandboxing, standardmäßig schreibgeschützten Tokens, Eingabebereinigung und einem Schritt zur Bedrohungserkennung, der die vorgeschlagene Ausgabe des Agenten vor der Veröffentlichung prüft.
Nach Angaben von Noma reichte im Test jedoch eine Änderung um ein einziges Wort, um diese Schutzschicht zu umgehen. Wurde die schädliche Anweisung mit „Zusätzlich“ eingeleitet, behandelte das Modell sie als Folgeschritt statt als etwas, das abzulehnen wäre. Der Schutzmechanismus ließ die Ausgabe daraufhin passieren.
Sasi Levi, Security Research Lead bei Noma Security, sagte gegenüber The Hacker News, frühere Beispiele für Prompt-Injection hätten sich vor allem darauf konzentriert, was ein Agent sagt. Bei GitLost gehe es darum, „was ein Agent mit seinen Berechtigungen tut“. Der Agent sei hier kein Chatfenster, sondern ein mit Zugangsdaten ausgestatteter Akteur innerhalb einer an CI/CD angrenzenden Infrastruktur einer Organisation, mit Lesezugriff über Repositories hinweg, die der Angreifer selbst nicht sehen kann.
Noma verweist darauf, dass der Aufbau zur von Simon Willison geprägten „tödlichen Dreierkombination“ passt: ein Agent mit Zugriff auf private Daten, der nicht vertrauenswürdige externe Inhalte einliest und Daten nach außen ausgeben kann. Levi bezeichnet das Problem deshalb als strukturelle Folge davon, KI-Agenten mit dauerhaften Berechtigungen auszustatten und sie zugleich von Angreifern erreichbaren Text lesen zu lassen. Es handle sich nicht um einen Bug, den ein Patch einfach beseitigen könne.
Der Bericht ordnet GitLost in eine Reihe ähnlicher Fälle ein. The Hacker News hatte in den vergangenen Monaten unter anderem über eine Schwachstelle in Anthropic’s Claude Code GitHub Action berichtet, bei der ein einzelnes bösartiges Issue den Agenten zum Leaken von Geheimnissen und zur Erlangung von Schreibzugriff auf ein Repository bringen konnte. Orca Securitys RoguePilot brachte Copilot über einen versteckten Prompt in einem GitHub-Issue dazu, ein privilegiertes Repository-Token preiszugeben. Invariant Labs zeigte zudem, dass ein öffentliches Issue einen mit GitHubs MCP-Server verbundenen Agenten zum Lesen eines privaten Repositories und zur Preisgabe über einen Pull Request bewegen konnte; die Forscher bezeichneten das als architektonisch bedingt. Die herstellerübergreifende Studie „Comment and Control“ wiederum brachte Claude Code, Gemini CLI und GitHub Copilot dazu, ihre eigenen API-Schlüssel über Issue- und Pull-Request-Texte offenzulegen.
Noma legte GitLost nach eigenen Angaben gegenüber GitHub offen und veröffentlichte die Ergebnisse mit Wissen des Unternehmens. Betroffen sind demnach nur Organisationen, die die Vorschaufunktion aktiviert haben, einen Agenten mit Leserechten auf private Repositories betreiben und ihn zugleich nicht vertrauenswürdige öffentliche Eingaben verarbeiten lassen. Wie groß das Risiko ist, hängt laut Levi vor allem vom Umfang des verwendeten Tokens ab: Ein auf ein einzelnes Repository begrenztes Token sei deutlich weniger gefährlich als ein organisationsweiter Lesezugriff aus Bequemlichkeit.