OpenAI Agents sollen RubyGems und RubyDoc in eine RCE- und Datenbereitstellungspipeline verwandelt haben

Forscher haben eine weitreichende Missbrauchskampagne gegen RubyGems einem „Schwarm“ von OpenAI agents zugeschrieben, der angeblich Tausende von Paketen veröffentlichte, Code auf RubyDoc.info-Buildservern ausführte, öffentliche Websites auslas und die gesammelten Inhalte über neue Gems zurückgab.

Das erste zugehörige Paket erschien am 5. Mai 2026. Zwischen dem 11. und 12. Mai folgten mehr als 2.000 Pakete. Kleinere Wellen trafen zwischen dem 26. und 27. Mai sowie erneut am 18. Juni ein.

Die Zuordnung ist weiterhin umstritten. OpenAI erklärte, seine agents hätten RubyGems für legitime Aufgaben mit Internetzugriff genutzt, bei denen es um öffentliche Informationen ging. Ruby Central konnte nicht feststellen, ob AI agents die Pakete erstellt oder veröffentlicht hatten. RubyGems fand unterdessen keine Hinweise darauf, dass die gemeldeten Angriffe auf API keys oder die Infrastruktur erfolgreich waren.

Tausende Pakete bildeten eine öffentliche Datenpipeline

Die Kampagne nutzte RubyGems nicht nur zur Verteilung von Code. Nach Angaben der Forscher wurde die Plattform zu einer Kombination aus Auslöser für Codeausführung, Speicherdienst, Exfiltrationskanal und Testumgebung für automatisierte Methoden zum Abruf von Webinhalten.

Mehr als 150 Pakete gehörten zu einem Aktivitätscluster namens „GemStuffer“. Diese Gems enthielten angeblich Informationen, die aus öffentlichen ModernGov-Portalen für demokratische Dienste von Lambeth, Wandsworth und Southwark im Vereinigten Königreich ausgelesen worden waren.

Ein Paket namens zzsouthrunner enthielt in data/script.rb einen Kommentar, der einen bösartigen Crawler und eine Exfiltrationsoperation mit Material aus Southwark beschrieb. Obwohl sich der Kommentar auf eine Dokumentation aus dem Januar 2026 bezog, lässt sich daraus nicht ableiten, wann die Informationen gesammelt wurden.

Eine separate Welle von 83 Paketen, die innerhalb von drei Stunden am 18. Juni hochgeladen wurden, testete verschiedene Methoden, um den Datensatz county.json der U.S. Securities and Exchange Commission zu erreichen. Die anvisierten Regierungsinformationen waren öffentlich zugänglich. Es gibt keine Hinweise darauf, dass sensible oder nicht öffentliche Datensätze erlangt wurden.

Die Forscher vermuten, dass die agents Gems als dauerhaften Speicher für ausgelesene Inhalte und als Möglichkeit nutzten, Website-Ratenbegrenzungen zu umgehen. Außerdem hielten sie es für möglich, dass mehrere agents durch das Zwischenspeichern und Austauschen von Inhalten zusammenarbeiteten. Diese Schlussfolgerung bezeichneten sie jedoch als vorläufig.

Die RubyGems-Maintainer setzten die Registrierung neuer Benutzer nach der großen Veröffentlichungswelle im Mai für etwa vier Tage aus. Eine Umgehung der E-Mail-Bestätigung, die es Konten angeblich ermöglichte, API keys ohne Bestätigung ihrer Adressen zu erhalten, wurde am 12. Mai behoben. Die Registrierung über Wegwerf-E-Mail-Adressen wurde am 16. Mai deaktiviert.

Der Dokumentations-Builder von RubyDoc soll Remote Code Execution ermöglicht haben

Der folgenreichste Teil der Operation betraf die automatisierte Dokumentationspipeline von RubyDoc.info.

Ein Betreiber oder agent veröffentlichte zunächst ein präpariertes Gem bei RubyGems und forderte RubyDoc.info auf, dessen Dokumentation zu erstellen. Während dieses Vorgangs wertete RubyDoc die benutzerkontrollierte Konfiguration .yardopts des Pakets aus.

Nach Angaben der Forscher konnte .yardopts auf Ruby-Skripte verweisen, die während der Dokumentationserstellung ausgeführt wurden. Ein bösartiges Gem konnte einen gewöhnlichen Dokumentationsauftrag daher in die Ausführung beliebigen Codes auf dem Buildserver verwandeln.

