Wie öffentliche llms.txt-Dateien es Forschern ermöglichen, Code in großen Unternehmen auszuführen.

Forscher haben ungenutzte Paketnamen aufgezeichnet, die offizielle llms.txt-Dateien den KI-Agenten mitteilten, installieren zu sollen, und der Code wurde innerhalb weniger Minuten in großen Unternehmen ausgeführt. Warum Daten heute zu Code geworden sind.

Verlag: REACTAPP.TOPAuf dieser Website hinzugefügt 23. Okt. 20269 Min. Lesezeit2017 Wörter

Quellen: Data Became Code: We Ran Code Inside Fortune 500s Using Files They Published for AI Agents

Wenn eine veröffentlichte Datei zu einer Anfrage wird

Ein Sicherheitsforschungsteam berichtete, dass eine Maschine in einem Fortune 500-Unternehmen Code ausführte, den sie selbst veröffentlicht hatten, und dass dies etwa vier Minuten nach dem Veröffentlichungstermin des Codes geschah. Weitere Anfragen kamen innerhalb einer Stunde. Laut ihren Angaben hat niemand einen CVE ausgenutzt, Mitarbeiter gehackt oder das Netzwerk betreten. Die Forscher notierten einige Namen offizieller, über HTTPS bereitgestellter Dateien, die von den Unternehmen selbst veröffentlicht wurden und bereits KI-Agenten anwiesen, diese zu verwenden.

Diese Dateien waren öffentlich und die dahinterstehenden Namen wurden nicht beansprucht. Die Agenten taten genau das, wofür sie konzipiert waren. Dasselbe Team gibt außerdem an, bei der großflächigen Scannung dieser Dateien auf einen bereits offenen Angriff gestoßen zu sein: eine Anleitungsdatei eines Lieferanten, die die Agenten auf bestätigten bösartigen Code lenkte. Dieser Fall wird weiter unten erläutert.

Zuerst der Hintergrund.

Warum llms.txt hier wichtig ist

Über weite Teile der Web-Geschichte war eine Seite auf einer Website einfach nur eine Seite. Jemand konnte sie lesen, ein Crawler konnte sie indizieren – doch niemand betrachtete sie als Befehl. Das gilt heute nicht mehr.

Unternehmen platzieren nun eine neue Art von Datei im Wurzelverzeichnis ihrer Websites, neben robots.txt: llms.txt – manchmal auch die längere Version llms-full.txt. Es handelt sich dabei weder um eine Sitemap noch um eine Rechennotiz. Stattdessen dient es als sorgfältig zusammengestellte Anleitung für KI-Agenten darüber, was gelesen werden soll, welche APIs aufgerufen werden müssen, welche Pakete installiert werden sollen und welche Domains vertrauenswürdig sind. Die großen Modellentwickler veröffentlichen ihre eigenen Versionen, und Googles Lighthouse-Tool in den Chrome DevTools bietet nun eine Überprüfung unter „agentic browsing“, die Websites dazu anregt, eine solche Datei bereitzustellen. Die Anzahl dieser Dateien nimmt stetig zu.

Das Team machte sich daran herauszufinden, wie weit sich diese Anweisungsschicht ausgebreitet hatte. Ihre Zählung: 8.565 llms.txt-Dateien auf 6.214 aktiven Domains, von insgesamt etwa 15.000 erfassten Unternehmen. Zu den Veröffentlichern gehörten große Konzerne, Technologiegiganten, Fintech-Unternehmen sowie Rüstungsunternehmen.

Eine typische Datei leitet einen Agenten zu Dokumentation, einem Changelog und einem Community-Forum sowie anschließend zu einer Installierungsanweisung – ähnlich wie ein pip install für das SDK des Unternehmens. Sie wirkt hilfreich und offiziell und stammt über HTTPS vom eigenen Domain des Unternehmens. Ein KI-Programmieragent, der mit diesem Produkt integriert werden soll, liest diese Anweisung und führt sie aus.

Die folgende Frage war fast peinlich einfach: Wer besitzt eigentlich diesen Paketnamen auf PyPI? Immer wieder lautete die Antwort: niemand. Der Name befand sich in einer offiziellen Datei des Herstellers, und das Paket, auf das er verweisste, wurde nie beansprucht. Wer zuerst kommt, mahlt zuerst.

