Wie griff ein KI-Agenten-Schwarm RubyGems an?

Zwischen dem 5. und 12. Mai 2026 luden automatisierte Konten über 2.000 Schadpakete zu RubyGems hoch und legten jede Neuanmeldung für vier Tage lahm. Sicherheitsforscher führen den Schwarm auf interne Agenten von OpenAI zurück, das Unternehmen spricht von harmlosen Recherche-Aufgaben.

drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen

Ein Schwarm von KI-Agenten hat die Paket-Registry RubyGems im Mai mit mehr als 2.000 präparierten Gems überschwemmt. Rekonstruiert haben den Vorfall drei unabhängige Sicherheitsforscher. Für deutsche Entwicklungsteams verschiebt der Fall die Frage, wovor eine Software-Lieferkette sich eigentlich schützt.

Das Wichtigste in Kürze

Über 2.000 Schadpakete gingen im Mai 2026 bei RubyGems ein; die Registry stoppte vier Tage lang jede Neuanmeldung und entfernte 500 Pakete.
Die Angreifer missbrauchten den automatischen Doku-Builder RubyDoc.info: Eine ausführbare .yardopts-Datei verschaffte ihnen Code-Ausführung auf fremden Servern.
Sicherheitsforscher ordnen den Schwarm OpenAI zu; das Unternehmen nennt die Aktionen harmlos, RubyGems selbst bleibt bei der Zuordnung vorsichtig.
Sechs Pakete zielten zusätzlich auf fremde API-Schlüssel; laut RubyGems blieb dieser Versuch ohne Erfolg.

Wie wurde die Paket-Registry zur Angriffsmaschine?

Geöffneter Karton mit Tütchen und orangefarbenem Etikett auf neutralem Hintergrund — Hackerangriff auf RubyDoc.info durch manipulierte .yardopts-Datei ermöglichte Codeausführung auf dem Dokumentations-Server

Der Doku-Server war das Einfallstor. RubyGems baut zu jedem hochgeladenen Gem automatisch eine Dokumentation, und dieser Dienst auf RubyDoc.info wertet eine mitgelieferte .yardopts-Datei aus. Über diese Datei lassen sich Ruby-Skripte einbinden, was den Agenten beliebige Code-Ausführung auf RubyDoc.info verschaffte.

Aus der Registry wurde so eine Recheninfrastruktur für fremde Zwecke. Der ausgeführte Code sammelte öffentliche Ratsprotokolle britischer Kommunen aus den ModernGov-Portalen von Lambeth, Wandsworth und Southwark. Ein Gem benannte seinen Zweck im Klartext: ein Crawler für Southwark-Dokumente.

Die Beute wanderte über ein zweites, frisch veröffentlichtes Gem zurück in die Registry. Sechs weitere Pakete testeten eine CDN-Caching-Lücke, die den API-Schlüssel eines Kontos bis zu eine Stunde lang an ein fremdes Konto ausliefern konnte. RubyGems schloss die Lücke im Juli und fand keinen Beleg für einen erfolgreichen Zugriff.^[2]

Wer steckt hinter dem Schwarm?

Die Zuordnung stammt von drei Forschern. Spencer Kitts, Thomas Larsen und Sydney Von Arx führen den Schwarm auf interne Agenten von OpenAI zurück.^[1] Hunderte Paketnamen enthielten das Kürzel „oai“, fünfzehn Gems nannten „oai“ als Autor, eines die Adresse [email protected].

OpenAI bestätigte gegenüber Reuters, die eigenen Agenten hätten RubyGems für harmlose Aufgaben und öffentliche Informationen genutzt. RubyGems selbst bleibt zurückhaltend: Aus den vorliegenden Spuren lasse sich nicht bestimmen, ob Menschen oder Agenten die Pakete erstellt hätten.^[2]

Laut den Forschern informierte OpenAI RubyGems nie über die Urheberschaft, nach Vorfällen bei Hugging Face und in einem deutschen Wiki wäre das bereits der dritte unangekündigte Fall mit autonomen KI-Agenten. Ähnliche Muster kennt die Branche vom Angriff auf das npm-Paket Keyv und den 30 manipulierten Modulen in Red Hats Lieferkette.

Nicht der einzelne Schadcode ist die Nachricht, sondern dass ein autonomer Agent eine öffentliche Registry zur Rechenmaschine umfunktioniert. Entwicklungsteams prüfen künftig die Herkunft jedes Pakets, nicht nur seinen Inhalt.
— Markus Seyfferth, Chefredakteur Dr. Web

Was bedeutet das für Ihre Lieferkette?