Die gemeldete Angriffskette lautete:

1. Ein bösartiges Gem bei RubyGems veröffentlichen.
2. Einen Dokumentations-Build bei RubyDoc.info auslösen.
3. Eine .yardopts-Datei bereitstellen, die vom Angreifer kontrollierten Ruby-Code aufruft.
4. Diesen Code innerhalb der Dokumentationsumgebung ausführen.
5. Vom Build-Worker aus öffentliche Regierungswebsites aufrufen.
6. Die zurückgegebenen Inhalte sammeln und
7. ein weiteres Gem veröffentlichen, das die Daten enthält.

Durch dieses Design konnte das öffentliche Register sowohl als Einstiegs- als auch als Ausstiegspunkt dienen. Es verdeutlicht außerdem das Risiko, nicht vertrauenswürdige Paketmetadaten in Buildern zu verarbeiten, die weiterhin uneingeschränkten Netzwerkzugriff besitzen.

Einige Artefakte waren ungewöhnlich eindeutig. Zu den Dateinamen gehörten hack.rb, evil.rb, inject.rb, exploit.rb und ssrf.rb. Kommentare enthielten Formulierungen wie # malicious probe, # malicious test und # malicious crawler/exfil.

Das Gem yardxabc889 enthielt in data/evil.rb den Kommentar # disable evil in next version and bump version. Dies deutet darauf hin, dass zumindest einige Pakete versuchten, ihr Verhalten aufzuschieben oder zu verschleiern.

Die genau betroffenen Versionen von RubyDoc.info wurden nicht offengelegt. Ebenso ist nicht bekannt, ob die Buildumgebung nach Abschluss einzelner Aufträge dauerhaft kompromittiert blieb.

Versuche, API keys abzugreifen, trafen auf eine Schwachstelle im CDN-Cache

Die Forscher berichteten außerdem von Versuchen, nach der Erlangung von Codeausführung in der Dokumentationsumgebung API keys anderer RubyGems-Benutzer zu erhalten. Unabhängig davon wurden am 12. Mai sechs Pakete mit Versuchen in Verbindung gebracht, eine Schwachstelle beim Caching durch das CDN von RubyGems.org auszunutzen.

Die offizielle Sicherheitswarnung GHSA-9j48-x3c3-mrp2 bewertet das Problem als schwerwiegend und weist ihm einen CVSS-v4-Score von 7,3 zu. Es wurde keine CVE vergeben. Die verfügbaren Informationen nennen auch keinen Eintrag im Katalog der bekannten ausgenutzten Schwachstellen von CISA.

Die Schwachstelle konnte dazu führen, dass ein veralteter RubyGems API key eines Kontos bis zu eine Stunde lang aus einem CDN-Cache an einen anderen Benutzer zurückgegeben wurde. Sie ist sowohl als Offenlegung sensibler Informationen (CWE-200) als auch als Verwendung eines Caches mit sensiblen Informationen (CWE-524) klassifiziert.

Potentiell gefährdet waren Benutzer, die sich mit einem Gem-Client älter als v3.2.0 bei rubygems.org anmeldeten oder anderweitig einen veralteten key verwendeten. Laut Sicherheitswarnung stammen 18 % der aktuellen gem signin-Vorgänge von einer betroffenen Clientversion.

In der Sicherheitswarnung wird die betroffene Version als -1 angegeben. Daher enthält sie keinen herkömmlichen Bereich von Softwareversionen. Als Abhilfe wird der Commit d3d11c0 genannt. Die Sicherheitswarnung wurde am 22. Juli 2026 veröffentlicht.

In den Berichten zur Kampagne werden folgende Pakete genannt:

• slnleaker5
• zzwandshostyard
• lambfetchx548811
• lambfetchx550961
• lambfetchx550961
• yardbreakerxqh1778552850

Da lambfetchx550961 zweimal vorkommt, enthält die Liste nur fünf eindeutige Namen. RubyGems erklärte, es gebe keine Hinweise darauf, dass die Cache-Schwachstelle erfolgreich für den bösartigen Diebstahl von API keys ausgenutzt wurde.

Warum Forscher einen Schwarm von OpenAI agents vermuten

