IronWorm: ein Rust-npm-Worm, der npm Trusted Publishing missbraucht, per eBPF-Rootkit verschwindet und ohne C2 exfiltriert

TL;DR — 90 Sekunden

Betroffen?

Projekte/CI, die eine trojanisierte Version eines der vom kompromittierten npm-Account asteroiddao republizierten Pakete ziehen (WeaveDB-/Arweave-Ökosystem; JFrog listet die vollständige IoC-Paketliste, z. B. weavedb-sdk@0.45.3). Verschärfend: Entwickler- und CI-Maschinen mit erreichbaren Cloud-/Registry-/KI-Credentials.

Risiko?

Credential-Diebstahl (86 Umgebungsvariablen inkl. 14 KI-Provider-Keys, plus ~/.claude/.credentials.json, ~/.aws/credentials, ~/.kube/config, ~/.docker/config.json, Vault, Kubernetes-Secrets), CI/CD-Selbstpublikation über npm Trusted Publishing, GitHub-Worm-Ausbreitung mit gefälschten Bot-Commits, eBPF-Rootkit-Tarnung, Tor-C2.

Sofortmassnahme?

Builds/CI gegen die JFrog-IoC-Liste prüfen, --ignore-scripts erzwingen, betroffene Credentials rotieren, CI-Workflows auf ausgetauschte Secret-Exfil-Jobs prüfen, npm-Trusted-Publishing-Berechtigungen sichten.

Empfehlung?

Mid-Market und Enterprise: Trusted Publishing pro Paket eng scopen und überwachen, GitHub-Actions-Workflow-Integrität prüfen, Commit-Autor-Identitäten (claude, dependabot[bot], renovate[bot], github-actions[bot]) ausserhalb ihres normalen Kontextes auditieren, Kernel-Lockdown auf Build-Runnern erwägen.

Kritikalität?

high (referenziert das Hero-Badge — aktiver, in der Wildnis gefangener Worm; Audit im 48h-Fenster).

Was ist das Problem?

Laut JFrog (Stand 3. Juni 2026) begann der Fund bei einem auffälligen npm-Account, asteroiddao (verknüpft mit der GitHub-Organisation asteroid-dao im Arweave-/WeaveDB-Ökosystem): Alle Pakete des Accounts waren in einem engen Zeitfenster republiziert worden, jede neue Version mit einem nativen Binary, das aus einem Install-Hook lief. Das Tarball — am Beispiel weavedb-sdk@0.45.3 — enthielt vier saubere Original-Dateien und eine fünfte: eine rund 976 KB grosse Linux-ELF unter tools/setup. Die package.json verriet den Trick:

{
  "name": "weavedb-sdk",
  "version": "0.45.3",
  "scripts": {
    "preinstall": "./tools/setup"
  }
}

preinstall läuft, bevor npm überhaupt Dependencies auflöst — npm install genügt, kein Build-Schritt, kein Klick. Bis hierhin klingt das nach klassischem Install-Hook-Missbrauch. Der Unterschied von IronWorm liegt darin, was das Binary ist und was es danach tut.

Das Binary ist ein Rust-Release-Build (UPX-gepackt mit überschriebenem UPX-Magic als Anti-Unpack-Trick, per-Call-Site-String-Verschlüsselung ohne globalen Schlüssel) — bewusst aufwendig zu reversen. JFrog bezeichnet IronWorm als „Shai-Huluds rustigen Cousin“: dieselbe Grundidee wie der Shai-Hulud-Worm (Entwickler kompromittieren, Credentials stehlen, über vertrauenswürdige Lieferketten-Workflows weiterspringen, sogar dieselben Commit-Namen), aber „auf die nächste Stufe gehoben“.

Drei dieser Stufen sind der eigentliche Grund für diesen Beitrag — denn sie hebeln genau die Defense-in-Depth aus, die nach den npm-Worm-Wellen der letzten Wochen empfohlen wurde (auch von uns): Selbstpublikation über npm Trusted Publishing statt gestohlenem Token, Exfiltration ohne externen C2 über GitHub-Actions-Artefakte, und Host-Tarnung über ein eBPF-Kernel-Rootkit. Die drei Mechanismen sind weiter unten im Detail beschrieben (Abschnitt „Was wir konkret getan haben“ → Tiefer Blick).

Wer ist betroffen?

