Shai-Hulud-Klon in npm: Infostealer und Phantom Bot bedrohen Entwickler

Vier neu entdeckte bösartige npm-Pakete zeigen, wie schnell sich Supply-Chain-Risiken im JavaScript-Ökosystem verschieben: Aus einem Tippfehler in einer Paketinstallation kann ein Infostealer, ein Shai-Hulud-Klon oder sogar ein DDoS-Bot auf einem Entwicklergerät oder CI-Runner werden. OX Security meldete die Pakete am 17. Mai 2026; The Hacker News griff den Vorfall am 18. Mai 2026 auf.

Besonders heikel ist die Mischung: Drei Pakete stehlen Zugangsdaten, Cloud-Credentials, SSH-Schlüssel, Umgebungsvariablen oder Wallet-Daten. Das vierte Paket, axois-utils, liefert zusätzlich einen Go-basierten Phantom Bot aus, der Systeme in ein DDoS-Botnet einbindet.

Betroffene npm-Pakete

Alle vier Pakete wurden laut OX Security durch denselben npm-Nutzer veröffentlicht. Die Namen sind auffällig: chalk-tempalte imitiert ein generisches Template-/Chalk-Muster, axois-utils spielt auf den bekannten HTTP-Client Axios an und nutzt dabei einen klassischen Typosquatting-Dreher.

Warum dieser npm-Angriff gefährlich ist

Der Vorfall ist mehr als ein weiterer Fall von „malicious packages“. Er verbindet drei Trends, die Security-Teams 2026 ernst nehmen müssen: Typosquatting gegen Entwickler, wiederverwendbaren Malware-Code aus früheren Supply-Chain-Angriffen und kompromittierte Entwicklungsumgebungen als Sprungbrett in Cloud, GitHub und CI/CD.

Der Shai-Hulud-Klon in chalk-tempalte ist dabei das deutlichste Signal. OX Security beschreibt das Paket als nahezu unveränderte Kopie des zuvor geleakten Shai-Hulud-Codes. Die Malware nutzt einen eigenen C2-Server, exfiltriert Zugangsdaten und kann gestohlene Daten über die GitHub-API in ein neues öffentliches Repository schreiben. Die dabei genutzte Repository-Beschreibung lautet laut Bericht A Mini Sha1-Hulud has Appeared.

Das passt zu dem Muster, das wir bereits beim Mini-Shai-Hulud-Angriff auf TanStack und beim älteren Shai-Hulud-2.0-Supply-Chain-Angriff gesehen haben: Der eigentliche Schaden entsteht nicht nur im Quellcode, sondern in den Identitäten, Tokens und Automatisierungen rund um den Code.

Technische Analyse: Infostealer und Phantom Bot

Die vier Pakete wurden zwar demselben npm-Account zugeordnet, verhalten sich aber nicht identisch. Das ist für die Verteidigung wichtig: Ein pauschaler „wir suchen nach einer Datei“-Ansatz reicht nicht. Teams müssen Lockfiles, Installationszeitpunkte, ausgehende Netzwerkverbindungen, GitHub-Aktivität und lokale Persistenzartefakte gemeinsam betrachten.

chalk-tempalte: Shai-Hulud als Copycat-Paket

chalk-tempalte ist besonders riskant, weil es laut OX Security einen direkten Klon des geleakten Shai-Hulud-Codes enthält. Der Angreifer ersetzte C2-Server und Schlüssel, ließ die Logik aber im Kern intakt. Ziel sind Secrets, Zugangsdaten, Cloud-Konfigurationen, Wallets und GitHub-Tokens.

axios-util und color-style-utils: direkte Credential-Stealer

@deadcode09284814/axios-util sammelt laut OX Security unter anderem SSH-Schlüssel, Umgebungsvariablen sowie AWS-, GCP- und Azure-Credentials. color-style-utils ist ebenfalls ein Infostealer und sammelt unter anderem IP- und Geodaten sowie Krypto-Wallet-Informationen.

axois-utils: Phantom Bot macht Entwicklergeräte zum DDoS-Werkzeug

axois-utils ist der Ausreißer in der Kampagne. Das Paket enthält einen Go-basierten Bot-Dienst namens Phantom Bot. Laut Analyse kann er HTTP-, TCP- und UDP-Floods ausführen und versucht, nach der Installation auf dem System zu bleiben. Damit wird aus einem Supply-Chain-Angriff nicht nur ein Credential-Theft-Vorfall, sondern potenziell auch ein Missbrauch der eigenen Infrastruktur für Angriffe auf Dritte.

Schnellcheck: Ist mein Projekt betroffen?

