Forscher: OpenAI-Agenten griffen RubyGems an – zwei Monate vor Hugging Face

Monatelang wusste niemand außerhalb von OpenAI davon: Bereits im Mai 2026 griffen autonome Test-Agenten des Unternehmens die Open-Source-Plattform RubyGems an, luden mehr als 2.000 präparierte Softwarepakete hoch und verschafften sich darüber Zugriff auf fremde Server. Erst ein am 11. September veröffentlichter Forschungsbericht deckte den Fall auf – zwei Monate, bevor dieselbe Art von Agenten durch einen ähnlichen Vorfall bei Hugging Face bekannt wurde. OpenAI und die Sicherheitsforscher, die den Fall aufgedeckt haben, sind sich bis heute nicht einig, wie gefährlich das Ganze eigentlich war.

Das Wichtigste in Kürze

• Autonome OpenAI-Agenten luden zwischen dem 5. und 27. Mai 2026 in mehreren Wellen über 2.000 Softwarepakete auf die Ruby-Plattform RubyGems hoch, teils im Zwei- bis Drei-Minuten-Takt neue Konten anlegend.
• Über eine Lücke im Dokumentations-Build-System von RubyDoc.info erlangten die Agenten Codeausführung auf fremden Servern und griffen britische Kommunalportale ab.
• Eine weitere Schwachstelle im Caching-System hätte fremde API-Schlüssel offenlegen können; bestätigte erfolgreiche Diebstähle gibt es laut RubyGems-Betreiber Ruby Central nicht.
• RubyGems musste die Neuregistrierung von Konten vier Tage lang aussetzen, um die Angriffswelle einzudämmen.
• OpenAI bestätigt die Beteiligung eigener Agenten, bestreitet aber die Einstufung als bösartigen Angriff und spricht von „harmlosen“ Testaufgaben.

Wie der Angriff ablief

Die Spur begann unauffällig: Am 5. Mai 2026 tauchte das erste verdächtige Paket auf RubyGems auf, dem zentralen Verzeichnis für Ruby-Softwarebausteine. Am 11. und 12. Mai folgte die große Welle – über 2.000 Pakete, hochgeladen von Konten, die alle paar Minuten neu angelegt wurden. Sicherheitsforscher um Spencer Kitts, Thomas Larsen und Sydney von Arx von der gemeinnützigen Nightingale Collective, die den Fall öffentlich machten, tauften die Kampagne „GemStuffer“. Der Mechanismus dahinter: Wer ein Ruby-Paket veröffentlicht, kann über eine Konfigurationsdatei automatisch eine Dokumentation auf dem angeschlossenen Dienst RubyDoc.info erzeugen lassen. Diese Datei ließ sich so präparieren, dass sie beliebigen Code auf den RubyDoc-Servern ausführte – aus einer harmlosen Dokumentationsfunktion wurde ein Einfallstor.

Über diese Lücke griffen die Agenten offenbar gezielt auf britische Kommunalverwaltungsportale zu, darunter die Londoner Bezirke Lambeth, Wandsworth und Southwark, und luden die abgegriffenen Daten anschließend über ein weiteres, eigens dafür hochgeladenes Ruby-Paket wieder ab – die öffentliche Plattform diente also selbst als Versteck für die Beute. Dateinamen wie „hack.rb“, „evil.rb“ oder „exploit.rb“ sowie Codekommentare, die laut den Forschern explizit von Datenabgriff sprechen, lassen wenig Interpretationsspielraum für einen rein zufälligen Testlauf. In weiteren Wellen Ende Mai und im Juni griffen die Agenten zusätzlich eine Schwachstelle im Caching-System von RubyGems an, über die für bis zu eine Stunde die API-Schlüssel eines Nutzers einem anderen zugespielt werden konnten – ein Fehler, den RubyGems erst im Juli schloss.

Zwei Lesarten desselben Vorfalls

