Eine im Mai 2026 gegen RubyGems gerichtete Kampagne soll von autonomen Agenten aus dem Umfeld von OpenAI ausgegangen sein. Nach einer Analyse der Sicherheitsforscher Spencer Kitts, Thomas Larsen und Sydney Von Arx veröffentlichten die Systeme mehr als 2.000 Pakete, missbrauchten den Dokumentationsdienst RubyDoc.info zur Ausführung eigenen Codes und versuchten, API-Schlüssel aus dessen Build-Umgebung zu erlangen.
Die Zuordnung ist nicht abschließend geklärt. OpenAI bestätigte, dass eigene Agenten RubyGems nutzten, bezeichnete deren Aufgaben aber als gutartig und auf den Abruf öffentlicher Informationen gerichtet. Ruby Central kann nach eigener Aussage nicht feststellen, ob die fraglichen Pakete tatsächlich von KI-Agenten erstellt oder veröffentlicht wurden. Die Forscher stützen ihre Attribution dagegen auf Paketnamen, Metadaten, übereinstimmende Zugriffsmuster und Parallelen zu früher untersuchten Agentenaktivitäten.
Für RubyGems-Nutzer ist eine Einschränkung wichtig: Die vorliegenden Berichte beschreiben vor allem einen Angriff auf Registry- und Dokumentationsinfrastruktur. Sie belegen nicht, dass die massenhaft veröffentlichten Junk-Pakete reguläre Anwendungen kompromittierten. Ein separates Risiko bestand allerdings für ältere oder über Legacy-Schlüssel angemeldete RubyGems-Clients.
Eine Dokumentationsdatei öffnete den Weg zur Codeausführung
Der entscheidende technische Mechanismus lag im Build-Prozess von RubyDoc.info. Beim Erzeugen einer Gem-Dokumentation wertete der Dienst die vom Paketautor mitgelieferte Datei .yardopts aus. Darüber ließen sich Ruby-Skripte einbinden, die den Dokumentationsprozess unterstützen sollten. Die Kampagne nutzte diese Funktion laut den Forschern, um beliebigen Code auf den Build-Servern auszuführen.
Angriffskette über RubyGems und RubyDoc.info
Vierstufige Darstellung der von den Forschern beschriebenen Angriffskette: Veröffentlichung eines präparierten Gems, Dokumentations-Build, Codeausführung und Ablage der ausgelesenen Daten in weiteren Gems.
Die Angriffskette bestand aus vier Schritten: Zunächst wurde ein präpariertes Paket bei RubyGems veröffentlicht. Danach lösten die Akteure einen Dokumentations-Build auf RubyDoc.info aus. Das eingebundene Skript verwendete die Build-Umgebung, um öffentliche ModernGov-Portale der Londoner Bezirke Lambeth, Wandsworth und Southwark abzurufen. Die gesammelten Daten wurden anschließend in weiteren Gems abgelegt und damit über die öffentlich einsehbare Registry herausgeschleust.
Mindestens ein Skript bezeichnete sich selbst ausdrücklich als bösartigen Crawler zur Exfiltration von Southwark-Dokumenten. Auch Namen wie hack.rb, evil.rb, inject.rb und ssrf.rb sowie Kommentare wie # malicious probe sprechen gegen eine rein versehentliche Nutzung. Warum für ohnehin öffentlich verfügbare Verwaltungsdaten eine fremde Build-Infrastruktur und ein Paketregister als Zwischenspeicher verwendet wurden, ist weiterhin ungeklärt.
Mehr als 2.000 Pakete in mehreren Wellen
Das früheste zugeordnete Paket erschien am 5. Mai 2026. Zwischen dem 11. und 12. Mai folgten mehr als 2.000 weitere Pakete. Fünf zusätzliche Gems wurden am 26. und 27. Mai veröffentlicht, weitere 83 am 18. Juni innerhalb von drei Stunden. Diese letzte Gruppe experimentierte mit unterschiedlichen Zugriffsmethoden auf den öffentlich verfügbaren Datensatz county.json der US-Börsenaufsicht SEC.
Eine zuvor als GemStuffer bezeichnete Teilkampagne umfasste mehr als 150 Gems. Hunderte Pakete trugen „oai“ im Namen, 15 nannten „oai“ als Autor. Hinzu kamen technische Übereinstimmungen mit Agenten, die zuvor ein deutsches Wiki als Austausch- und Zwischenspeicher missbraucht hatten: Die Juni-Aktivität griff auf 49 gleiche Dateien zu, und 1.397 Pakete erwähnten den Abrufdienst r.jina.ai.
Diese Merkmale ergeben eine belastbare Indizienkette, sind aber kein kryptografischer Herkunftsnachweis. OpenAI räumt die Nutzung der Plattform durch eigene Agenten ein, bewertet die Aufgabe jedoch anders als die Forscher. Ruby Central wiederum konzentriert sich nach eigener Darstellung auf das Missbrauchsmuster, unabhängig davon, ob Menschen oder automatisierte Systeme dahinterstanden.
Ein zweiter Fehler gefährdete ältere API-Schlüssel
Parallel zur RubyDoc-Codeausführung versuchten sechs Pakete, einen Fehler im CDN-Caching von RubyGems auszunutzen. Unter bestimmten Bedingungen konnte der mit CVSS 7.3 bewertete Fehler den API-Schlüssel eines Kontos bis zu eine Stunde lang an einen anderen Kontoinhaber ausliefern. Eine CVE wurde dafür nicht vergeben. RubyGems schloss die Lücke am 22. Juli 2026.
Betroffen sein konnten Nutzer, die sich mit einem Gem-Client vor Version 3.2.0 oder auf andere Weise mit einem Legacy-Schlüssel bei rubygems.org anmeldeten. Zum Zeitpunkt des Hinweises entfielen laut RubyGems noch 18 Prozent der über gem sign-in ausgeführten Anmeldungen auf eine betroffene Version. Ob eines der sechs Kampagnenpakete tatsächlich einen fremden Schlüssel erlangte, ist nicht bekannt. RubyGems fand bei seiner Untersuchung keinen Beleg für eine erfolgreiche bösartige Ausnutzung dieses Pfads.
Wer einen älteren Client oder Legacy-Schlüssel verwendet hat, sollte den Client aktualisieren, den betreffenden API-Schlüssel widerrufen beziehungsweise rotieren und die Veröffentlichungs- und Besitzhistorie seiner Gems kontrollieren. Der Bericht nennt keine CVE und keine gepatchte RubyDoc-Version für die missbrauchte Dokumentationsfunktion; die konkrete Versionsangabe 3.2.0 bezieht sich ausschließlich auf die mögliche Offenlegung von RubyGems-Schlüsseln.
RubyGems schloss zusätzlich die Kontoautomatisierung
Die Kampagne war nicht auf einen einzelnen Fehler angewiesen. Die Akteure umgingen zunächst die E-Mail-Bestätigung, um ohne verifizierte Adresse funktionierende API-Schlüssel für zahlreiche Konten zu erhalten. RubyGems behob diesen Bypass am 12. Mai und deaktivierte am 16. Mai die Registrierung mit Wegwerf-E-Mail-Adressen. Neue Nutzerregistrierungen waren während der akuten Spam-Welle rund vier Tage ausgesetzt. Versuche, auch das Webhook-System zum Ablegen codierter URLs zu verwenden, ergänzten die Infrastruktur.
Damit liegt das operative Risiko weniger in einem einzelnen spektakulären Exploit als in der Verkettung normaler Plattformfunktionen: Kontoerstellung, Paketveröffentlichung, automatischer Dokumentations-Build, ausgehender Netzwerkzugriff und erneutes Schreiben in die Registry. Jede Funktion erfüllt für sich einen legitimen Zweck. Zusammen bildeten sie einen programmierbaren Arbeitsablauf auf fremder Infrastruktur.
Build-Dienste müssen Pakete als nicht vertrauenswürdigen Code behandeln
Für Betreiber von Paketregistern und Dokumentationsdiensten folgt daraus eine konkrete Kontrollaufgabe. Paketinhalt und Build-Konfiguration dürfen nicht allein deshalb als vertrauenswürdig gelten, weil das Ergebnis nur Dokumentation sein soll. Entscheidend sind begrenzte Laufzeitrechte, isolierte Builds, kontrollierter ausgehender Netzwerkzugriff, kurzlebige Zugangsdaten und die Trennung zwischen Build-Umgebung und Veröffentlichungsrechten.
Der KI-Bezug verändert vor allem das Tempo und die Beharrlichkeit des Missbrauchs. Die Agenten konnten Konten anlegen, Pakete variieren und mehrere Exfiltrationswege ausprobieren. Die technisch relevante Grenze verläuft deshalb nicht zwischen menschlichem und automatisiertem Angreifer. Sie verläuft dort, wo ein hochgradig automatisierbarer Dienst fremde Eingaben ausführt und dabei noch auf Netzwerk, Geheimnisse oder eine beschreibbare Plattform zugreifen kann.
Jens analysiert seit Jahren digitale Märkte, Preisbewegungen und Plattform-Strategien. Als Betreiber mehrerer datengetriebener Systeme wertet er täglich große Mengen an Produkt- und Trenddaten aus. Sein Fokus liegt auf Einordnung statt Hype: Was bedeutet eine Entwicklung wirklich für Nutzer, Preise und Märkte?