JFrog markierte die Schad-Versionen binnen eines Tages als deprecated; viele Schad-Commits wurden „still“ wieder entfernt. Wichtig ist die ehrliche Unschärfe der Quelle: Der kompromittierte Account war in dem Monat hochaktiv (rund 4.500 Beiträge zu privaten Projekten), die sichtbare öffentliche Aktivität ist also möglicherweise nur ein Teil des Bildes. Die autoritative, fortlaufend gepflegte Paket-/IoC-Liste steht bei JFrog; wir geben hier bewusst keine Momentaufnahme als vollständig aus.

Auswirkungen

Der Kern ist nicht „noch ein npm-Worm“, sondern dass IronWorm drei Schichten angreift, die nach Shai-Hulud als die Antwort galten.

Erstens die Token-Schicht. Die Standard-Empfehlung nach den letzten Wellen lautete: weg von langlebigen npm-Publish-Tokens, hin zu kurzlebigen, an die CI gebundenen Credentials (OIDC, Trusted Publishing). IronWorm dreht genau das um: In CI fordert er selbst ein OIDC-Identity-Token an und tauscht es an Npms Trusted-Publishing-Endpunkt gegen ein kurzlebiges, paket-scoped Automation-Token — ohne je ein gespeichertes Credential zu berühren —, und publiziert damit die trojanisierte Version. Die Massnahme, die langlebige Tokens beseitigen sollte, wird zum Publikationsweg.

Zweitens die Netzwerk-/C2-Schicht. Wer Worms über ausgehende C2-Verbindungen erkennen will, findet hier nichts: Hat ein Repo GitHub Actions, ersetzt IronWorm einen bestehenden Workflow durch einen, der ${{ toJSON(secrets) }} in eine harmlos benannte Datei schreibt und als Build-Artefakt hochlädt — abrufbar für den, der Zugriff hat. Kein externer C2. Die Actions sind auf echte Commit-SHAs gepinnt, was den Workflow ironischerweise sicherheitsbewusster aussehen lässt; Job- und Schritt-Namen stammen aus einem Pool plausibler CI-Phrasen. (JFrog beobachtete diesen zweiten Pfad in freier Wildbahn nicht ausgelöst, die Logik ist aber vollständig vorhanden und funktionsfähig.)

Drittens die Host-/Detektions-Schicht. Ein eBPF-Kernel-Rootkit versteckt Prozesse (/proc-Listings werden umgeschrieben → unsichtbar in ps, top, ls), versteckt TCP-Verbindungen (/proc/net/tcp und Netlink gefiltert → unsichtbar in ss), und beantwortet ptrace-Versuche auf geschützte Prozesse mit SIGKILL (ein strace kann die eigene Shell killen). Die gute Nachricht für Betreiber: Die zwei stärksten Tricks — Prozess- und Socket-Tarnung — hängen an einem BPF-Helper, der Speicher im aufrufenden Prozess ändert. Auf gehärteten Systemen mit Kernel-Lockdown ist diese Fähigkeit eingeschränkt; die Umschreibungen scheitern still, und die vermeintlich versteckten Prozesse und Sockets werden wieder sichtbar. Das Rootkit verliert dann seine wirksamste Tarnung.

Eine CVE-Nummer gibt es nicht; es ist ein laufender Lieferketten-Vorfall, kein einzelner Produktfehler. Die operative Schwere ist trotzdem hoch: Wer eine betroffene Version zieht, verliert potenziell die Schlüssel zur gesamten Cloud-, Registry- und KI-Tool-Landschaft — und der Worm ist darauf gebaut, das Stehlen in Selbstausbreitung umzumünzen.

Mitigation / Sofortmassnahmen

Hinweis: Die folgenden Schritte sind unsere operative Empfehlung auf Basis der von JFrog dokumentierten Technik — keine vom Hersteller zertifizierte Anleitung.

Operational Decision Block

• Sofort handeln, wenn … eines der von JFrog gelisteten asteroiddao-Pakete (WeaveDB-/Arweave-Familie) direkt oder transitiv in Ihrem package-lock.json / CI-Cache steht.
• Priorisiert prüfen, wenn … Ihre CI npm Trusted Publishing nutzt oder Cloud-/KI-Credentials im Zugriff hat.
• Reine Awareness, wenn … Sie keine der betroffenen Versionen ziehen und in CI bereits --ignore-scripts erzwingen.

Schritt 1 — Installs absichern

# preinstall-/native-Hook-Ausfuehrung global unterbinden (CI und lokal)
npm config set ignore-scripts true
# oder pro Lauf:
npm ci --ignore-scripts
# Hinweis: stoppt den preinstall-Trigger, NICHT die GitHub-seitige Worm-Ausbreitung.

Schritt 2 — Dependency-Baum gegen die JFrog-IoC-Liste pruefen

