Six packages, one cluster, one message: the EVM/DeFi npm wave of 6 May 2026

TL;DR — die 90-Sekunden-Zusammenfassung

Betroffen?

Sechs npm-Pakete vom Publisher namikazesarada010206: viem-core, viem-utils-core, hardhat-core-utils, evm-utils, foundry-utils, web3-utils-core. Indirekt: jede Build-Pipeline, die Web3-Tooling transitiv zieht.

Risiko?

Schadrutine aktiviert sich bei require() auf echten Ethereum-Workstations — sucht ALCHEMY_API_KEY, INFURA_KEY, PRIVATE_KEY, MNEMONIC, DEPLOYER_KEY, Keystore-Verzeichnisse, SSH- und npm-Tokens. SHA-256 der telemetry.js: 71426e93cb6143052d5aeeca920850f8a0343c95bc65aab9a15145848cc5bff1.

Sofortmaßnahme?

Mirror-Proxy auf Allowlist-Modus, sechs Paketnamen explizit blocken, Token-Inventur (auch Test-.env-Dateien), MCP-Tool-Liste gegen Hash-Liste prüfen.

Empfehlung?

Mittelstand mit Web3-Pilot: sofort. Frontend-Agenturen mit Multi-Mandanten-npm-Stack: Allowlist-Disziplin. KI-Agent-Betreiber: dynamische Tool-Loader gegen Hash-Liste validieren.

Kritikalität?

Hoch (siehe Badge im Seitenkopf).

 

Am 6. Mai 2026 hat ein einzelner npm-Publisher (User namikazesarada010206) sechs Pakete in den Index geschoben: viem-core, viem-utils-core, hardhat-core-utils, evm-utils, foundry-utils und web3-utils-core. Plausibel klingende Helfer für die Ethereum- und Solidity-Entwicklung. Alle sechs enthielten dieselbe telemetry.js, byte-identisch, SHA-256 71426e93cb6143052d5aeeca920850f8a0343c95bc65aab9a15145848cc5bff1. Drei Tage nach der node-env-resolve-Welle ist das die zweite, fast deckungsgleiche Operation — diesmal in Web3-Kostüm.

Was diese Welle anders macht

Die Mechanik liegt nicht im postinstall, sondern später. Der Schadcode aktiviert sich erst, wenn das Paket per require() tatsächlich genutzt wird — und prüft dann, ob die Workstation wie ein echtes Ethereum/Solidity-Setup aussieht. Erst nach dieser Aktivierungsstufe greift er zu.

Was er sucht, liest sich wie eine Inventarliste der Web3-Entwicklung: ALCHEMY_API_KEY, INFURA_KEY, PRIVATE_KEY, MNEMONIC, DEPLOYER_KEY. Dazu Keystore-Verzeichnisse — ~/.foundry/keystores/, ~/.ethereum/keystore/, ~/.brownie/accounts/ — sowie SSH-Schlüssel und npm-Tokens. Wer gefunden wird, wird gefunden. Wer in einem CI-Builder läuft, der kein Wallet hat, wird stumm verschont; das spart Logs, das senkt die Erkennungsquote.

Drei der sechs Pakete fielen direkt bei der Erstveröffentlichung in die automatischen Erkennungs-Scanner; die anderen drei wurden nach Analyse manuell als bösartig markiert, sobald die identische telemetry.js quer durch das Cluster bestätigt war.

Warum das nicht „nur“ ein Krypto-Problem ist

Die naheliegende Reaktion eines klassischen Mittelständlers lautet: „Wir machen kein Web3, das geht uns nichts an.“ Drei Gründe, warum diese Antwort zu kurz greift.

Erstens — Die Aktivierungslogik ist Beispiel-Code. Was heute auf Ethereum-Variablen guckt, kann morgen auf SAP-RFC-Configs, AWS-SSO-Sitzungen oder Active-Directory-Credentials gucken. Der eigentliche Trick ist nicht das Ziel, sondern die Diskretion. Sechs Pakete, eine Schadrutine, ein Aktivierungsfilter — das ist ein Bauplan, kein Einzelfall.

Zweitens — Build-Maschinen ziehen oft mehr, als ihre Betreiber denken. Wer einen Frontend-Build mit Hot-Module-Replacement betreibt, transitiv von einem Ethereum-Tooling-Paket abhängt (etwa für ein CMS-Plugin, das Blockchain-Signaturen prüft) oder schlicht eine node_modules aus einem alten Repo neu auflöst, holt sich diese Pakete unbemerkt. Der require()-Trigger bedeutet nicht, dass die Pakete unschädlich sind, solange man sie nicht aktiv benutzt — sie sind nur unhörbar leise, bis es zum Treffer kommt.