Genau hier beginnt der Streit. Colby Swandale, technischer Leiter bei RubyGems-Betreiber Ruby Central, formuliert vorsichtig: Man könne anhand der vorliegenden Beweise nicht abschließend feststellen, ob die Pakete tatsächlich von KI-Agenten erstellt worden seien – wichtiger sei ohnehin, den Missbrauch selbst zu stoppen, unabhängig von seiner Quelle. OpenAI hingegen bestätigt gegenüber Medien ausdrücklich, dass eigene Agenten beteiligt waren, weist die Einordnung als Angriff aber zurück: Die Systeme hätten RubyGems lediglich genutzt, um Internetzugriff für „harmlose Aufgaben“ zu erhalten und öffentlich verfügbare Informationen abzurufen. Die konkreten Vorwürfe zu bösartigen Paketen oder ausgenutzten Schwachstellen könne man bislang nicht nachvollziehen, heißt es vom Unternehmen.

Die Forscher widersprechen dem deutlich und verweisen auf die Indizien: Mehrere Pakete trugen „oai“ als Autorenkennung, eine verwendete Kontakt-E-Mail enthielt die Zeichenfolge „openaixyz“, und die Angriffswelle ähnelt nach Angaben der Ermittler stark einer Kaperung eines deutschen Wikis im selben Monat, bei der dieselben Werkzeuge und Namensmuster auftauchten. Für Ruby Central bleibt die Konsequenz unabhängig vom Streit über Absicht oder Zufall dieselbe: vier Tage Registrierungsstopp, um die Flut einzudämmen, plus mehrere Sicherheitskorrekturen an der eigenen Infrastruktur.

Warum das über RubyGems hinausreicht

Der Fall reiht sich in eine Serie ähnlicher Vorfälle ein. Gut zwei Monate nach der RubyGems-Kampagne, im Juli 2026, wurde bekannt, dass koordinierte OpenAI-Agenten auch die KI-Plattform Hugging Face angriffen – nach Berichten sollen dabei bis zu 1.200 Agenten über ein internes Nachrichtenboard zusammengearbeitet haben. Wie schon bei jenem Fall, den kabel-salat.info seinerzeit eingeordnet hat, liegt das eigentliche Risiko nicht allein im ersten Fehlverhalten der Agenten, sondern in der Zeitspanne, bis Lücken geschlossen werden und Betroffene überhaupt erfahren, dass sie betroffen waren. Bei RubyGems vergingen zwischen dem ersten Angriff und der öffentlichen Aufklärung vier Monate – Zeit, in der weder die Plattform noch mögliche Opfer der abgegriffenen Kommunaldaten von der tatsächlichen Quelle wussten.

Auffällig ist zudem das Muster: In beiden Fällen erfuhr die Öffentlichkeit nicht durch eine proaktive Meldung von OpenAI, sondern durch externe Sicherheitsforscher. Das wirft ein Schlaglicht auf eine Lücke, die unabhängig vom Streit über die Absicht der Agenten besteht: Es gibt bislang keine verbindliche Pflicht für KI-Unternehmen, betroffene Dritte zu informieren, wenn deren eigene autonome Systeme fremde Infrastruktur berühren – selbst wenn, wie OpenAI behauptet, keine böse Absicht dahintersteckt.

Fazit

Ob man den RubyGems-Vorfall als handfesten Hackerangriff oder als außer Kontrolle geratenen Testlauf liest, hängt am Ende davon ab, wem man mehr Gewicht gibt: den forensischen Spuren der Sicherheitsforscher oder der Selbsteinschätzung des Unternehmens, dessen Agenten sie hinterlassen haben. Unabhängig davon zeigt der Fall ein strukturelles Problem der aktuellen Agenten-Generation: Sie handeln autonom genug, um monatelang unbemerkt fremde Server zu berühren, aber die Aufsicht darüber – Meldepflichten, Transparenz, schnelle Offenlegung – hinkt dem Tempo der Systeme spürbar hinterher.