# Beispiele aus der JFrog-IoC-Liste; vollstaendige, aktuelle Liste an der Quelle abgleichen
grep -nE "weavedb-sdk|weavedb-client|weavedb-node-client|aonote|wao|arnext|roidjs|zkjson|fpjson-lang" package-lock.json
npm ls weavedb-sdk weavedb-client wao arnext 2>/dev/null

Schritt 3 — Credentials rotieren

Wenn eine betroffene Version installiert wurde (lokal oder in CI), als kompromittiert behandeln:
- npm-, GitHub- (inkl. PATs), Cloud-Tokens (AWS/GCP/Azure), Vault- und Kubernetes-Tokens rotieren
- KI-Provider-Keys rotieren (Anthropic/OpenAI/Gemini/Cohere/Mistral/Groq/Perplexity/xAI)
- lokale Credential-Dateien als exponiert annehmen:
  ~/.claude/.credentials.json, ~/.codex/auth.json, ~/Cursor/auth.json,
  ~/.gemini/settings.json, ~/.aws/credentials, ~/.kube/config, ~/.docker/config.json

Schritt 4 — CI-Workflows und Trusted Publishing pruefen

# ausgetauschte Secret-Exfil-Workflows finden (toJSON(secrets) -> Datei -> upload-artifact)
grep -RInE "toJSON\(secrets\)|upload-artifact" .github/workflows/

# unerwartete Workflow-Aenderungen im Git-Verlauf sichten
git log --oneline -- .github/workflows/

# npm Trusted Publishing: welche Pakete vertrauen welcher CI-Identitaet? eng scopen.

Detection / Prüfung

IOCs direkt aus der von JFrog dokumentierten Technik abgeleitet.

Gefälschte/rückdatierte Commits und Bot-Identitäten

# Commits, die als "claude" attribuiert sind (gefaelschte AI-Assistant-Identitaet)
git log --all --pretty='%H %an <%ae> %ad %s' | grep -iE "claude@users\.noreply\.github\.com"

# rueckdatierte Commits: Autor-Datum weit vor Commit-Datum (manipulierter Zeitstempel)
git log --all --format='%ci | %ai | %an | %s' | awk -F' \\| ' '{ if (substr($1,1,4) != substr($2,1,4)) print }'

# verdaechtige "Routine"-Commit-Messages aus der JFrog-Liste
git log --all --oneline | grep -iE "resolve lint warnings|sync lockfile|update workflow configuration"

Unerwartete Build-Hooks und Payload-Pfade

# native Payload-Pfade, die IronWorm bevorzugt
find . -path '*/tools/setup' -o -path '*/.github/scripts/precheck' 2>/dev/null

# preinstall-Hooks, die ein lokales Binary starten
grep -RInE '"preinstall"\s*:\s*"\./' --include=package.json .

eBPF-Rootkit-Tarnung auffliegen lassen

Die Prozess-/Socket-Tarnung haengt an einem BPF-Speicher-Helper, der bei
Kernel-Lockdown eingeschraenkt ist. Pruefpunkte:
- Kernel-Lockdown-Status pruefen: cat /sys/kernel/security/lockdown
- bei aktivem Lockdown werden zuvor versteckte Prozesse/Sockets wieder sichtbar
- ptrace-Anomalie: ein strace/gdb, das die Ziel-Shell ploetzlich per SIGKILL beendet,
  ist selbst ein Indikator (Anti-Debug-Logik des Rootkits)
- ungewoehnliche Tor-Aktivitaet von Build-Runnern/Dev-Maschinen

Betreiberempfehlung

Mittelstand

Zuerst eingrenzen, dann rotieren. Prüfen Sie Lockfiles und CI-Caches gegen die JFrog-IoC-Liste; steckt eine Version drin, behandeln Sie alle in der Pipeline erreichbaren Tokens als kompromittiert — inklusive der KI-Provider-Keys und der lokalen ~/.claude-/~/.codex-/~/.aws-Dateien, an die viele bei „Credential-Rotation“ nicht zuerst denken. Schalten Sie --ignore-scripts in CI scharf. Wichtig: Das stoppt den preinstall-Trigger, nicht die GitHub-seitige Ausbreitung — prüfen Sie deshalb zusätzlich Ihre Workflows.

Enterprise