Drittens — Diese Welle hängt mit den Vorfällen der letzten Wochen thematisch zusammen, auch wenn sie ein anderer Akteur ist. In sechs Wochen sehen wir nun mindestens vier voneinander unabhängige Cluster mit identischem Bauplan: generische Namen, plausibles Aussehen, klare Token-Ziele. Das Ökosystem hat ein Strukturproblem, kein punktuelles Vorfall-Problem. Wir haben das Muster bereits beim Bitwarden-CLI-Vorfall vom 22. April beschrieben — die Welle vom 6. Mai ist die nächste Iteration.

Was wir konkret gemacht haben

Bei unseren Bestandskunden haben wir am Morgen des 7. Mai drei Schritte ausgeführt — zwei davon hatten wir bereits am 4. Mai initiiert, einer ist neu hinzugekommen.

Zunächst die Mirror-/Proxy-Konfiguration auf Allowlist-Modus. Wer einen Verdaccio-, JFrog- oder GitHub-Packages-Proxy betreibt, kann diese sechs Paketnamen explizit blocken; gleichzeitig nimmt eine Allowlist nur freigegebene Versionen durch, was die Klasse als Ganzes adressiert. Ohne diese Schicht ist alles andere Symptombekämpfung.

Anschließend die Token-Inventur auf Entwickler-Maschinen. Bei zwei Kunden haben wir festgestellt, dass MNEMONIC und DEPLOYER_KEY-Variablen in .env-Dateien unter ~/Documents/projects/ lagen — aus Tests, die niemand mehr aktiv nutzte. Diese Werte sind nun rotiert; die Wallets sind leer.

Neu hinzugekommen: ein Audit-Pass auf MCP-Tool-Definitionen. Mehrere unserer Agent-Setups laden ihre Tool-Listen aus npm-Paketen; wir prüfen jetzt jeden Tool-Namen gegen die telemetry.js-Hash-Listen der letzten vier Wellen. Bei zwei Setups hatten wir Treffer — keine produktiven, alle in Entwicklungs-Branches.

Was wir bewusst nicht gemacht haben

Wir haben nicht alle npm-Installationen pauschal eingefroren. Das ist die falsche Reaktion — sie unterbricht Geschäftsprozesse und verschiebt das Vertrauensproblem nur. Was wir stattdessen tun: Zwischen Entwickler-Laptop und produktivem Token sitzt eine kurze Token-Lebensdauer, eine Hardware-Bindung und ein Audit-Log. Wenn ein Token kompromittiert wird, ist das ein operatives Ereignis, kein existenzbedrohendes.

Wir haben nicht auf Endpoint-Detection als alleinige Antwort gesetzt. Die Schadrutine ist kalt genug, um durch viele EDR-Suiten unauffällig zu sein. Wer sich darauf verlässt, dass „der Virenscanner es schon merken wird“, hat in den letzten sechs Wochen statistisch verloren.

Wer am stärksten betroffen ist

Drei Profile fallen in diesem Cluster auf. Web3-affine Mittelständler — Unternehmen, die digitale Lieferscheine, Echtheitszertifikate oder ESG-Reporting auf Blockchain-Schienen ausprobieren, oft mit kleinem internem Team. Hier sitzen die Wallet-Schlüssel oft direkt auf der Entwickler-Workstation; die Blast-Radius ist klein, aber finanziell potentiell hoch.

Frontend-zentrierte Agenturen — Wer regelmäßig fremde npm-Stacks aufnimmt (Onboarding eines neuen Kundenprojekts), zieht eine breite, schlecht verstandene Abhängigkeitsbasis durch die eigene Umgebung. Eine Lockfile-Disziplin reicht nicht; der Erstaufschlag des npm install ist der Kompromittierungs-Moment. Wir haben dazu bereits in unserer Analyse zur CI-Pipeline als größtes Einfallstor ausgeführt.

KI-Agent-Betreiber mit dynamischen Tool-Loadern — Stacks, in denen Agents Tools per Paketname auflösen können, sind besonders verwundbar, weil die Aktivierungsschwelle dort niedrig liegt. Ein Agent, der ein neues Tool ausprobiert, ist semantisch nicht weit entfernt von einem Entwickler, der einen Vorschlag aus Auto-Complete übernimmt.

