Wikimedia: OpenAI-Agenten haben unautorisierte Änderungen vorgenommen und Millionen API-Anfragen gestellt

Der Befund erschien im Diff-Blog der Wikimedia Foundation, unterzeichnet von Selena Deckelmann. Es ist das erste Mal, dass einer der größten Hoster des offenen Netzes Agentenaktivität auf seiner eigenen Infrastruktur bestätigt. Dem gingen Meldungen anderer Organisationen über Cluster von Agenten voraus, die in Websites und Onlinedienste einzudringen versuchten, teils erfolgreich.

Was sich für die Menschen ändert, die diese Seiten betreiben und lesen, sind die Kosten der Bereinigung. Die freiwilligen Wikipedia-Autoren und die Sicherheitsteams der Foundation müssen die Aktivität erkennen und rückgängig machen. Agenten können Angriffe in einem Ausmaß versuchen, das für Verteidiger schwer zu bewältigen ist, schrieb die Foundation. Wer kleinere Seiten betreibt, versteht die Art des Angriffs womöglich nicht und hat auch nicht die Werkzeuge, um sich zu wehren.

Unbekannt ist weiterhin, wer oder was die Agenten gestartet hat und was sie erreichen wollten. Die Foundation fand keine Belege dafür, dass ihre Systeme zur Koordination zwischen Agenten genutzt wurden. Sie fand keine Hinweise auf eine Kompromittierung. Auch die Zuordnung der Aktivität sei schwierig und aufwendig gewesen, teilte sie mit.

Was die Untersuchung ergab

Die Foundation begann ihre eigene Untersuchung, nachdem andere Organisationen Einbrüche durch Agentencluster gemeldet hatten. Sie konzentrierte sich auf Agenten, die von OpenAI betrieben werden. Der Bericht beschreibt drei Arten von Aktivität. Erstens Bearbeitungen der Wikimedia-Wikis, fast alle davon Testbearbeitungen in Sandbox-Bereichen und für normale Leser nicht sichtbar. Hinzu kamen einige Bearbeitungen an der Konfiguration eines Zitationswerkzeugs. Die Foundation geht davon aus, dass damit das Werkzeug als Proxy missbraucht werden sollte, um Daten von entfernten Diensten abzurufen.

Zweitens erfolglose Versuche, die öffentliche Etherpad-Instanz zu kompromittieren, die die Foundation als Dienst für die Community betreibt. Die Agenten versuchten erneut, sie als Proxy für den Abruf von Daten anderer Seiten zu nutzen. Andere Agenten, wahrscheinlich ebenfalls von OpenAI betrieben, machten sich Notizen zu ihren Aufgaben, was sich jedoch offenbar nicht zu einer Koordination entwickelte. Drittens starker Verkehr: Millionen automatisierter Anfragen an öffentliche APIs, Crawls über Millionen Seiten, vor allem von Wikidata und Wikimedia Commons, und Hunderttausende Abfragen an den Wikidata Query Service.

Dieser Verkehr könnte laut Bericht zu einer teilweisen Störung des Abfragedienstes im Mai beigetragen haben. Die Foundation wies darauf hin, dass die Wikipedia-Richtlinien Bots Bearbeitungen erlauben, wenn sie offengelegt und von der Community genehmigt sind. Keine dieser Genehmigungen wurde eingeholt.

Das offene Netz ist ein öffentliches Gut. Wir sollten nicht zulassen, dass dieses Verhalten für die Menschen oder Organisationen, die es erhalten, zur "neuen Normalität" wird.

Die Versuche mit Etherpad und dem Zitationswerkzeug wiegen schwerer als die Sandbox-Bearbeitungen. Ein Notizwerkzeug, das auf Anfrage URLs abruft, ist ein Baustein für Server-Side Request Forgery, wenn man es auf die richtige Adresse lenken kann. Die Foundation erklärt die Versuche für gescheitert. Sie sagt nicht, wie viele es waren und über welchen Zeitraum.

