Vier Tage nach dem node-env-resolve-RAT folgte die zweite Welle: Am 6. Mai 2026 erschienen sechs malicious npm-Pakete für die Ethereum-, Hardhat- und Foundry-Welt. Gleicher Code, andere Maske, anderes Ökosystem — und eine schlichte Lehre für jede Build-Pipeline.
Was hat sich geändert? Sechs npm-Pakete mit identischer Schadrutine, geöffnet über EVM-/Hardhat-/Foundry-Tooling-Namen, aktiviert erst bei require() in einer echten Ethereum-Workstation. Wer ist betroffen? Web3-affine Mittelständler, Frontend-Agenturen mit npm-Lockfile-Hygiene-Schwäche, KI-Agent-Betreiber mit dynamischen Tool-Loadern. Was sollten Sie heute lesen? Mirror-Allowlist, Token-Inventur, MCP-Tool-Audit — in dieser Reihenfolge.
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.
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.
Mirror-Proxy auf Allowlist-Modus, sechs Paketnamen explizit blocken, Token-Inventur (auch Test-.env-Dateien), MCP-Tool-Liste gegen Hash-Liste prüfen.
Mittelstand mit Web3-Pilot: sofort. Frontend-Agenturen mit Multi-Mandanten-npm-Stack: Allowlist-Disziplin. KI-Agent-Betreiber: dynamische Tool-Loader gegen Hash-Liste validieren.
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.
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.
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. Ich habe das Muster bereits beim Bitwarden-CLI-Vorfall vom 22. April beschrieben — die Welle vom 6. Mai ist die nächste Iteration.
Bei meinen Bestandskunden habe ich am Morgen des 7. Mai drei Schritte ausgeführt — zwei davon hatte ich 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 habe ich 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 meiner Agent-Setups laden ihre Tool-Listen aus npm-Paketen; ich prüfe jetzt jeden Tool-Namen gegen die telemetry.js-Hash-Listen der letzten vier Wellen. Bei zwei Setups hatte ich Treffer — keine produktiven, alle in Entwicklungs-Branches.
Ich habe nicht alle npm-Installationen pauschal eingefroren. Das ist die falsche Reaktion — sie unterbricht Geschäftsprozesse und verschiebt das Vertrauensproblem nur. Was ich stattdessen tue: 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.
Ich habe 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.
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. Ich habe dazu bereits in meiner 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.
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.
Drei Profile aus meiner Beratungspraxis sitzen heute im Risiko:
| Setup | Hauptrisiko | Typische Folgekosten |
|---|---|---|
| Web3-affine Mittelständler mit Wallet-Schlüsseln auf Entwickler-Maschinen | Schadrutine findet PRIVATE_KEY, MNEMONIC, Keystore-Verzeichnisse | Wallet-Drain innerhalb von Minuten, im DeFi-Kontext oft fünf- bis sechsstellig |
| Frontend-Agenturen mit Multi-Mandanten-npm-Stack | Erstaufschlag npm install bei Kunden-Onboarding zieht transitiv die sechs Pakete | Cross-Mandanten-Eskalation, npm-Token-Exfiltration, Lateral-Movement in andere Repos |
| KI-Agent-Betreiber mit dynamischen Tool-Loadern | Agent lädt Tool-Definition per Paketname, npm-Resolution greift kompromittiertes Paket | Agent-Sandbox-Bypass, Token-Diebstahl im Agent-Prozess-Kontext |
| CI/CD-Runner mit transitiver Web3-Dependency | Build-Token, NPM_TOKEN, GitHub-Actions-Secrets im Runner-Env exponiert | Supply-Chain-Pipeline-Eskalation, Build-Artefakte kompromittiert |
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.
Die kurze Antwort: Mirror-Proxy auf Allowlist, sechs Paketnamen blocken, Hash-Liste prüfen. Vier Schritte:
# 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
.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)
# 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
# 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.
Fünf Kernfragen, wenn npm in Ihrem Stack läuft:
npm ls --all, dann grep -iE '(viem|hardhat|foundry|web3)'.# 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
Die Empfehlung hängt vom Setup ab. Vier Szenarien, vier Antworten — mit einem operativen Entscheidungsraster vorab:
Entscheidungsraster: Wann jetzt rotieren, wann beobachten?
PRIVATE_KEY oder MNEMONIC auf einer betroffenen Workstation lagen und der Erstaufschlag npm install die sechs Pakete gezogen haben könnte.ALCHEMY_API_KEY, INFURA_KEY oder ein vergleichbarer Cloud-Provider-Token im User-Home lag.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.
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.
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.
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.
Bei meinen Bestandskunden habe ich am Morgen des 7. Mai drei Schritte ausgeführt — zwei davon hatte ich bereits am 4. Mai initiiert (node-env-resolve-Welle), einer ist neu hinzugekommen.
MNEMONIC und DEPLOYER_KEY-Variablen in Test-.env-Dateien unter ~/Documents/projects/. Wallets rotiert, alte geleert.telemetry.js-Hash-Listen der letzten vier Wellen geprüft. Bei zwei Setups Treffer in Dev-Branches, keine produktiv.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 meine laufende operative Praxis. 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.
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:
postinstallKlassische 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.
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.
Die Schadrutine liest:
ALCHEMY_API_KEY, INFURA_KEY, PRIVATE_KEY, MNEMONIC, DEPLOYER_KEY, ETHERSCAN_API_KEY~/.foundry/keystores/, ~/.ethereum/keystore/, ~/.brownie/accounts/, ~/.ssh/id_*~/.npmrc auf _authToken, GitHub-Packages-Token, npm-Publish-Tokenpostinstall-Trigger, nicht auf require()-Time-Trigger.Direkt selten, transitiv häufig. Frontend-Stacks, CMS-Plugins für Auth-Walls oder NFT-Belohnungen, ESG-Tools mit Blockchain-Anbindung — all das zieht Pakete aus dem Web3-Umfeld in node_modules. Prüfen Sie ein npm ls viem hardhat foundry in Ihren Repos. Wer dort Treffer hat, ist im Bewertungskreis.
Sie hilft gegen spätere unbeabsichtigte Versions-Sprung-Kompromittierungen. Sie hilft nicht beim Erstaufschlag. Wenn ein Entwickler ein neues Repo aufsetzt, ein neues Paket ausprobiert oder eine fremde node_modules mit npm install neu auflöst, ist das Lockfile noch nicht da — oder es enthält bereits den bösartigen Eintrag. Allowlist-Mirror ist die einzige Schicht, die diese Klasse adressiert.
Drei Schritte. Erstens: Suche nach den sechs Paketnamen in package-lock.json und node_modules aller aktiven Repositories. Zweitens: Hash-Vergleich auf telemetry.js gegen den veröffentlichten SHA-256 71426e93…. Drittens: Prüfung der HKCU-/LaunchAgent-/systemd-Persistenz und ungewöhnlicher langlaufender Node-Prozesse. Bei Treffer: Maschine isolieren, Tokens rotieren, sauber neu aufsetzen.
Für eine kleine Entwickler-Mannschaft (5–20 Personen) zwei bis vier Personentage für Setup, Verdaccio- oder JFrog-Konfiguration und Onboarding der bestehenden Projekte. Laufende Pflege: ein bis zwei Stunden pro Woche, vor allem für neue Paket-Approvals. Der Schmerz steckt nicht im Aufbau, sondern in der Disziplin, neue Pakete nicht spontan zu erlauben.
Mehr als die meisten denken. KI-Agent-Stacks laden Tool-Definitionen oft als npm-Pakete — das ist genau der Mechanismus, den die Welle vom 6. Mai ausgenutzt hätte, wäre sie auf Tool-Namen statt auf Web3-Bibliotheken gegangen. Ein Agent, der ein neues Tool installiert, ist eine Build-Pipeline mit weniger Reibung. Diese Klasse benötigt dieselbe Allowlist-Disziplin wie der Entwickler-Laptop.
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.