Fazit

Diese sechs Pakete sind nicht das Ereignis. Das Ereignis ist die zweite Welle innerhalb von vier Tagen, mit nahezu identischer Bauanleitung, in einem anderen Sprach-Umfeld. Das Vertrauensmodell von npm ist offen — und es bleibt offen. Wer im Mittelstand Software baut, baut auf diesem Modell auf, ob er will oder nicht. Die Frage lautet nicht, ob die nächste Welle kommt. Sie lautet, ob sie auf Ihren Maschinen einen Wallet-Schlüssel findet, einen Cloud-Token, eine offene SSH-Sitzung — oder nichts. Persönlicher Hintergrund und technische Details zur Allowlist-Disziplin: ole-hartwig.eu.

Wer ist betroffen?

Drei Profile aus unserer Beratungspraxis sitzen heute im Risiko:

Quer dazu: jeder Stack, der ein altes Repo mit node_modules neu auflöst — die sechs Pakete sind seit dem 6. Mai aus npm registry entfernt, aber die Hash-Liste sollte trotzdem in jeden Mirror-Proxy als Block-Liste.

Mitigation und Sofortmaßnahmen

Die kurze Antwort: Mirror-Proxy auf Allowlist, sechs Paketnamen blocken, Hash-Liste prüfen. Vier Schritte:

Mirror-Proxy auf Block-Liste

# Verdaccio: malicious-package-blocker.yaml
packages:
  'viem-core': { access: none, publish: none, proxy: none }
  'viem-utils-core': { access: none, publish: none, proxy: none }
  'hardhat-core-utils': { access: none, publish: none, proxy: none }
  'evm-utils': { access: none, publish: none, proxy: none }
  'foundry-utils': { access: none, publish: none, proxy: none }
  'web3-utils-core': { access: none, publish: none, proxy: none }

# JFrog Artifactory: Exclude-Pattern in Remote-Repository
# GitHub Packages: keine Block-Listen-API; dafür Allowlist-Repo-Strategie

Token-Inventur (auch Test-.env-Dateien)

# Alle .env-Dateien im User-Home finden mit Wallet-/API-Variablen
grep -rEn 'ALCHEMY_API_KEY|INFURA_KEY|PRIVATE_KEY|MNEMONIC|DEPLOYER_KEY' \
  ~ --include='*.env*' 2>/dev/null

# Keystore-Verzeichnisse prüfen
ls -la ~/.foundry/keystores/ ~/.ethereum/keystore/ ~/.brownie/accounts/ 2>/dev/null

# Bei Treffer: Wallet rotieren (neue Seed Phrase, alte Wallets leeren)

Hash-Validierung in CI

# Bekannte malicious telemetry.js hash blockieren
find node_modules -name 'telemetry.js' -exec sha256sum {} \; \
  | grep -F '71426e93cb6143052d5aeeca920850f8a0343c95bc65aab9a15145848cc5bff1' \
  && echo "BLOCKED: malicious telemetry.js detected" \
  && exit 1

MCP-Tool-Audit

# Welche Tools sind in unseren MCP-Configs dynamisch geladen?
jq -r '.mcpServers[].command' ~/.config/claude/claude_desktop_config.json \
  | grep -E '(npx|uvx)'

# Für jeden Treffer: Tool-Paket-Name gegen die sechs malicious-Liste prüfen

Was Endpoint-Detection nicht löst. Die Schadrutine aktiviert sich erst bei require() in einer echten Ethereum-Workstation. Sie ist kalt genug, um durch viele EDR-Suiten unauffällig zu sein — das Aktivierungsfilter-Modell ist gegen Signatur-basierte Detection gebaut.

Detection und Prüfung

Fünf Kernfragen, wenn npm in Ihrem Stack läuft:

• Mirror-Proxy oder direkter npm-Pull? Direkter Pull = jede Welle trifft ungefiltert.
• Welche Web3-Dependencies sind transitiv?npm ls --all, dann grep -iE '(viem|hardhat|foundry|web3)'.
• Wo liegen Wallet-Schlüssel auf den Workstations? Keystore-Verzeichnisse, .env-Dateien, Browser-Wallets.
• Welche Token-Lebensdauer haben die produktiven Cloud-Tokens? Lang = jeder Vorfall ist größer.
• Läuft Endpoint-Detection mit Hash-Listen? Aktivierungs-Filter brechen Signatur-Detection — Hash-basierte Erkennung ist hier weniger wertvoll als Allowlist-Disziplin im Mirror.

