OpenAIs Agenten kaperten RubyGems im Mai

Am 10.09.2026 haben wir geschrieben, dass OpenAIs Agentenschwarm auch auf RubyGems unterwegs war, mit 83 Paketen als Linkablage, und dass das in diesem Fall harmlos aussah. Zwei Tage später ist diese Einschätzung überholt.

Das Nightingale Collective, dieselbe Gruppe, die den Schwarm im Grazer Wiki nachgewiesen hat, hat am 11.09.2026 einen Bericht zu RubyGems veröffentlicht. Er beschreibt einen anderen, früheren Vorgang: Im Mai 2026 haben OpenAI-Agenten über 2.000 Schadpakete in das Ruby-Paketverzeichnis geladen, sich über den automatischen Dokumentations-Build fremde Server zur Codeausführung besorgt und versucht, die API-Schlüssel anderer Nutzer zu stehlen. Das Wall Street Journal hat parallel berichtet, RubyGems hat am selben Tag Stellung genommen.

Was im Mai passiert ist

Die Zeitleiste aus dem Bericht:

Die Sicherheitsfirma Socket hatte den Vorgang im Mai unter dem Namen GemStuffer dokumentiert, damals ohne zu wissen, wer dahintersteckt. Ein Mitglied des RubyGems-Sicherheitsteams nannte ihn seinerzeit einen "major malicious attack".

Der Angriffsweg

Wer ein Gem auf RubyGems veröffentlicht, bekommt von RubyDoc.info automatisch eine gebaute Dokumentation dazu. Dieser Build wertet eine mitgelieferte .yardopts-Datei aus, und die darf auf Ruby-Skripte verweisen. Genau das haben die Agenten ausgenutzt: Sie haben über hundert Pakete so gebaut, dass der Dokumentations-Build ihren eigenen Code auf den Servern von RubyDoc.info ausführt.

flowchart TB
  PUB["Agent veröffentlicht Gem<br/>mit .yardopts und Skript"] --> BUILD["RubyDoc.info baut Doku<br/>und führt das Skript aus"]
  BUILD --> SCRAPE["Skript ruft Zielseiten ab<br/>britische Kommunalportale"]
  SCRAPE --> BACK["Daten werden als neues Gem<br/>nach RubyGems zurückgeschrieben"]
  BACK --> FETCH["Öffentlich abrufbar<br/>mit gem fetch"]
  classDef agent fill:#7F1D1D,stroke:#EF4444,color:#FCA5A5
  classDef infra fill:#1A3A4A,stroke:#00BCEC,color:#BAE6FD
  classDef out fill:#14532D,stroke:#22C55E,color:#86EFAC
  class PUB,SCRAPE agent
  class BUILD,BACK infra
  class FETCH out

Dass das der Plan war, muss man nicht erraten. In einem inzwischen zurückgezogenen Paket steht der Zweck als Kommentar über der Nutzlast: "malicious crawler/exfil for Southwark Jan 2026 docs via rubydoc.info worker". Die Ziele waren die Sitzungsportale der Londoner Bezirke Lambeth, Wandsworth und Southwark, also öffentlich zugängliche Kalender- und Tagesordnungsseiten.

Um überhaupt so viele Konten anlegen zu können, haben die Agenten zusätzlich einen Fehler in der Registrierung ausgenutzt: Konten mit unbestätigter Mailadresse bekamen funktionierende API-Schlüssel. Der Fix dafür wurde am 11.05. eingereicht und am 12.05. ausgerollt.

Der Versuch mit den fremden Schlüsseln

Der unangenehmste Teil steht weiter hinten im Bericht. Aus der gekaperten Build-Umgebung heraus haben mindestens sechs Pakete versucht, über eine damals unbekannte Lücke die API-Schlüssel fremder RubyGems-Nutzer abzugreifen.

Diese Lücke gab es wirklich, und sie wurde erst zwei Monate später gefunden. RubyGems hat sie am 22.07.2026 veröffentlicht: Ein Zusammenspiel aus Antwortkomprimierung und Cache-Headern führte dazu, dass das CDN die Antwort auf GET /api/v1/api_key zwischenspeicherte. Wer sich mit einem älteren gem-Client anmeldete, dessen frisch erzeugter Schlüssel konnte bis zu eine Stunde lang an beliebige andere Aufrufer am selben Edge-Knoten ausgeliefert werden, ohne jede Anmeldung. CVSS 4.0 Basisscore 7.3, also hoch. Nach RubyGems' eigener Schätzung war der Fehler rund neun Jahre lang da.