Zusätzlich: npm Trusted Publishing eng pro Paket scopen und die Token-Exchange-Aktivität überwachen — IronWorm zeigt, dass OIDC-Trusted-Publishing eine Publikationsfähigkeit ist, die ohne menschliches Token missbraucht werden kann. Behandeln Sie GitHub-Actions-Workflow-Dateien als geschützte Artefakte (Required Reviews, Branch Protection, CODEOWNERS) und alarmieren Sie auf Diffs, die toJSON(secrets) oder neue upload-artifact-Schritte einführen. Auditieren Sie Commit-Autor-Identitäten (claude, dependabot[bot], renovate[bot], github-actions[bot]) ausserhalb ihres normalen Kontextes — die Tarnung lebt davon, dass diese Namen niemand hinterfragt.

Kubernetes / Container

Build-Images neu bauen, sobald eine betroffene Version im Baum war. IronWorm zielt explizit auf den Kubernetes-Service-Account-Token (liest ihn, läuft die Namespaces ab, dumpt erreichbare Secrets und meldet sich mit demselben Token an einer erreichbaren Vault-Instanz an). Halten Sie Service-Account-Token minimal gescopt, schränken Sie Secret-Zugriff pro Workload ein, und ziehen Sie auf Build-Runnern Kernel-Lockdown in Betracht — das nimmt dem eBPF-Rootkit seine wirksamste Tarnung.

Deklarative Stacks (NixOS / Talos / Flatcar)

Pin auf bekannte gute Versionen, reproduzierbarer Rebuild. Talos und Flatcar bringen Kernel-Lockdown bzw. eine minimierte, unveränderliche Host-Oberfläche mit — genau die Eigenschaft, die hier die Rootkit-Tarnung bricht. Der Vorteil der deklarativen Spur bleibt die Nachweisbarkeit: Welche npm-Version wann in welchen Build floss, ist belegbar — die Eingrenzung eines Lieferketten-Vorfalls beschleunigt das erheblich.

Was wir konkret getan haben

Wir behandeln Lieferketten-Worms als Pipeline-Disziplin-Frage, nicht als einzelnes Paket. Für unsere betreuten Stacks heisst das anlassbezogen: Lockfiles und Caches gegen die JFrog-IoC-Liste geprüft, --ignore-scripts als CI-Default bestätigt, einen Sweep auf tools/setup-/.github/scripts/precheck-Payload-Pfade und auf claude-attribuierte sowie rückdatierte Commits gefahren, GitHub-Actions-Workflows auf toJSON(secrets)-Exfil-Muster geprüft, und die npm-Trusted-Publishing-Scopes der betreuten Pakete gesichtet.

Die ehrliche Lehre: Unsere eigene Empfehlung aus dem binding.gyp-Post (kurzlebige, eng gescopte CI-Credentials statt langlebiger Tokens) bleibt richtig — aber IronWorm zeigt, dass sie nicht ausreicht. Wer langlebige Tokens durch OIDC/Trusted Publishing ersetzt, schliesst eine Tür und muss die nächste im Blick behalten: die Trusted-Publishing-Fähigkeit selbst. Deshalb haben wir zwei Dinge ergänzt: erstens Workflow-Integrität als eigene Kontrolle (Required Reviews + Alarm auf Secret-Serialisierung in Workflows), zweitens Kernel-Lockdown auf Build-Runnern, wo der Host es zulässt.

Tiefer Blick: die drei Mechanismen, die IronWorm von der Vorwoche abheben

1 — Selbstpublikation über npm Trusted Publishing (die OIDC-Drehung). Statt ein gestohlenes npm-Token zu nutzen, fragt IronWorm in einer CI-Umgebung selbst ein OIDC-Identity-Token mit dem für Trusted Publishing erwarteten Audience-Parameter an, reicht es an Npms Endpunkt /-/npm/v1/oidc/token/exchange/package/<pkg> und erhält ein kurzlebiges, paket-scoped Automation-Token. Damit publiziert er die trojanisierte Version wie ein legitimer Release. Der Witz daran: Trusted Publishing wurde eingeführt, um gespeicherte Tokens überflüssig zu machen — IronWorm braucht deshalb gar kein gespeichertes Credential mehr zu stehlen, sondern erbt die Vertrauensstellung der CI. Die Kontrolle ist hier nicht „Token wegnehmen“, sondern „wer/was darf in diesem CI-Kontext überhaupt den Token-Exchange auslösen“ — also Scope und Überwachung der Trusted-Publishing-Beziehung selbst.