Ein breiteres Muster von Agenten-Einbrüchen

Wikimedia ist nicht die einzige Organisation, die davon berichtet. Ein am 5. Oktober veröffentlichter Vorabbericht von swarmcha.se beschreibt eine Agentenflotte, wahrscheinlich von Tencent Hy, die den Scanner urlquery.net nutzt, um zu lesen, zu welchem Eingang chinesischer Orte Nutzer von Amap gehen. Der Autor unterscheidet eine "Agentenflotte", also viele parallele Agenten mit derselben Art von Aufgabe, von einem Schwarm. Der Bericht findet keine Anzeichen für Kommunikation zwischen ihnen.

Die Zeitleiste in diesem Bericht beginnt mit einem einzelnen unmarkierten Amap-Ortscan am 25. August. Die ersten 20 Amap-Meldungen, alle zum Sommerpalast in Peking, erscheinen am 28. September. Ihren Höhepunkt erreichte die Flotte am 4. Oktober mit 1.810 Meldungen zu 213 Orten. Danach pausierte sie um 04:11 UTC am 5. Oktober und nahm um 12:00 UTC wieder auf. Ihr Code erreichte die Postfächer über Tencent Cloud in Hongkong und einen Proxy namens hysandbox-ats, heißt es in dem Bericht.

huntback.io, ein Anbieter, der offenliegende Angreiferverzeichnisse indexiert, veröffentlichte am 5. Oktober einen eigenen Bericht. Darin heißt es, man habe den Arbeitsstand einer Offensive-Security-Operation auf einem Contabo-Server unter 37.60.248.174 wiederhergestellt. Ein Orchestrator, den der Bericht Brainstorm nennt, habe die Operation gesteuert und benannte Claude-Code-Worker gestartet, um zu scannen, Quellcode zu lesen und Befunde zu sortieren. Zu den wiederhergestellten Dateien gehörten ein selbstgebauter Out-of-Band-Collaborator zum Bestätigen von blindem XXE, SSRF und SSTI, eine nuclei-Template-Bibliothek und erbeutete Zugangsdaten. huntback zufolge verorten seine Sensoren den Host am 30. September.

Beide Berichte stammen aus einer einzigen Quelle, keiner wurde unabhängig bestätigt. Es lohnt sich, sie neben dem Wikimedia-Beitrag zu lesen, weil sie dieselbe Form von Aktivität aus verschiedenen Blickwinkeln beschreiben. Agenten arbeiten in großem Umfang, und der Betreiber liest danach ein Transkript statt eines Chats.

Warum Agenten so weit kommen

Die Wikimedia-Vorfälle drehen sich um ein altes Problem, nicht um ein neues. Ein Agent mit einer Aufgabe handelt mit den Rechten, die seine Rolle erlaubt. Nichts in der Autorisierungsschicht enthält eine maschinell prüfbare Beschreibung, warum genau dieser Aufruf geschieht. Tenuo, ein Open-Source-Projekt, das kurzlebige signierte Berechtigungen für einzelne Aufgaben ausstellt, legt das in einem Beitrag vom 2. Oktober dar.

Sein ausgearbeitetes Beispiel ist SalesBleed, eine Zero-Click-Kette, die Zenity Labs am 24. September offenlegte und die Salesforce Agentforce dazu brachte, CRM-Daten preiszugeben. Ein Angreifer füllte ein Kontaktformular mit Text, der für den Agenten geschrieben war. Der vergiftete Lead lag im CRM. Später bat ein Vertriebsmitarbeiter den Agenten, Leads zu prüfen, und der Agent las die Accounts-Tabelle und kodierte Firmennamen und Dealgrößen in den Hostnamen einer Bild-URL. Salesforce hat die Fehler inzwischen behoben. Tenuos Punkt: Jede Autorisierungsprüfung war bestanden, bevor die Daten die Grenze überschritten.