Für uns ist ein Detail daran besonders relevant: Betroffen sind gem-Clients älter als 3.2.0, und dazu gehört die Version, die aktuelles macOS mitliefert (3.0.3.1 unter /usr/bin/gem). Das war kein exotischer Altbestand, sondern Systemstandard.

Der Agentencode, den die Forscher zitieren, probiert vier Varianten des Endpunkts in einer Schleife durch und beschreibt sich selbst im Kommentar als "leak exfil by repeated attempts & fresh leaked keys variants". Ob einer dieser Versuche erfolgreich war, weiß niemand. RubyGems hat nach eigener Aussage ausführlich geprüft und keine Hinweise darauf gefunden, kann es aber nicht ausschließen.

Was OpenAI dazu sagt

OpenAI hat den Vorgang gegenüber Bloomberg bestätigt und ihn so eingeordnet:

Based on our review, our agents used the RubyGems platform to access the internet to carry out benign tasks and retrieve public information. We'll continue to investigate as part of our broader review of agent activity during training and evaluation.

Das Unternehmen sagt außerdem, man sei inzwischen mit RubyGems in Kontakt. Inzwischen heißt: nach der Veröffentlichung des Berichts. Vorher nicht. Die Forscher schreiben, nach ihren Gesprächen mit Leuten aus der Ruby-Community habe OpenAI RubyGems nie darüber informiert, dass die eigenen Agenten hinter der Kampagne stecken. Vier Monate lang hat die Community ein Phänomen ohne Urheber verwaltet.

"Benign tasks" ist die Beschreibung für einen Vorgang, bei dem fremder Code auf fremden Servern lief und fremde Zugangsschlüssel abgegriffen werden sollten. Dass die abgerufenen Daten selbst öffentlich waren, ändert daran nichts. Der Weg dorthin war es nicht.

RubyGems hat am selben Tag geantwortet und bleibt bemerkenswert sachlich. Das Team bestätigt die beschriebene Technik, bestätigt den Code zum Schlüsselabgriff, fand keine Belege für einen Erfolg und schreibt zur Zuordnung: Auf Basis der eigenen Daten könne man nicht feststellen, ob die Pakete von KI-Agenten stammen. Der letzte Absatz ist eine höfliche Rechnung:

Responding to abuse requires time and resources from the people maintaining package repositories, alongside their everyday work of keeping these services secure and reliable for the community.

Was das für euch heißt

Einordnung

Zwei Dinge muss man hier auseinanderhalten, sonst wird die Kritik unpräzise und damit angreifbar.

Was nicht belegt ist: dass hier eine klassische Lieferkettenattacke lief. Die Pakete zielten nicht auf Entwicklerrechner, sie hatten kaum Downloads, und Socket schrieb schon im Mai, sie wirkten nicht auf breite Kompromittierung ausgelegt. Auch die Forscher selbst finden kein schlüssiges Motiv für den Schlüsseldiebstahl und schreiben das offen hin. Wer daraus "OpenAI hat Malware unter Entwickler verteilt" macht, geht über die Quellenlage hinaus.

Was belegt ist, reicht aber völlig: Agenten eines Unternehmens haben fremde Infrastruktur zur Codeausführung missbraucht, dabei eine unbekannte Sicherheitslücke gefunden und zu nutzen versucht, einen Registrierungsfehler ausgenutzt, einen Non-Profit vier Tage in den Notbetrieb gezwungen, und das Unternehmen hat vier Monate lang niemandem gesagt, dass es das war. Erst nach der Veröffentlichung durch Dritte kam Kontakt zustande. Der Angriffsweg ist jetzt öffentlich dokumentiert und steht damit auch allen anderen zur Verfügung.

Die Frage, die daraus folgt, ist keine technische. Wenn ein Unternehmen bei einem Test die Kontrolle über seine eigenen Systeme verliert und die Kosten dieses Kontrollverlusts bei Freiwilligen landen, wer trägt sie dann? In der Softwarewelt gibt es darauf bisher keine eingespielte Antwort. Für KI-Funktionen im eigenen Produkt ist die Lage inzwischen klarer, das haben wir in Wer haftet bei Fehlern aufgeschrieben. Für Trainingsläufe, die aus der Sandbox ausbrechen und fremde Dienste beschädigen, ist sie es nicht. Solange das so bleibt, bleibt auch die Aufarbeitung dort, wo sie jetzt liegt: bei Leuten, die das unbezahlt neben ihrer eigentlichen Arbeit machen.

Was sich sofort ändern ließe, ohne dass irgendjemand ein Gesetz braucht: Wer einen Testlauf fährt, bei dem Agenten fremde Systeme anfassen, meldet das den Betroffenen. Nicht nach vier Monaten, und nicht erst, wenn es ohnehin jemand anders herausgefunden hat.