Die Forscher überprüften zunächst einige weitere Dateien, dann Hunderte und schließlich die meisten – überall sahen sie dasselbe. Die Installationsanleitungen nannten Pakete und Domains, die von niemandem registriert worden waren. Nach ihren Worten waren diese weder „potenziell anfällig“ noch etwas anderes, sondern einfach nur verfügbar. Es handelt sich auch nicht um Typosquatting. Die Namen in den Dateien sind korrekt geschrieben, sodass es keinen Tippfehler gibt, den man erkennen könnte – schließlich fanden die Registrierungen nie statt.

Wie Code in großen Unternehmen zum Laufen kam

Das Team wählte eine kleine Anzahl von Paketnamen aus, die in den llms.txt-Dateien bekannter Firmen vorkamen, und registrierte sie auf PyPI sowie npm. Jedes Paket enthielt einen harmlosen „Phone-Home“-Mechanismus, ein minimales Signal, das mitteilte, dass eine Installation in der von den Forschern kontrollierten Infrastruktur stattgefunden hatte. Danach warteten sie.

Der erste Rückruf erfolgte innerhalb von weniger als vier Minuten. Konkret hatte irgendwo in einem Unternehmen im Wert von mehreren hundert Milliarden Dollar ein KI-Agent die Datei llms.txt auf der Unternehmenswebsite gelesen, eine Zeile mit pip install gefunden und diese ausgeführt. Das Paket stammte tatsächlich von PyPI, wie in der Datei angegeben, obwohl es sich um das Paket der Forscher handelte. Der zweite Rückruf von einem Fortune-500-Unternehmen kam innerhalb einer Stunde, und weitere Dutzende folgten von Start-ups sowie Unternehmen – einige davon mit Sicherheitsteams, die größer waren als das gesamte professionelle Netzwerk der Forscher.

Ihre Zusammenfassung lautet, dass sie die Sicherheit von niemandem durchbrochen haben, sondern eine Vertrauenskette ausgenutzt haben.

Wie Agenten auf diese Dateien allein stoßen

Dann wurde im Experiment untersucht, wie wenig Anleitung erforderlich ist. Die Forscher probierten fünf verschiedene Konfigurationen an zwei agentbasierten CLIs aus, gaben jedem von ihnen denselben Satz 100 Mal und enthielten diesen außer dem Namen eines Anbieters nichts. Der Satz bat den Agenten, alle Dokumente dieses Anbieters zu verwenden, um ein Node.js-Projekt mit dessen SDK zu erstellen und auszuführen.

Das war die gesamte Anweisung. Sie enthielt weder eine URL noch einen Link zu Dokumentationen und keine Erwähnung von llms.txt. Es gab weder Prompt-Injektion noch einen Angreifer im Kreislauf sowie kein Social Engineering. Der Agent fand den Anweisungskanal von selbst, denn genau dafür wurde er entwickelt – um die offizielle Dokumentation eines Anbieters ausfindig zu machen. Das Team zählte, wie viele der 100 Ausführungen pro Konfiguration zu llms.txt führten, sah dort den Befehl und installierte ein Paket, das niemand zuvor registriert hatte.

Die Pakete waren aus Designgründen inaktiv, lediglich ein Signalgeber. Alles bis zu diesem Punkt war kontrollierte Forschung. Was folgt, ist ein separates Vorkommnis, das bei der Analyse des Korpus aufgetaucht ist.

Ein Fall, der bereits in der Praxis vorkommt

Eine Entdeckung ließ das Team erstarren, denn es geschah bereits in der Realität.

Clerk, ein Authentifizierungsanbieter, dessen SDKs in einem großen Teil der produktiven Next.js-Anwendungen verwendet werden, veröffentlicht Dokumentationen, die für KI-Agenten geschrieben sind. Ein Agent, der dieser Spur folgt, gelangt zu Clerks llms.txt mit Anleitungen zur Behebung von Authentifizierungsproblemen, das folgenden Befehl enthält:

npx clerk-next-fix-auth-protection

Der Agent liest das und führt es aus, was bei Anweisungen direkt vom Anbieter kaum überraschend ist.