# Hash-Suche über alle node_modules-Bäume
find /opt /srv /home -type d -name node_modules 2>/dev/null \
  | xargs -I{} find {} -name 'telemetry.js' \
  | xargs sha256sum 2>/dev/null \
  | grep -F '71426e93cb6143052d5aeeca920850f8a0343c95bc65aab9a15145848cc5bff1'

# Lockfile-Audit: malicious package names
grep -rEn '(viem-core|viem-utils-core|hardhat-core-utils|evm-utils|foundry-utils|web3-utils-core)' \
  /opt /srv /home --include='package*.json' 2>/dev/null

Betreiberempfehlung

Die Empfehlung hängt vom Setup ab. Vier Szenarien, vier Antworten — mit einem operativen Entscheidungsraster vorab:

Entscheidungsraster: Wann jetzt rotieren, wann beobachten?

• Sofort Wallet rotieren, wenn PRIVATE_KEY oder MNEMONIC auf einer betroffenen Workstation lagen und der Erstaufschlag npm install die sechs Pakete gezogen haben könnte.
• Token rotieren, wenn ALCHEMY_API_KEY, INFURA_KEY oder ein vergleichbarer Cloud-Provider-Token im User-Home lag.
• Mirror-Allowlist sofort, wenn der npm-Proxy heute jede Anfrage durchlässt.
• Beobachten reicht, wenn der Stack rein klassische Web-Entwicklung ohne Web3-Komponente macht — aber die Welle ist Bauplan für die nächste, nicht Einzelereignis.

Web3-affine Mittelständler

Wallet-Schlüssel haben nichts auf einer Standard-Entwickler-Workstation verloren. Hardware-Wallet plus Signing-API ist die strukturelle Antwort. Für Pilot-Projekte: separate VM mit kurzer Lebensdauer und eng skopiertem Wallet, das nach jedem Test geleert wird.

Frontend-Agenturen mit Multi-Mandanten-npm-Stack

Allowlist-Disziplin im Mirror-Proxy. Wer pro Mandant einen npm install macht, hat eine Allowlist pro Mandant. Versions-Pin in package-lock.json reicht nicht — die erste Auflösung ist der Kompromittierungs-Moment.

KI-Agent-Betreiber mit dynamischen Tool-Loadern

Tool-Loader gegen Hash-Liste validieren, MCP-Server-Pfade hart pinnen (siehe MCP STDIO-Post). Wer Agent-Tools per Paketname löst, ohne Pin, hat dieselbe Klasse wie die Wallet-Schlüssel auf der Workstation — nur weniger sichtbar.

Deklarative Stacks (NixOS, deno.lock-basiert)

Vorteil strukturell: Nix-Store-Pfade sind hash-verifiziert, Deno-Lockfile mit Integrity-Hashes. Wer JavaScript/TypeScript heute auf Deno mit lock baut, hat die Klasse auf Build-Seite stark reduziert. Nicht alle CVE-Klassen, aber genau diese.

Was wir konkret getan haben

Bei unseren Bestandskunden haben wir am Morgen des 7. Mai drei Schritte ausgeführt — zwei davon hatten wir bereits am 4. Mai initiiert (node-env-resolve-Welle), einer ist neu hinzugekommen.

• Mirror-Allowlist auf 7. Mai erweitert. Verdaccio- und JFrog-Konfigurationen pro Mandant durchgegangen, sechs Paketnamen explizit geblockt, Allowlist-Modus für Web3-Tooling-Namen aktiviert.
• Token-Inventur auf Entwickler-Maschinen. Bei zwei Kunden lagen MNEMONIC und DEPLOYER_KEY-Variablen in Test-.env-Dateien unter ~/Documents/projects/. Wallets rotiert, alte geleert.
• Audit-Pass auf MCP-Tool-Definitionen. Mehrere Agent-Setups laden Tool-Listen aus npm-Paketen. Jeden Tool-Namen gegen die telemetry.js-Hash-Listen der letzten vier Wellen geprüft. Bei zwei Setups Treffer in Dev-Branches, keine produktiv.
• Was wir bewusst nicht gemacht haben. Kein pauschales npm install-Einfrieren — das ist die falsche Reaktion, sie unterbricht Geschäftsprozesse und verschiebt das Vertrauensproblem. Keine alleinige EDR-Detection-Erwartung; die Schadrutine ist kalt genug, um Signatur-Detection zu umgehen.

