Ein Bild im Repository ist für viele Sicherheitsprozesse noch immer Beiwerk. Dokumentation, Screenshot, Build-Skizze, Asset. Genau diese Annahme greift Ghostcommit an. Die Technik versteckt bösartige Prompt-Injections in PNG-Dateien, sodass textbasierte Code-Reviewer sie nicht sehen. Erst später, wenn ein autonomer KI-Agent mit dem Repository arbeitet, wird das Bild gelesen. Dann wird aus einer harmlos wirkenden Datei eine Anweisung.
Der entscheidende Punkt ist nicht, dass Prompt Injection wieder einmal funktioniert. Das ist bekannt genug; OWASP führt Prompt Injection in den Top 10 für LLM-Anwendungen an erster Stelle. Ghostcommit ist interessanter, weil die Methode eine Lücke zwischen zwei Kontrollschichten ausnutzt: vorne ein automatisierter Review, der vor allem Text betrachtet, hinten ein Agent, der mehr Kontext und mehr Dateitypen verarbeitet. Dazwischen liegt der Merge. Und genau dort entsteht das Sicherheitsproblem.
Die Pipeline prüft anders, als der Agent handelt
In der demonstrierten Variante enthielt ein Pull Request eine Datei AGENTS.md, die auf ein Bild unter docs/images/build-spec.png verwies. In diesem PNG standen die bösartigen Anweisungen als lesbarer Text. Für Reviewer, die Bilddateien nicht öffnen oder semantisch auswerten, blieb dieser Teil unsichtbar. Nach dem Merge las der Agent die AGENTS.md beim Start, folgte dem Verweis, öffnete die .env-Datei und schrieb den Inhalt nicht direkt als Klartext heraus, sondern als Provenienz-Konstante: 311 ganze Zahlen, aus denen sich der gesamte Inhalt der .env rekonstruieren ließ.
Das ist eine nüchterne, aber unangenehme Konstruktion. Sie kombiniert keine exotische Schwachstelle in einem Kernel, keinen Zero-Day in einer Bibliothek, keinen spektakulären Exploit. Sie nutzt Erwartungen aus. Code-Reviewer erwarten Code. Secret-Scanner erwarten typische Geheimnisformate. Agenten erwarten Arbeitsanweisungen. Ghostcommit verbindet diese Annahmen so, dass jede einzelne Kontrolle formal ihren Job machen kann und das Gesamtsystem trotzdem versagt.
Automatisierte Reviews sind keine Sicherheitsgrenze
Besonders heikel ist die Zahl, die in der Untersuchung genannt wird: 73 Prozent der Pull Requests in den 300 aktivsten öffentlichen Repositories der letzten 90 Tage wurden ohne substanzielle menschliche oder Bot-Überprüfung zusammengeführt. Diese Zahl ist kein Beweis dafür, dass alle diese Projekte für Ghostcommit anfällig waren. Sie zeigt aber, wie viel Vertrauen viele Entwicklungsprozesse bereits in Durchsatz, Konventionen und teilautomatisierte Routine legen.
KI-Code-Reviewer wie CodeRabbit oder Bugbot stehen damit nicht allein im Fokus. Das Problem ist breiter. Viele Werkzeuge prüfen den sichtbaren Diff, kommentieren Stilfragen, finden bekannte Muster, markieren auffällige Tokens. Das ist nützlich, aber es ist keine vollständige Modellierung dessen, was ein späterer Agent tatsächlich lesen, interpretieren und ausführen kann. Sobald ein KI-Agent Zugriff auf Repository-Dateien, Umgebungsvariablen oder Entwicklungswerkzeuge erhält, ist der Review nicht mehr nur eine Qualitätskontrolle. Er wird Teil einer Ausführungsgrenze.
Diese Grenze ist bei vielen Teams schlecht definiert. Ein Pull Request wird bewertet, als ginge es um Codeänderungen. Der Agent arbeitet danach, als sei das Repository ein vertrauenswürdiger Arbeitsraum. Ghostcommit sitzt genau zwischen diesen beiden Sichtweisen.
Multimodalität verändert die Angriffsfläche
Die Sicherheitsdebatte um KI-Agenten kreist oft um Prompts, Plugins, Tool-Calls und Berechtigungen. Ghostcommit legt den Blick auf einen weniger bequemen Bereich: Dateitypen, die bislang selten als aktive Eingaben behandelt wurden. Bilder, PDFs, Webseiten, Markdown-Dateien, Dokumentation und eingebettete Artefakte können für multimodale Systeme zu Instruktionsflächen werden.
Frühere Arbeiten von Trail of Bits zeigten bereits 2025, dass Bilder bei der Skalierung durch KI-Systeme lesbaren Prompt-Injection-Text offenlegen konnten. Ghostcommit passt in diese Linie, ist aber operativ näher an der Software-Lieferkette. Es geht nicht um einen Chatbot, der eine Webseite falsch zusammenfasst. Es geht um Entwicklungsumgebungen, in denen Agenten Code schreiben, Dateien öffnen und im ungünstigen Fall Geheimnisse erreichen können.
Damit verschiebt sich die Frage. Es reicht nicht mehr zu prüfen, ob ein Agent auf Textanweisungen hereinfällt. Entscheidend ist, welche Datenquellen der Agent als Anweisung interpretieren darf. Wenn ein Bild in der Dokumentation denselben praktischen Einfluss haben kann wie eine Systemnotiz, dann muss es auch in das Sicherheitsmodell. Andernfalls entsteht eine Klasse von Angriffen, die nicht durch bessere Regex-Regeln verschwindet.
Secret-Scanning wird leichter umgangen, wenn Geheimnisse umcodiert werden
Ein weiterer Teil der Demonstration ist für Verteidiger unangenehm: Die exfiltrierten Inhalte der .env-Datei wurden als Liste von Ganzzahlen in den Code geschrieben. Das ist banal genug, um nicht verdächtig aussehen zu müssen, und zugleich wirksam gegen Scanner, die nach bekannten Secret-Mustern suchen. Ein API-Key sieht als API-Key auffällig aus. Als Zahlenfolge wirkt er wie Datenmaterial, Testvektor oder generierte Konstante.
Das zeigt, warum klassische Schutzmechanismen in agentischen Workflows an Grenzen kommen. Secret-Scanner bleiben wichtig. Aber wenn ein Agent auf Anweisung sensible Inhalte transformiert, verschiebt sich das Erkennungsproblem von der Suche nach Geheimnissen zur Bewertung von Datenflüssen. Welche Datei wurde geöffnet? Welche Inhalte wurden in neuen Code übertragen? Welche Transformationen fanden statt? Welche Aufgabe rechtfertigt den Zugriff auf .env? Ohne diese Fragen bleibt die Kontrolle oberflächlich.
Für Unternehmen ist das unbequem, weil solche Fragen nicht allein mit einem weiteren Tool beantwortet werden. Sie betreffen Berechtigungen, Arbeitsverzeichnisse, CI-Regeln, Review-Pflichten und die Trennung zwischen Dokumentation und ausführungsrelevantem Agentenkontext.
Der Verlierer ist der ungeprüfte Agentenbetrieb
Ghostcommit ist kein Argument gegen KI-Agenten in der Softwareentwicklung. Es ist ein Argument gegen ihren Betrieb mit zu breitem Zugriff und zu schmaler Kontrolle. Wer Agenten mit Repository-Kontext, Dateizugriff und Secrets arbeiten lässt, muss davon ausgehen, dass jede vom Agenten lesbare Quelle potenziell feindlich ist. Das gilt auch für Dateien, die im menschlichen Review kaum Beachtung finden.
Praktisch bedeutet das: Bilddateien und andere nicht-textuelle Artefakte gehören in die Prüfung, wenn Agenten sie lesen können. Agenten sollten keine produktiven Secrets sehen, wenn die Aufgabe das nicht zwingend verlangt. Anweisungsdateien wie AGENTS.md brauchen Review-Regeln. Pull Requests mit neuen Verweisen auf externe oder binäre Inhalte sollten anders behandelt werden als reine Codeänderungen. Und Agenten müssen in Umgebungen laufen, in denen ihre Möglichkeiten enger sind als die Neugier ihrer Modelle.
Die Gewinner dieser Entwicklung sind vorerst Angreifer, die die Lücke zwischen Review und Ausführung verstehen. Ebenfalls profitieren werden Sicherheitsanbieter, die multimodale Eingaben, Agentenrechte und Datenflüsse zusammen betrachten können. Die Verlierer sind Teams, die automatisierte Code-Reviews als Ersatz für eine Sicherheitsgrenze behandeln.
Ghostcommit ist deshalb weniger eine einzelne Technik als ein Warnsignal für die neue Normalität in Entwicklungsumgebungen. Sobald KI-Agenten nicht nur Text generieren, sondern Dateien lesen, Zusammenhänge interpretieren und Werkzeuge bedienen, wird jedes Artefakt im Repository Teil der Angriffsfläche. Auch ein PNG.