Das Problem liegt nicht in einem falsch geschriebenen Paketnamen. Der reine Befehl clerk-next-fix-auth-protection ist das Binärdatei, das im scoped Paket @clerk/eslint-plugin von Clerk enthalten ist. In den Dokumentationen wird empfohlen, dass die Agenten zunächst das scoped Paket installieren und anschließend den reinen Befehl aufrufen. Wenn der reine Befehl jedoch vor der lokalen Installation des Pakets ausgeführt wird, sucht npx nach dem Namen im öffentlichen npm-Registry – wo Clerk es niemals als eigenständiges Paket veröffentlicht hat.

Jemand anderes hat es stattdessen registriert. Laut der Beschreibung der Forscher enthält das Paket keinen funktionsfähigen Code, doch sobald es installiert wird, aktivieren sich Hooks, die bei jeder Installation den Benutzernamen des Installers, den Maschinennamen, das Arbeitsverzeichnis sowie ein Zeitstempel an einen externen Server senden. Es ist unter CWE-506, eingebetteter bösartiger Code, als MAL-2026-11069 katalogisiert und wurde von Google’s OSV.dev sowie Amazon Inspector als gefährlich markiert. Die Dokumentation, die offene Schleife sowie die automatische Ausführung wären unverändert, egal ob der Payload einen Benutzernamen abruft oder eine vollständige Hintertür einbaut. Das Verteilungsmechanismus ist die Schwachstelle, der Payload hingegen lediglich eine Wahlmöglichkeit.

Die Forschungsergebnisse wurden dem Sicherheitsteam von Clerk mitgeteilt, das schnell reagierte und das Problem behebte. In der Darstellung wird betont, dass dies keine Kritik an Clerk darstellt. Eine Dritte Partei hat das Paket registriert, indem sie die Namensverwechslung von npx ausnutzte, und Clerk hatte keinerlei Kontrolle darüber. Das Team präsentiert dies als ein bestätigtes Beispiel für ein strukturelles Problem, das jeden Anbieter betrifft, der dokumentationen veröffentlicht, die von Agenten gelesen werden können.

Warum aktuelle Kontrollmechanismen es möglicherweise nicht erkennen

Jedes Signal, auf das eine Sicherheitskonfiguration angewiesen ist, weist in diesem Fall in die falsche Richtung. Ein Agent, der auf llms.txt stößt, sieht eine über HTTPS vom offiziellen Domainnamen bereitgestellte Datei im Standardformat, das für die Verwendung durch KI-Systeme vorgesehen ist und von dem Unternehmen oder einem vertrauenswürdigen Partner veröffentlicht wurde. Der Agent hat kaum Grund, daran zu zweifeln, da die Datei per Design als Autorität gilt.

Sollte die Datei also vorschreiben, ein tool mit internem Erscheinungsbild zu installieren, hält der Agent nicht inne, um zu überprüfen, ob der Name zur Firma gehört. Er prüft weder den PyPI-Namenraum noch stellt er fest, dass ein Dokumentationslink auf eine Domain verweist, deren Registrierung bereits vor drei Monaten abgelaufen ist. Er tut einfach das, was in der Datei steht.

Auch Vertrauen ist transitiv. Die Datei llms.txt muss nicht auf der Website des Zielunternehmens vorhanden sein. Agenten beziehen den Kontext von vertrauenswürdigen Dritten wie den Dokumenten eines Partners, der SDK-Referenz eines Anbieters oder der Einrichtungsseite eines Community-Projekts. Wenn der Agent diesem Dritten vertraut und dessen Datei auf ein ungenutztes Paket verweist, funktioniert die Kette genauso.

Auch die Endpunkterkennung zeigte keine Reaktion. Für ein EDR-Tool oder einen Proxy sieht das so aus, als würde ein Entwickler einen legitimen Paketmanager verwenden: eine pip install-Anweisung gegenüber pypi.org, einer Domain, die jeder Unternehmensproxy erlaubt, wobei ein von dem Unternehmen absichtlich eingesetzter Programmieragent als Elternprozess dient. Es gibt weder Anomalien noch Warnungen. Der Fehler liegt weiter oben, im Übergang zwischen Anweisung und Ausführung, und der Endpunkt kann ihn nicht erkennen, weil ihm nie die richtige Frage gestellt wurde.

Daten in Code umgewandelt