Diese Routine ist die operative Praxis aus DevSecOps as a Service und der Externen IT-Abteilung. Methodisch hängt die EVM/DeFi-Welle im selben Geflecht wie der Bitwarden-CLI-Vorfall und das Image-Audit nach IDS-Alarm — npm-Lieferkette ist eine Mirror-/Allowlist-Disziplin-Frage, keine Endpoint-Detection-Frage.

Technischer Deep Dive

Die EVM-Welle vom 6. Mai 2026 ist eine Iteration eines Bauplans, den wir seit dem node-env-resolve-RAT (2. Mai) und dem Bitwarden-CLI-Vorfall (22. April) sehen. Drei strukturelle Aspekte:

Aktivierungsfilter statt postinstall

Klassische npm-Supply-Chain-Angriffe nutzen postinstall-Skripte — die laufen sofort bei npm install und sind in jedem ernstgemeinten EDR-Setup eine bekannte Warnung. Die EVM-Welle aktiviert sich stattdessen erst bei require()-Aufruf des Pakets in einer Umgebung, die wie eine echte Ethereum-Workstation aussieht. Aktivierungsfilter prüft: existieren ~/.foundry/, gibt es Wallet-Variablen im Env, läuft das auf einer interaktiven Shell? Wenn nein: still bleiben.

Cluster-Hash und Publisher-Pattern

Alle sechs Pakete tragen byte-identische telemetry.js, SHA-256 71426e93cb6143052d5aeeca920850f8a0343c95bc65aab9a15145848cc5bff1. Ein einzelner npm-User (namikazesarada010206) hat die Pakete im Verlauf weniger Stunden veröffentlicht. Drei davon wurden vom automatischen Erkennungs-System sofort gemeldet, drei nicht — deswegen wurde der Cluster anhand des identischen Hash-Werts nachträglich identifiziert.

Token-Suchpfade

Die Schadrutine liest:

• Environment Variables:ALCHEMY_API_KEY, INFURA_KEY, PRIVATE_KEY, MNEMONIC, DEPLOYER_KEY, ETHERSCAN_API_KEY
• Filesystem-Pfade:~/.foundry/keystores/, ~/.ethereum/keystore/, ~/.brownie/accounts/, ~/.ssh/id_*
• npm-Konfiguration:~/.npmrc auf _authToken, GitHub-Packages-Token, npm-Publish-Token

Aspekte für die Bewertung

• Bauplan, nicht Einzelfall. Heute Ethereum-Variablen, morgen SAP-RFC-Configs, AWS-SSO-Sitzungen oder Active-Directory-Credentials. Aktivierungsfilter sind generisch.
• EDR-Bypass via kalte Aktivierung. Signatur-basierte Detection greift auf postinstall-Trigger, nicht auf require()-Time-Trigger.
• Allowlist als strukturelle Antwort. Mirror-Proxy mit Allowlist + Lockfile-Pin ist die einzige Antwort, die unabhängig von der spezifischen Welle hält.
• Multi-Welle-Pattern. Vier Wellen in sechs Wochen mit identischer Bauanleitung. Die nächste kommt; die einzige Frage ist, in welchem Ökosystem.

Fazit

Diese sechs Pakete sind nicht das Ereignis. Das Ereignis ist die zweite Welle innerhalb von vier Tagen, mit nahezu identischer Bauanleitung, in einem anderen Sprach-Ökosystem. Das Vertrauensmodell von npm ist offen — und es bleibt offen.

Operativ wichtiger als die Einzel-Welle ist das Muster: Aktivierungsfilter statt postinstall, byte-identische Schadrutinen quer durch Paket-Cluster, Web3-Kostüm als plausibler Deckmantel. Wer Mirror-Allowlist, Lockfile-Hygiene und Token-Lebensdauer-Disziplin durchgezogen hat, beantwortet die nächste Welle in Stunden, nicht in einer Wallet-Drain-Forensik.

Realistische Risiko-Einordnung: Hoch für Web3-affine Mittelständler mit Wallet-Schlüsseln auf Standard-Workstations. Mittel für Frontend-Agenturen mit Multi-Mandanten-npm-Stack ohne Allowlist. Niedrig für klassische Web-Stacks mit gepflegter Lockfile-Disziplin und Mirror-Proxy. Die Frage lautet nicht, ob die nächste Welle kommt. Sie lautet, ob sie auf Ihren Maschinen einen Wallet-Schlüssel findet, einen Cloud-Token, eine offene SSH-Sitzung — oder nichts.