Prüfen Sie zuerst die offensichtlichen Stellen: package.json, Lockfiles, CI-Logs, Build-Artefakte und Paketinstallationen auf Entwicklergeräten. Wichtig ist dabei die Schreibweise: axois-utils ist nicht axios-utils, sondern ein Typosquatting-Name.

rg -n '"(chalk-tempalte|@deadcode09284814/axios-util|axois-utils|color-style-utils)"' \
  package.json package-lock.json npm-shrinkwrap.json pnpm-lock.yaml yarn.lock bun.lockb

Zusätzlich lohnt sich ein Blick auf installierte Abhängigkeiten. Der folgende Befehl kann mit einem Fehlercode enden, wenn die Pakete nicht installiert sind; relevant ist die Ausgabe, nicht nur der Exit-Code.

npm ls chalk-tempalte @deadcode09284814/axios-util axois-utils color-style-utils

npm audit und npm audit signatures bleiben sinnvolle Bestandteile einer Security-Baseline. Sie ersetzen aber keine Malware-Hunting-Logik: Frische bösartige Pakete werden oft schneller installiert, als zentrale Advisory- oder Reputationsdatenbanken reagieren können.

Sofortmaßnahmen nach Installation

Wenn eines der Pakete installiert wurde, sollte der erste Reflex nicht „einmal npm uninstall und weiter“ sein. Bei Infostealern und Bot-Persistenz zählt die Reihenfolge: zuerst eindämmen und sichern, dann bereinigen, dann Secrets rotieren.

IOCs: Domains, IPs und Suchmuster

OX Security nennt mehrere Netzwerkindikatoren, die Security-Teams in DNS-, Proxy-, EDR- und Firewall-Logs prüfen sollten. Schreiben Sie die IOCs in Detektionsregeln bewusst defanged, damit sie nicht versehentlich anklickbar oder automatisch aufgelöst werden.

Prävention: npm-Supply-Chain-Schutz für Teams

Dieser Fall zeigt, warum „wir nutzen nur Open Source“ keine Risikostrategie ist. Moderne AppSec muss Paketinstallationen, Entwickleridentitäten und CI/CD-Secrets als zusammenhängendes System behandeln.

• Paketnamen reviewen: Neue direkte Dependencies brauchen Review, besonders bei ähnlich klingenden Namen wie axios versus axois.
• Allowlist für CI/CD: Kritische Builds sollten nur freigegebene Paketquellen und interne Mirrors nutzen.
• Lifecycle-Scripts begrenzen: npm ci --ignore-scripts ist nicht überall praktikabel, aber in Build-Stufen ohne legitime Install-Scripts ein starker Schutz.
• Secrets knapp halten: Entwicklergeräte und PR-Builds sollten keine langlebigen Cloud- oder Publishing-Credentials besitzen.
• Registry-Signaturen und Provenance prüfen: Nutzen Sie npm audit signatures dort, wo es in Ihren Prozess passt.
• Egress überwachen: Build-Systeme brauchen oft Internetzugriff, aber nicht beliebige Verbindungen zu neuen Domains oder ungewöhnlichen Ports.
• AI-Coding-Agenten einbeziehen: Prüfen Sie Agenten- und IDE-Konfigurationen, weil genau dort Tokens, MCP-Zugriffe, Shell-Kommandos und Paketinstallationen zusammenlaufen.

Gerade wer Automatisierung über n8n, CI/CD und Agenten nutzt, sollte die Lehre aus diesem Fall breit ziehen: Ein bösartiges npm-Paket kann nicht nur eine Web-App kompromittieren, sondern auch die Werkzeuge, mit denen diese Web-App gebaut, ausgeliefert und betrieben wird.

Häufige Fragen

Fazit

Die vier bösartigen npm-Pakete sind ein kompakter Vorgeschmack auf die nächste Welle von Supply-Chain-Angriffen: günstige Typosquatting-Köder, wiederverwendete Malware, schnelle Exfiltration und Missbrauch von Entwickler- oder CI-Systemen. Wer betroffen ist, sollte nicht nur Pakete entfernen, sondern Identitäten und Build-Umgebungen prüfen.

Für Unternehmen ist die wichtigste Maßnahme eine klare Baseline: Paketänderungen reviewen, Secrets minimieren, CI-Runner kurzlebig halten, Egress kontrollieren und Verdachtsfälle wie echte Incident-Response-Fälle behandeln. Genau dort entscheidet sich, ob ein einzelner npm-Tippfehler ein kurzer Alarm bleibt oder zum Cloud- und GitHub-Vorfall wird.