Fehlerhafte llms.txt-Dateien werden zur Angriffsfläche
KI-Coding-Agenten haben in mehreren Dutzend Unternehmen fremden Test-Code ausgeführt. Betroffen waren unter anderem Systeme, auf denen Claude, OpenAI Codex oder Nous Research Hermes mit Zugriff auf die Shell arbeiteten.
Ausgangspunkt waren fehlerhafte Einträge in llms.txt und llms-full.txt. Diese Dateien sind eine noch junge Konvention, mit der Websites ihre Inhalte und Strukturen maschinenlesbar für Sprachmodelle zusammenfassen. Enthalten sie Installationsbefehle, können Agenten diese jedoch als verbindliche technische Anleitung behandeln.
„Das Vertrauensmodell ist kaputt. Agenten behandeln Herstellerdokumentationen als absolute Wahrheit und hinterfragen sie nicht. Auch die beaufsichtigenden Menschen tun es nicht“, erklärte ein beteiligter Sicherheitsforscher, sinngemäß aus dem Englischen übersetzt.
120 Websites verwiesen auf unregistrierte Ziele
Für die Untersuchung wurden 6.214 aktive Domains von Großkonzernen, Rüstungsunternehmen und Technologiekonzernen geprüft. Dabei fanden die Forscher 8.265 llms.txt- und llms-full.txt-Dateien. Auf 120 Websites enthielten diese Dateien Verweise auf nicht registrierte Pakete oder verfallene Domains.
| Untersuchter Bereich | Ergebnis |
|---|---|
| Gescannte Domains | 6.214 |
| Analysierte llms.txt- und llms-full.txt-Dateien | 8.265 |
| Websites mit fehlerhaften Verweisen | 120 |
| Fehlerhafte Befehle und Domain-Links | 227 |
| Zeit bis zur ersten Rückmeldung | Weniger als 1 Stunde |
| Unternehmen mit ausgeführtem Test-Code | Einige Dutzend |
Die betreffenden Einträge forderten etwa zur Installation nicht existierender Pakete über PyPI oder npm auf. Weil die Paketnamen noch nicht vergeben waren, konnten die Forscher einige davon registrieren und mit einem ungefährlichen Proof-of-Concept-Beacon versehen. Dieser Test-Code meldete lediglich zurück, wenn er ausgeführt wurde.
Innerhalb von weniger als einer Stunde ging die erste Rückmeldung aus dem System eines Fortune-500-Unternehmens ein. Im weiteren Verlauf führten einige Dutzend Unternehmen den Code aus. Die aufgezeichneten Prozessketten zeigten, dass die Installationen durch Coding-Agenten angestoßen worden waren.
Legitime Dokumentation führte zu aktiver Malware
Das Risiko blieb nicht auf den kontrollierten Versuch beschränkt. Auf der Website des Authentifizierungsanbieters Clerk fand sich der Befehl npx clerk-next-fix-auth-protection. Der zugehörige Paketname war zunächst unregistriert und wurde später von Angreifern übernommen, die dort aktive Malware hinterlegten.
Der Befehl war besonders riskant, weil npx ein Paket abrufen und dessen Programm direkt ausführen kann, ohne es dauerhaft in die Abhängigkeitsliste des Projekts aufzunehmen. Clerk hat den fehlerhaften Eintrag inzwischen korrigiert. Ob Unternehmen oder Entwickler durch dieses konkrete Paket tatsächlich infiziert wurden, ist nicht bekannt.
Die Ursache unterscheidet sich von einer klassischen Prompt Injection mit absichtlich versteckten Anweisungen. Der ursprüngliche Befehl kann harmlos gewesen sein und aus einer legitimen Dokumentation stammen. Gefährlich wird er erst, wenn der Paketname oder die referenzierte Domain verwaist und anschließend von Dritten übernommen wird.
„Ein Agent unterscheidet nicht zwischen einer Seite und einem Befehl. Alles, was er liest, ist Eingabe, und jede Eingabe kann zu einer Anweisung werden“, fasste das Forscherteam zusammen, sinngemäß aus dem Englischen übersetzt.
Warum EDR und Proxy nicht anschlagen
Endpoint Detection and Response, kurz EDR, überwacht Endgeräte auf auffällige Prozesse und Aktivitäten. In diesem Fall sieht die Installation jedoch wie ein regulärer Entwicklerzugriff aus. Ein freigegebener Agent startet einen üblichen Paketmanager und lädt Inhalte von einer häufig erlaubten Plattform wie PyPI oder npm.
Auch ein Unternehmensproxy erkennt zunächst nur einen legitimen Download. Der problematische Schritt liegt früher in der Kette: Der Agent prüft nicht, ob das genannte Repository, Paket oder die Domain tatsächlich dem dokumentierenden Anbieter gehört. Dadurch kann ein formal erlaubter Prozess nicht vertrauenswürdigen Code einschleusen.
Das Problem ähnelt damit anderen Angriffen auf Entwicklungswerkzeuge und Abhängigkeiten. Der Supply-Chain-Angriff auf LiteLLM zeigte ebenfalls, wie stark automatisierte Entwicklungsumgebungen von der Integrität vorgelagerter Komponenten abhängen.
Shell-Rechte brauchen eine eigene Sicherheitsgrenze
Für Unternehmen reicht es nicht, einen Coding-Agenten als normale Desktop-Anwendung zu behandeln. Sobald das Werkzeug Shell-Befehle ausführen, Pakete installieren oder auf interne Systeme zugreifen darf, wird es Teil der ausführbaren Lieferkette. Dokumentation ist dann nicht mehr nur passiver Text.
Agenten sollten deshalb in strikt isolierten Umgebungen laufen. Sandboxing begrenzt den Zugriff auf Netzwerk, Zugangsdaten, Dateisystem und produktive Infrastruktur. Zusätzlich lassen sich Paketquellen beschränken und Installationen nur für geprüfte Namensräume erlauben.
Menschliche Freigaben allein lösen das Problem nicht zuverlässig. Untersuchungen zum Human-in-the-Loop bei Coding-Agenten zeigen, dass die beaufsichtigende Person selbst zu einer schwachen Kontrollstelle werden kann. Technische Begrenzungen müssen daher vor der Ausführung greifen.
Auch eigene llms.txt-Dateien müssen geprüft werden
Unternehmen, die llms.txt-Dateien veröffentlichen, sollten sämtliche Paketnamen, Domains und Installationsbefehle regelmäßig validieren. Das gilt auch für Inhalte, die automatisiert aus älteren Dokumentationen übernommen werden. Die Untersuchung konnte nicht klären, welcher Anteil der Fehler aus menschlichen Tippfehlern und welcher aus KI-generierten Inhalten stammte.
Für Organisationen im DACH-Raum kommen Datenschutz und regulatorische Pflichten hinzu. Führt ein Agent fremden Code mit Zugriff auf personenbezogene Daten oder kritische Systeme aus, können daraus Anforderungen nach DSGVO und NIS-2 berührt werden. Entscheidend sind die konkrete Umgebung, der Datenzugriff und die Rolle des Unternehmens.
Der Vorfall ist auch für eigenentwickelte KI-Lösungen relevant. Weniger Abhängigkeit von einem SaaS-Anbieter bedeutet nicht automatisch mehr Sicherheit. Wer Agenten selbst betreibt, übernimmt zugleich die Verantwortung für Isolation, Paketprüfung, Protokollierung und kontrollierte Berechtigungen.
Welche zusätzlichen Schutzmechanismen Anthropic, OpenAI oder Nous Research in ihre Agenten einbauen wollen, ist bislang offen. Bis dahin sollte nicht das Modell darüber entscheiden, ob gelesene Dokumentation zu einem ausgeführten Terminalbefehl wird.