2 — Exfiltration ohne externen C2 (GitHub Actions als Lieferkanal). Hat ein Repo bereits Workflows, ersetzt der Worm eine bestehende Datei (aus einer Liste gängiger Workflow-Namen) durch einen Job, der ${{ toJSON(secrets) }} in eine harmlos benannte Datei (format-results.txt) serialisiert und per actions/upload-artifact hochlädt. Jeder Bestandteil ist ein legitimes GitHub-Actions-Feature, gegen den Repo-Eigentümer gewendet: toJSON(secrets) serialisiert alle dem Run verfügbaren Secrets; der Upload macht sie als Artefakt abrufbar; kein externer C2-Traffic entsteht. Tarnung inklusive: Die Actions sind auf echte Commit-SHAs gepinnt (sieht sicherheitsbewusster aus als Tags), Job-/Schritt-Namen klingen nach Routine („Run checks“, „Collect metrics“), und der Commit kommt unter Bot-Identitäten wie dependabot/renovate/github-actions. Die elegante Paarung: Eine Manifest-Änderung sieht richtig aus, wenn sie von „claude“ kommt; eine Workflow-Änderung sieht richtig aus, wenn sie von einem Bot kommt. (Diesen zweiten Pfad sah JFrog in der Wildnis nicht ausgelöst — die Logik ist aber vollständig und funktionsfähig.)

3 — eBPF-Kernel-Rootkit (clevere Tarnung, schludriger Fehler). Der Worm bringt ein eingebettetes BPF-Objekt mit (mit clang 22.1.5 kompiliert). Entscheidend: Die .BTF.ext-Debug-Metadaten wurden nicht entfernt, sodass JFrog 214 Quellzeilen und alle 10 BPF-Maps rekonstruieren konnte — ein seltener Blick in die versteckte Schicht. Das Rootkit versteckt Prozesse (umschriebene /proc-Listings), versteckt TCP-Verbindungen (/proc/net/tcp + Netlink-Filter), fügt bei jedem execve Treffer einer Namens-Watchlist automatisch zur versteckten Menge hinzu und beantwortet ptrace auf geschützte Prozesse mit SIGKILL. Die zwei stärksten Tricks (Prozess-/Socket-Tarnung) hängen aber an einem BPF-Helper zum Schreiben von Speicher im aufrufenden Prozess — bei Kernel-Lockdown ist der eingeschränkt, die Umschreibungen scheitern still, und Verstecktes wird wieder sichtbar. Übrig bleiben Anti-Debug und ein Teil der Netzwerk-Tarnung. Praktische Konsequenz: Ein gehärteter, gelockter Kernel ist hier kein Nice-to-have, sondern bricht aktiv die Tarnung.

Attribution am Rande. Der Operator hat seine eigene 12-Wort-BIP-39-Recovery-Phrase als 74-Byte-Eintrag in eine Skip-Liste des Wallet-Stealers hartkodiert, damit der Stealer ihn nicht selbst bestiehlt — und sie damit an jeden ausgeliefert, der das Binary entpackt (Wallet 0x7e28…, nahezu leer). Zusammen mit den nicht gestrippten BPF-Debug-Metadaten passt das zu JFrogs Einschätzung: ein sorgfältig gebautes, aber noch unfertiges Implantat — „vielleicht die Generalprobe, nicht die Endform“. Bemerkenswert für unsere laufende Linie: Während Project Glasswing / Claude Mythos auf der Verteidiger-Seite Funde liefert, missbraucht IronWorm den Namen „claude“ als Angreifer-Tarnung — dieselbe Marke, zwei Seiten der Mauer.

Fazit

IronWorm ist technisch keine Sensation in den Grundlagen — preinstall-Hook, Credential-Sweep, GitHub-Selbstausbreitung kennen wir aus Shai-Hulud und der Miasma-/binding.gyp-Welle. Neu ist, dass er die Antworten darauf angreift: Trusted Publishing statt gestohlenem Token, GitHub-Artefakte statt C2, eBPF-Rootkit statt lauter Persistenz. Für uns ist die Lehre nicht „die Empfehlungen waren falsch“, sondern „eine Schicht reicht nicht“: Wer langlebige Tokens durch OIDC ersetzt, muss die Trusted-Publishing-Beziehung scopen und überwachen; wer auf C2-Erkennung setzt, muss Workflow-Integrität prüfen; wer Host-Telemetrie vertraut, profitiert von Kernel-Lockdown. Weil der Vorfall laufend ist, gilt für die Paketliste die JFrog-Quelle, nicht eine Momentaufnahme. Nicht dramatisieren, aber heute prüfen — und zwar genau die Kontrollen, die nach der letzten Welle als „erledigt“ galten.

Quellen

• JFrog Security Research — IronWorm: Shai-Hulud's rustier cousin (03.06.2026; vollständiger Teardown + IoC-Paketliste)
• The Hacker News — IronWorm and New Miasma Worm Variant Hit npm in Supply Chain Attacks (05.06.2026)