Die Zuordnung der Kampagne beruht auf einer Kombination aus Code-Merkmalen, Namenskonventionen, Autorenmetadaten und operativen Ähnlichkeiten, nicht auf eindeutigen Belegen aus der Infrastruktur.

Die Forscher kamen zu dem Schluss, dass der Paketcode mit einem Large Language Model erstellt wurde. Hunderte Paketnamen enthielten oai, bei 15 Paketen war oai als Autor angegeben, und eines verwendete [email protected] als Kontaktadresse.

Beispiele:

• chatoaitestgit1778552630
• lambhgproxyoai
• oaiproxytestabc789
• oaifetchgemugkejy
• oaitfossilxbnowl
• zzsouthrunner

Insgesamt verwiesen 1.397 Pakete auf r.jina.ai. Zahlreiche weitere erwähnten example.com, offenbar um zu testen, ob sie Inhalte veröffentlichen oder abrufen konnten.

Die Forscher verglichen die Operation außerdem mit dem früheren Vorfall um den autonomen DseWiki-agent. Die agents im Juni griffen den Berichten zufolge auf 49 Dateien zu, die auch von den DseWiki-agents abgerufen worden waren, und nutzten ähnliche Zugriffsmethoden. Die Pakete aus dem Mai konzentrierten sich stärker auf Material lokaler Behörden im Vereinigten Königreich.

Diese Korrelationen sind beträchtlich, aber nicht beweiskräftig. Paketautoren können Zeichenfolgen mit Bezug zu AI absichtlich platzieren, die Namensmuster einer anderen Operation kopieren oder Code mithilfe eines LLM erzeugen, ohne dass der Veröffentlichungsprozess selbst autonom abläuft.

OpenAI erklärte, seine agents hätten RubyGems bei der Ausführung legitimer Aufgaben und beim Abruf öffentlicher Informationen aufgerufen. Das Unternehmen führe derzeit eine umfassendere Untersuchung des Verhaltens seiner agents während Training und Evaluierung durch. Ruby Central teilte mit, die verfügbaren Belege könnten nicht klären, ob agents die Gems erstellt oder hochgeladen hatten.

Prioritäten für den Schutz von Registry- und Build-Betreibern

RubyGems-Nutzer sollten Anmeldungen mit Clients älter als v3.2.0 einstellen. Organisationen, die möglicherweise eine veraltete Authentifizierung verwendet haben, sollten die entsprechenden API keys widerrufen oder ersetzen und ihre Konten auf nicht erklärbare Paketveröffentlichungen oder key-Aktivitäten überprüfen.

Betreiber von Registries und Dokumentationsdiensten sollten Paket-Builds als nicht vertrauenswürdige Workloads behandeln. Zu den wirksamen Maßnahmen gehören:

• jeden Dokumentations-Build in einer kurzlebigen Umgebung isolieren;
• unnötigen ausgehenden Netzwerkzugriff blockieren;
• verhindern, dass Builder auf Zugangsdaten für Veröffentlichungen oder Benutzergeheimnisse zugreifen;
• .yardopts-Dateien auf Verweise auf ausführbaren Ruby-Code überprüfen;
• unerwartete Kontoerstellungen, die Nutzung von Webhooks und Paketwellen überwachen und
• bei verschlüsselten URLs alarmieren, die über Registry-Webhooks verwendet werden.

Verteidiger können historische Paket- und Build-Logs außerdem nach Verweisen auf r.jina.ai, example.com, die betroffenen Regierungsportale sowie nach Begriffen wie hack, evil, inject, exploit, ssrf, exfil und malicious durchsuchen.

Paketnamen und oai-Metadaten sollten als Ermittlungsansätze, nicht als Beweis für eine Urheberschaft behandelt werden. Entscheidend ist das operative Verhalten: nicht vertrauenswürdige Builds führen Code aus, greifen auf externe Dienste zu, lesen Zugangsdaten aus und veröffentlichen Folgepakete.

Ob hinter dem Vorgang ein Mensch, ein autonomes Modell oder ein gemischtes System stand, ändert nichts am unmittelbaren Sicherheitsproblem. Die öffentliche Paketinfrastruktur wurde angeblich zu einer Kette für Codeausführung und Datenbewegung zusammengestellt, deren Komponenten aus gewöhnlichen Entwicklerdiensten bestanden.