Was am 12. Mai 2026 geschah
Am 12. Mai 2026 deaktivierte das RubyGems-Team die Registrierung neuer Konten auf der offiziellen Paketregistry für die Programmiersprache Ruby. Auslöser war eine koordinierte Welle aus mehr als 500 bösartigen Paketen, die über automatisierte Bot-Konten hochgeladen wurden. Wer die Anmeldeseite aufruft, erhält seither die Meldung „New account registration has been temporarily disabled“.
Anders als bei klassischen Supply-Chain-Angriffen war das primäre Ziel nicht die Kompromittierung von Endanwendern, sondern die Registry-Infrastruktur selbst. In den Uploads steckten unter anderem XSS-Versuche und Code, der Daten von RubyGems-internen Systemen exfiltrieren sollte. Maciej Mensfeld vom RubyGems-Security-Team kommentierte den Vorfall öffentlich und gab zu bedenken, dass die Spam-Welle möglicherweise einen tiefergehenden Angriff überdeckt.
- Datum: 12. Mai 2026, Mitteilung über RubyGems-Statusseite und X/Twitter.
- Umfang: Mehr als 500 schädliche Pakete hochgeladen, Botkonten gesperrt.
- Maßnahme: Neuregistrierungen temporär ausgesetzt, voraussichtlich 2–3 weitere Tage.
- Nicht betroffen: Installationen und
gem pushbestehender Konten. - Charakterisierung durch RubyGems: DDoS-artige Spam-Welle gegen die Plattform.
Die operative Reaktion erfolgte gemeinsam mit dem CDN- und Security-Partner Fastly: Web Application Firewallregeln wurden verschärft, die Rate-Limits für die Kontoerstellung deutlich angezogen, und die als bösartig identifizierten Gems wurden aus der Registry zurückgezogen (yank). Mend.io, das die Registry sicherheitstechnisch begleitet, kündigte einen detaillierten Bericht nach Abschluss der Aufräumarbeiten an.
Die Parallelkampagne: BufferZoneCorp zielt auf CI/CD-Credentials
Nahezu zeitgleich zur Spam-Welle veröffentlichten Forscher von Socket.deveine Analyse einer separaten, deutlich gezielteren Kampagne. Das GitHub-KontoBufferZoneCorphatte sieben Ruby-Gems und neun Go-Module veröffentlicht, die ausschließlich auf Continuous-Integration-Pipelines und Entwicklerumgebungenabzielen. Ob beide Vorfälle vom selben Akteur stammen, ist nicht abschließend geklärt – technisch sind sie aber zu unterscheiden.
Das technisch aggressivste Paket ist laut Socketknot-activesupport-logger. Es tarnt sich als Hilfsbibliothek im Stil eines bekannten Rails-Utilities – mit plausibler README und konsistenter Versionshistorie. Der Schadcode wird nicht erst zur Laufzeit aktiv, sondern bereits zum Installationszeitpunkt: RubyGems führtextconf.rbautomatisch im Rahmen des Native-Extension-Builds aus – ein klassischer, oft übersehener Ausführungspfad.
| Ökosystem | Aktive Pakete (Auswahl) | Zweck |
|---|---|---|
| Ruby Gems | knot-activesupport-logger knot-devise-jwt-helper knot-rack-session-store knot-rails-assets-pipeline knot-rspec-formatter-json | Credential-Diebstahl beim Install & beim ersten Logger-Aufruf |
| Go-Module | go-metrics-sdk go-weather-sdk go-retryablehttp go-stdlib-ext grpc-client / net-helper / config-loader | GitHub-Actions-Manipulation, SSH-Persistenz, Wrapper-Hijack der go-Binary |
Die Ruby-Gems sammeln laut Socket-Researcher Kirill Boychenko Umgebungsvariablen, SSH-Keys, AWS-Secrets, .npmrc,.netrc, GitHub-CLI-Konfiguration und RubyGems-Credentials ein und senden die Daten an einen Webhook.site-Endpunkt des Angreifers. Die Go-Module schreiben einen gefälschten go-Wrapperin das Cache-Verzeichnis, manipulieren GITHUB_ENVund GITHUB_PATHund hinterlegen einen Public Key in ~/.ssh/authorized_keysfür persistenten Zugriff.
So läuft der CI-Pipeline-Angriff technisch ab
Boychenko beschreibt den Kern des Go-Module-Angriffs in einem Satz, der das Zusammenspiel aus Init-Hook, GitHub-Actions-Erkennung und PATH-Hijacking sauber zusammenfasst:
Ablauf eines Install-Time-Angriffs (Ruby-Gem)
- 1Entwickler oder CI-Runner installiert ein Gem mit plausibel klingendem Namen (z. B. via Tippfehler oder Dependency-Confusion).
- 2RubyGems entpackt das Paket und führt automatisch extconf.rb für die Native-Extension aus – lange vor jedem require im Code.
- 3Das Skript scannt die Umgebung auf SSH-Keys, AWS-/GitHub-Tokens, .npmrc, .netrc und RubyGems-Credentials.
- 4Sekundärer Persistenzpfad: Beim ersten Aufruf des Loggers wird die Exfiltration erneut ausgelöst – zweiter Versuch in einer eventuell besseren Umgebung.
- 5Daten werden per HTTPS an einen Webhook.site-Endpunkt des Angreifers gesendet – keine eigene Infrastruktur, keine offensichtlichen IOCs.
Wer in einer GitHub-Actions-Pipeline prüfen will, ob Build-Hosts kompromittiert wurden, kann mit wenigen Aufrufen einen ersten Triage-Snapshot ziehen. Die folgenden Befehle sind defensiv und lesen ausschließlich Zustand – sie schreiben weder Daten zurück noch verändern sie Konfiguration:
# Verdächtiger go-Wrapper im Cache?
find ~ /tmp /var/cache -type f -name go -newer /etc/hostname -ls 2>/dev/null
# Wurde PATH innerhalb der Workflow-Umgebung manipuliert?
echo "$PATH" | tr ':' '\n'
[ -n "$GITHUB_PATH" ] && cat "$GITHUB_PATH"
[ -n "$GITHUB_ENV" ] && cat "$GITHUB_ENV"
# Unerwartete SSH-Public-Keys auf dem Runner?
test -f ~/.ssh/authorized_keys && \
awk '{print NR": "$1" "$3}' ~/.ssh/authorized_keys
# Liste verdächtiger Gems im Lockfile (Beispielmuster)
grep -E 'knot-(activesupport-logger|devise-jwt-helper|rack-session-store|rails-assets-pipeline|rspec-formatter-json|date-utils-rb|simple-formatter)' Gemfile.lock 2>/dev/nullStatische Analyse von Quellcode allein reicht hier nicht. Native-Extension-Skripte (extconf.rb), npm-postinstall-Hooks und Go-init()-Funktionenwerden in der Praxis selten geprüft, laufen aber automatisch mit den Rechten der CI/CD-Pipeline. Wer keine Sandbox um den Build-Prozess legt, vergibt seine Secrets faktisch an jeden Erstanbieter einer transitiven Dependency.
Einordnung: Warum 2026 zum Jahr der Registry-Angriffe wird
Der RubyGems-Vorfall reiht sich in eine sichtbar zunehmende Serie von Angriffen auf Paket-Registries ein. Im gleichen Berichtszeitraum dokumentierten Analysten massive Kompromittierungen im npm- und PyPI-Ökosystem (siehe u. a. SANS Internet Storm Center, Stormcast vom 13. Mai 2026). Was sich verändert, ist nicht die Tatsache, dass es Schadpakete gibt – das ist seit Jahren bekannt – sondern die Skalierung und Zielsetzung.
Registry als Ziel
Die Plattform selbst wird zum Angriffsziel – nicht nur als Umschlagplatz. XSS- und Exfiltrations-Payloads zielen auf Registry-Backends, Sessions von Maintainern und Moderationstools.
Install-Time-Hooks
extconf.rb, postinstall, init() – alle drei werden ohne Bestätigung beim Installieren ausgeführt. Die Build-Pipeline wird zum bevorzugten Eintrittsvektor.
CI-Credentials als Beute
Cloud-Tokens, GitHub-PATs, NPM-Tokens und Signaturschlüssel liegen während des Builds in Klartext-Umgebungsvariablen vor – ideale Ziele für sekundären Lateral Movement.
Plausibles Naming
Pakete wie knot-activesupport-logger imitieren etablierte Ökosystem-Konventionen. Reviewer scrollen häufig nicht bis zur Native-Extension – der Trojanisierungsgrad steigt.
Konkrete Maßnahmen für Entwicklungsteams
Die Empfehlungen unterscheiden sich nach Rolle. Wer aktiv Ruby- oder Go-Projekte betreibt, sollte eine kurze Bestandsaufnahme machen – selbst dann, wenn die genannten BufferZoneCorp-Pakete nicht im Lockfile auftauchen. Die Mechanik (Install-Hooks, PATH-Hijack, Webhook-Exfiltration) ist mit minimalem Aufwand auf andere Ökosysteme übertragbar.
Sofortmaßnahmen (heute)
- 1Gemfile.lock und go.sum auf die genannten BufferZoneCorp-Paketnamen prüfen – in CI-Pipelines genauso wie in Developer-Workstations.
- 2Falls ein Treffer: betroffene CI-Runner sofort isolieren, Cloud- und Git-Tokens rotieren, ~/.ssh/authorized_keys auf unbekannte Keys prüfen.
- 3Outbound-Verbindungen zu webhook.site und vergleichbaren Pastebin-/Receiver-Diensten in den letzten 7 Tagen in Netzwerk- und Egress-Logs nachvollziehen.
- 4gem install und go get künftig in einer isolierten Build-Umgebung (Container ohne Cloud-Secrets) ausführen – Secrets erst per Federation in den Run-Schritt einspielen.
- SBOM-Pflicht in der Pipeline: Jeder Build erzeugt eine vollständige Software Bill of Materials – inklusive transitiver Dependencies. Neue Pakete laufen durch ein Allowlist-Gate.
- Install-Hook-Audit: Native Extensions,
postinstallundinit()werden vor der ersten Nutzung automatisiert geprüft. - Egress-Kontrolle für CI: Build-Runner dürfen nur explizit erlaubte Domains erreichen – nicht das gesamte Internet.
- Short-lived Credentials: Statt langlebigen PATs OIDC-Federation mit Cloud- und Registry-Anbietern verwenden – gestohlene Tokens verlieren ihren Wert.
Fazit
Die Suspension von Neuregistrierungen bei RubyGems ist eine sinnvolle, aber kurzfristige Maßnahme gegen ein strukturelles Problem: Paket-Registries sind geteilte, kuratierte Trust-Anker für hunderttausende Projekte – und damit Hochwert-Ziele. Dass RubyGems den Angriff so transparent kommuniziert und die schädlichen Pakete zurückgezogen hat, ist vorbildlich. Den eigentlichen Schaden trägt jedoch jedes Team, dessen CI-Runner in den letzten Wochen ein Paket der BufferZoneCorp-Familie installiert hat – und das nicht weiß, welche Secrets dabei den Endpunkt verlassen haben.
Wer 2026 noch eine Build-Pipeline ohne Egress-Kontrolle, ohne SBOM und ohne Hook-Audit betreibt, arbeitet faktisch auf Vertrauensbasis mit dem gesamten Open-Source-Ökosystem. Die Mechanik dieses Angriffs – extconf.rb,init() und Webhook-Exfiltration – ist trivial reproduzierbar. Die nächste Welle wird kommen.