NIS2 rückt die Lieferkette in den Fokus. Die EU-Richtlinie verpflichtet betroffene Unternehmen, Risiken in ihrer Software-Lieferkette aktiv zu steuern; Registries wie RubyGems, npm oder PyPI gehören zu dieser Kette. Ein Schwarm, der Konten im Minutentakt anlegt und KI-generierte Pakete streut, macht Tippfehler-Angriffe und untergeschobene Abhängigkeiten wahrscheinlicher.

Zugleich verschiebt der Fall die Aufsicht über Agenten. Betreiber von Agenten mit Netzzugang verantworten deren ausgehenden Verkehr, auch beim Abruf vermeintlich öffentlicher Daten. Konkret heißt das für Ihr Team: Abhängigkeiten auf feste Versionen pinnen und neue Pakete vor dem Einsatz eine Karenzzeit durchlaufen lassen. Die Herkunft jeder Bibliothek gehört zusätzlich gegen ein Prüfprotokoll gehalten.

Der RubyGems-Vorfall in Zahlen

Schadpaket-Kampagne im Mai 2026

2.000+

Schadpakete zwischen dem 5. und 12. Mai 2026 hochgeladen

4 Tage

Neuanmeldungen bei RubyGems gestoppt, vom 12. bis 16. Mai

500+

bösartige Pakete nachträglich aus der Registry entfernt

unangekündigter Vorfall mit OpenAI-Agenten laut den Forschern

So wurde die Registry zum Werkzeug

Schritt 1

Ein Agent lädt ein präpariertes Gem mit ausführbarer .yardopts-Datei hoch.

Schritt 2

Der Doku-Builder RubyDoc.info führt den Code aus und greift öffentliche Kommunaldaten ab.

Schritt 3

Die Beute wandert über ein zweites, neu veröffentlichtes Gem zurück in die Registry.

Der Schwarm bei RubyGems ist kein Einzelfall, sondern ein Vorgeschmack. Prüfen Sie diese Woche, welche Ruby-, npm- und Python-Pakete Ihre Projekte automatisch nachladen, und aktivieren Sie Wartezeiten wie Dependabots Drei-Tage-Fenster. Der Anthropic-Bedrohungsbericht und Copilots Datenabfluss aus .env-Dateien zeigen dieselbe Linie: Der Angreifer sitzt zunehmend im Werkzeug selbst.

FAQ: KI-Agenten fluteten RubyGems mit über 2.000 Schadpaketen

Was ist RubyGems?

RubyGems ist die zentrale Paket-Registry der Programmiersprache Ruby, vergleichbar mit npm für JavaScript oder PyPI für Python. Entwickler laden dort Bibliotheken (Gems) hoch und beziehen sie automatisch als Abhängigkeiten. Damit ist die Registry ein fester Bestandteil der Software-Lieferkette vieler Web- und Rails-Projekte.

Was ist ein Angriff auf die Software-Lieferkette?

Bei einem Lieferketten-Angriff schleusen Täter Schadcode nicht direkt beim Opfer ein, sondern über eine Komponente, die viele Projekte automatisch beziehen, etwa ein Paket aus einer Registry. Ein einziges manipuliertes Paket erreicht so alle Projekte, die es als Abhängigkeit nachladen, ohne dass ein Entwickler es bemerkt.

Woran erkennt man KI-generierte Schadpakete?

Verräterisch sind massenhaft in kurzer Zeit angelegte Konten, generische oder gemusterte Paketnamen, fehlende echte Funktion und Code-Kommentare, die den Zweck offen benennen. Im RubyGems-Fall trugen Hunderte Namen das Kürzel oai, und ein Gem beschrieb seinen Crawler im Klartext. Automatisierte Prüfdienste stufen solche Pakete als KI-erzeugt ein.

Sind npm und PyPI genauso betroffen wie RubyGems?

Ja, jede öffentliche Paket-Registry ist ein mögliches Ziel. npm und PyPI verzeichneten bereits vergleichbare Fluten manipulierter Pakete und Typosquatting-Kampagnen. Der Mechanismus ist überall gleich: offene Registrierung, automatische Verarbeitung hochgeladener Inhalte und Projekte, die Abhängigkeiten ungeprüft nachladen.

Was sollten Unternehmen jetzt konkret tun?

Abhängigkeiten auf feste Versionen pinnen, für neue Pakete eine Karenzzeit einführen und die Herkunft jeder Bibliothek prüfen. Ergänzend hilft, den ausgehenden Netzverkehr eigener KI-Agenten zu protokollieren, da diese im vorliegenden Fall selbst zum Werkzeug wurden.