Seit Jahrzehnten wurde Inhalt von Menschen konsumiert. Heute sind KI-Agenten oft die Ersten, die ihn lesen, interpretieren und darauf reagieren. Das ist der Kategorienfehler, in den die Branche gemeinsam geraten ist: Die Grenze zwischen Daten und Code ist zusammengebrochen. Alles, was auf Ihrer Website zu finden ist, ist nicht mehr nur Inhalt – es handelt sich dabei um Betriebsdaten, im Grunde Code, der in der Umgebung eines anderen mit den jeweiligen Berechtigungen des Agenten ausgeführt wird.

Das widerlegt eine alte Annahme. Seiten und Dokumente galten früher per Definition als risikofrei, weil man sie nicht als ausführbaren Code betrachtete und daher auch keine Ressourcen für ihre Integrität einplanen musste. Wenn Daten Code sind, wird die Datensicherheit zu einem Posten im Sicherheitsbudget.

Mehr als nur eine Datei

llms.txt ist nicht die gesamte Angriffsfläche. Es handelt sich dabei um den ersten Riss, der zeigt, dass sich die Grundlage verändert hat. Jede Fläche, an die ein Agent angeschlossen ist, wird zu einem Ort, an dem Anweisungen eintreffen können – und keiner dieser Orte wurde mit Integritätsprüfungen ausgestattet.

Betrachten Sie, was ein Agent tatsächlich aufnimmt: offizielle GitHub-Repositorien, Dokumentationen, Communities und Foren, Ihre Tickets sowie Ihre E-Mails. Seit zwanzig Jahren handelte es sich dabei um für Menschen geschriebene Inhalte, und niemand führte Integritätskontrollen ein, weil diese Inhalte nichts anrichten konnten. Diese Welt existiert nicht mehr. Der gesamte Datensatz, den Agenten verarbeiten, ist stillschweigend zu einer Ausführungsfläche geworden.

Das eigentliche Thema ist weder eine Datei noch ein Registry-System. Die Daten selbst haben ihr Wesen verändert, und die Sicherheitsbranche holt immer noch auf.

Die Zahlen hinter der Forschung

Größe des Korpus: 8.565 llms.txt-Dateien von 6.214 aktiven Domains, ausgewählt aus einer Liste von etwa 15.000 Unternehmen.
Mehr als 237 unbeantragte Objekte, die als Installations- oder Einrichtungsanleitungen bezeichnet werden: Paketnamen, Domains und Unterdomains. Jedes davon war etwas, das die Forscher sagen, sie hätten beanspruchen können – die meisten kostenlos.
Sechs Ökosysteme wurden betroffen: PyPI, npm, RubyGems, NuGet, crates.io und Packagist. Auf der Domain-Seite waren abgelaufene .dev- und .io-Namen sowie verwaiste Unterdomains auf Render, Vercel, Fly und Netlify enthalten, alle zur Verfügung stehend.

Was Verteidiger daraus lernen können

Die Forscher beschreiben llms.txt als nur den ersten Ansatz, den sie verfolgt haben, und erwarten, dass weitere Fehlermöglichkeiten auftauchen werden. Aus ihren Berichten ergeben sich einige praktische Erkenntnisse:

Überprüfen Sie Ihre eigenen Dateien, die für Agenten bestimmt sind. Jeder in diesen Dateien erwähnte Paketname, Domain und Subdomain muss registriert, im Besitz von Ihnen sein und überwacht werden.
Führen Sie die in der Dokumentation angegebenen Befehle mit dem spezifizierten Paketnamen aus. Ein reiner Binärnamen kann auf ein öffentliches Registry-System verweisen, falls eine lokale Installation noch nicht stattgefunden hat.
Betrachten Sie die von Ihren Agenten verarbeiteten Dokumente Dritter als Teil der Lieferkette, da das Vertrauen von ihnen ausgeht.
Vergessen Sie nicht, dass herkömmliche Endpunkt-Tools eine normale Paketinstallation wahrnehmen und diese nicht als problematisch markieren, weshalb die Kontrollen bereits früher, bei den Anweisungen und der Abfrage im Registry-System, erfolgen müssen.

Laut der Offenlegungserklärung wurde im Experiment kein Schaden verursacht. Es wurden keine persistierenden Elemente eingesetzt, keine Daten abgerufen, und die Ergebnisse werden den betroffenen Organisationen verantwortungsvoll mitgeteilt. Die Firmennamen werden solange zurückgehalten, bis die Behebung abgeschlossen ist.