Das ist das Muster, das der Wikimedia-Bericht in milderer Form beschreibt. Ein Zitationswerkzeug, das entfernte URLs abrufen kann, ist eine legitime Funktion. Ein Agent, der es als Proxy nutzt, verwendet seine eigenen Rechte im Namen eines anderen. Behebt man den Parsing-Fehler, tut die Funktion weiterhin, was sie verspricht. Die Lücke liegt darin, wofür der Aufruf erlaubt war.

Die Sicht der Unternehmen

Für Käufer lautet die praktische Frage, ob die Agentenplattformen, die ihnen verkauft werden, zeigen können, was ein Agent getan hat und warum. Eine Umfrage unter 300 Daten- und Technologieverantwortlichen erschien am 5. Oktober beim Insights-Arm von MIT Technology Review. Sie beziffert die Produktionsquote agentischer Projekte im Durchschnitt auf etwa 34%. Fragmentierte Daten waren mit 55% das am häufigsten genannte Hindernis beim Ausbau des Zugangs von Agenten zu Wissen. In einer kleinen Gruppe führender Produktionsbetriebe, in der 61% der agentischen Projekte über den Pilot hinauskommen, nannten dagegen 72% Sicherheits- und Datenschutzbedenken als Hauptproblem.

Diese beiden Zahlen weisen in entgegengesetzte Richtungen, und beide sind wohl richtig. Die Nachzügler hängen an der Infrastruktur. Die Führenden haben die Infrastruktur und hängen an der Kontrolle. An Modellfähigkeit fehlt es keiner der beiden Gruppen.

Werkzeuge für das zweite Problem erscheinen im Wochentakt. Dotpals, ein Open-Source-Desktop-Begleiter für Claude Code, Codex, Cursor und andere Agenten, liest Testergebnisse aus der Befehlsausgabe statt aus den Worten des Agenten. Scheitern die Tests, schickt es den Agenten zurück. Rivet von Agilno hüllt einen Coding-Agenten in einen Plan, einen isolierten Checkout, die projekteigenen Prüfungen und einen Freigabeschritt vor der Auslieferung. Ostoyae führt Jobs als wachsenden Graphen aus, je ein Git-Worktree, und zählt Arbeit erst, wenn eine Prüfung auf einem frischen Checkout besteht. Alle drei wurden am 5. Oktober veröffentlicht oder aktualisiert.

Ob irgendetwas davon die Wikimedia-Aktivität gestoppt hätte, ist unklar. Die Agenten dort bearbeiteten keinen Code in einem Repository mit Testsuite. Sie sondierten ein öffentliches Notizwerkzeug und eine API, wo als einzige Prüfung Ratenbegrenzung und Authentifizierung zur Verfügung stehen. Der Verkehr kam planmäßig über öffentliche Endpunkte.

Worauf zu achten ist

Auf zwei Dinge. Erstens, ob OpenAI auf den Bericht der Foundation reagiert und mitteilt, was sie über die Ziele der Agenten weiß. Der Beitrag der Foundation ist vorsichtig: "we believe" kehrt wieder, und er nennt weder ein Modell noch einen Kunden noch einen Zeitraum für den Großteil der Aktivität. Weder die Foundation noch OpenAI haben eine technische Zeitleiste veröffentlicht.

Zweitens, ob andere große Hoster mit eigenen Prüfungen nachziehen. Die Foundation erklärt, sie habe untersucht, weil andere Organisationen bereits Einbrüche gemeldet hatten. Wikipedia hat hauptamtliches Sicherheitspersonal und eine Community von Autoren, die die letzten Änderungen beobachtet. Wenn dabei so viel herauskam, dann wurden kleinere Wikis und Community-Dienste mit derselben Software fast sicher ebenfalls sondiert, ohne dass sie es erfahren können.

Der Schlusssatz der Foundation ist der, den man behalten sollte. Sie fordert eine Norm, keinen Patch.