Shai-Hulud-Wurm kompromittiert npm-Paket von Tensorlake und stiehlt Zugangsdaten
Das TypeScript-SDK tensorlake wurde über eine neue Shai-Hulud-Variante infiziert. Eine Version enthielt einen Preinstall-Hook, der Tokens, Cloud-Schlüssel und Krypto-Wallets abgriff. Selbst-Hoster von n8n sollten jetzt handeln.
Veröffentlicht am 9. Oktober • Zuerst erschienen auf cortexflow.tech
Am 8. Oktober 2026 wurde das npm-Paket tensorlake, das TypeScript-SDK für Tensorlakes AI-Agent-Infrastruktur, durch eine neue Variante des Shai-Hulud-Wurms kompromittiert. Version 0.5.144 enthielt einen Preinstall-Hook, der auf jeder Maschine, auf der das Paket installiert wurde, npm-Tokens, GitHub-Tokens, AWS-Schlüssel, SSH-Schlüssel,.env-Dateien, Krypto-Wallets und Browser-Passwörter stahl. Die Version wurde innerhalb weniger Minuten zurückgezogen, doch die Schadsoftware bleibt auf infizierten Hosts bestehen.
Wenn du n8n selbst hostest, ist genau das dein Bedrohungsmodell: Du lebst auf npm. Jedes Community-Node, das du installierst, jeder Docker-Rebuild, der npm install ausführt, jedes npx in deiner CI-Pipeline führt Installationsskripte aus. Dieser Artikel geht genau darauf ein, wie dieser Angriff funktionierte, und liefert eine konkrete Checkliste, mit der deine Geheimnisse beim nächsten Vorfall geschützt bleiben.
Laut der Analyse von Aikido begann die Infektion nicht mit einem typoverwechselten Paket. Sie begann im legitimen tensorlake-GitHub-Repository. Am 7. Oktober tätigte der Angreifer verifizierte Commits unter der Identität eines Maintainers. Die Schadsoftware wurde im Commit 41b38f0 über einen direkten Datei-Upload eingeschleust, und der Angreifer erhöhte anschließend die Versionsnummer, um eine Veröffentlichung auszulösen. Das Repository war rund 20 Stunden lang kompromittiert, bevor Version 0.5.144 auf npm live ging.
Deine Abhängigkeit kann direkt an der Quelle vergiftet werden, nicht nur über einen ähnlich klingenden Namen. Die Registry hat alles richtig gemacht. Das Paket war echt, die Version war echt, die Herausgeber-Identität wurde auf Repository-Ebene gestohlen.
Zeitleiste laut Socket, das die bösartige Veröffentlichung 11 Minuten nach dem Publish meldete, am 8. Oktober um 01:23:10 UTC:
Mit rund 12.000 wöchentlichen Downloads und mehr als 1.000 GitHub-Sternen ist die Reichweite des Pakets keineswegs trivial. Selbst ein Fenster von wenigen Minuten kann CI-Pipelines treffen, die bei jedem Lauf die neueste Version installieren.
Ein kompromittiertes Paket greift nicht deinen Server an, sondern die Entwicklermaschine, auf der es installiert wird.
Die vergiftete Veröffentlichung enthielt einen npm-Preinstall-Hook, ein Skript, das automatisch in dem Moment ausgeführt wird, in dem du das Paket installierst, noch bevor dein Code es überhaupt berührt. Das ist die Kette:
Die Liste der gestohlenen Daten liest sich wie ein Inventar des Lebens eines beruflichen Entwicklers: npm-Tokens, GitHub-Tokens, AWS-Zugangsdaten und Secrets, HashiCorp-Vault-Daten, Kubernetes-Zugangsdaten, SSH-Schlüssel,.env-Dateien, Krypto-Wallets, Browser-Passwörter, Konfigurationsdateien von Anthropic Claude und Daten von Messaging-Apps. Diese Variante zielt zudem gezielt auf 14 Krypto-Browsererweiterungen. Aikido weist darauf hin, dass dies auf einen Betreiber hindeutet, der infizierte Entwickler-Endpunkte schneller in Geld umwandeln will, statt die Weiterverbreitung in der Supply Chain voranzutreiben.
Der üble Teil, vor dem Socket warnt: Die Persistenz kann das Entfernen der Abhängigkeit überstehen. Und laut Berichten von The Register überwacht diese Variante bestimmte gestohlene GitHub-Tokens. Wird eines davon widerrufen, kann die Schadsoftware unter bestimmten Bedingungen das Home-Verzeichnis des infizierten Nutzers löschen. Das bedeutet: Die Reihenfolge der Bereinigung ist entscheidend. Deaktiviere den bösartigen Token-Monitor, bevor du Zugangsdaten widerrufst, sonst lässt der Angreifer die Maschine aus Rachsucht verbrennen.
Die meisten selbst gehosteten n8n-Setups hängen mindestens auf eine dieser Arten von npm ab:
Das tieferliegende Problem: Ein Workflow-Automatisierungsserver ist ein Sammelpunkt für Geheimnisse. Dein n8n-Host speichert API-Schlüssel für OpenAI, Stripe, deine Datenbank und dein CRM, also genau die Art von Material, die dieser Wurm zu ernten gebaut wurde. Eine infizierte Build-Maschine kompromittiert nicht nur ein einzelnes Konto, sondern die Schlüssel, auf denen dein Geschäft läuft.
Ein selbst gehosteter Automatisierungsserver ist ein Sammelpunkt für Geheimnisse, und genau das jagt dieser Wurm.
Dies ist eine Anleitung, eingebettet in eine Nachricht, denn die nächste Shai-Hulud-Welle wird dasselbe Muster verwenden.
Durchsuche deine Lockfiles und den Installationsverlauf:
grep -r "tensorlake" package-lock.json yarn.lock pnpm-lock.yaml 2>/dev/null npm ls tensorlake 2>/dev/null Enter fullscreen mode Exit fullscreen mode Wenn die Antwort Ja lautet: Führe nicht einfach eine Deinstallation durch. Die Deinstallation entfernt das Paket, aber nicht die Persistenz. Sockets Empfehlung: Baue das betroffene System aus einer vertrauenswürdigen Quelle neu auf, bevor du den Zugriff auf Secrets wiederherstellst, und rotiere jede Zugangsberechtigung, die die Maschine sehen konnte, und widerrufe sie anschließend. Und den Warnungen der Forscher folgend, neutralisiere den Token-Monitor, bevor du betroffene Tokens widerrufst.
Die meisten Installationsskripte sind Komfort, keine Notwendigkeit. Deaktiviere sie:
npm config set ignore-scripts true Enter fullscreen mode Exit fullscreen mode Warum das funktioniert: Preinstall-Hooks, also genau der Mechanismus, den dieser Wurm nutzte, werden schlicht nie ausgeführt. Wenn ein Paket seinen Build-Schritt wirklich braucht, was bei Anwendungen selten der Fall ist, erlaubst du es explizit pro Paket. In Docker-Builds entfernt diese eine Zeile die Angriffsfläche zur Installationszeit aus jedem Image, das du erstellst.
Schwebende Versionsbereiche wie ^0.5.144 in einer CI-Pipeline, die nächtlich läuft, machen aus einem 20-stündigen bösartigen Zeitfenster deinen Vorfall. Pinnen exakte Versionen, committe die Lockfile und mache Abhängigkeits-Updates zu einer bewussten, überprüfbaren Pull-Request-Entscheidung, nicht zu einem automatischen Abruf. n8ns eigene 3.0-Empfehlung zu unverifizierten Community-Nodes zeigt in dieselbe Richtung: Behandle jedes installierte Paket als Vertrauensentscheidung.
Führe npm install in Wegwerf-CI-Runnern oder Containern aus, in die keine langlebigen Zugangsdaten eingebunden sind, und niemals auf der Maschine, auf der deine Produktions-Secrets liegen. Wenn dein n8n-Host und deine Build-Maschine derselbe Rechner sind, ist das die wichtigste strukturelle Korrektur, die dir zur Verfügung steht.
Socket meldete diese Veröffentlichung in 11 Minuten. Tools wie Sockets Scanner oder Aikidos Safe Chain fangen npm- und npx-Installationen ab und prüfen Pakete vor deren Ausführung gegen Malware-Informationen. Eines davon in deiner CI ist eine günstige Versicherung gegen die nächste Welle. Die Kompromittierung von keyv/flat-cache im August nutzte dieselbe ChainDrop-Familie, und das Muster ist eindeutig noch nicht vorbei.
Shai-Hulud hat sich vom generellen npm-Typosquatting zu einem eigens gebauten Jäger von AI-Infrastruktur entwickelt. Die Kompromittierung von Tensorlake ist der erste öffentlich bekannte Fall, in dem der Wurm auf eine AI-Agenten-Plattform übersprang, und die Hinwendung des Betreibers zu Krypto-Wallets und Browser-Speichern deutet darauf hin, dass diese Kampagnen als profitables kriminelles Geschäft geführt werden, nicht als einmalige Aktionen.
Für Agenten-Entwickler ist die Erkenntnis struktureller Natur: Die Sicherheit deines Automatisierungs-Stacks ist die Vereinigung der Sicherheit aller Abhängigkeiten. Das perfekt konfigurierte AI-Agent-Node bedeutet nichts, wenn das Installationsskript, das dein Community-Node geliefert hat, zuerst setup.mjs ausgeführt hat. Secrets-Hygiene, Installations-Isolation und Installationen mit deaktivierten Skripten sind die günstigsten Verteidigungen, die du hast. Setze sie ein, bevor du sie brauchst.
Als Nächstes: Führe das grep aus Schritt 1 noch heute für deine Projekte aus, und wenn eine Lockfile 0.5.144 zeigt, behandle es als aktiven Vorfall, nicht als Aufräumaufgabe.
Nein. Der bösartige Code lief nur auf Maschinen, die tensorlake@0.5.144 in dem Zeitfenster installierten, bevor das Paket aus npm entfernt wurde. Wenn du es nie in einer Lockfile oder im Installationsprotokoll hattest, bist du von diesem speziellen Vorfall nicht betroffen, aber die oben genannten Härtungsschritte schützen dich vor der nächsten.
Ein normal kompromittiertes Paket läuft erst, wenn du seinen Code ausführst. Ein Preinstall-Hook wird automatisch während npm install ausgeführt, mit den Rechten deines Nutzers, auf der Maschine, die die Installation durchführt, und diese hält häufig CI-Secrets, AWS-Schlüssel und SSH-Zugangsdaten. Du wirst infiziert, ohne die Bibliothek jemals zu importieren.
Teilweise. Docker isoliert den laufenden Workflow vom Host, aber RUN npm install in deinem Dockerfile führt während des Builds weiterhin Preinstall-Hooks aus, und Build-Umgebungen tragen oft Registry-Zugangsdaten mit sich. Die Lösung ist npm config set ignore-scripts true in deinen Dockerfiles plus Multi-Stage-Builds, die Build-Zeit-Secrets nicht durchsickern lassen.
Socket meldete tensorlake@0.5.144 am 8. Oktober 2026 um 01:23:10 UTC, etwa 11 Minuten nach der Veröffentlichung. Die Version wurde anschließend aus der npm-Registry entfernt. Die Geschwindigkeit der Erkennung hilft Hosts nicht, die während des Zeitfensters installiert haben, weshalb das Scannen vor der Installation erfolgen muss.
[Quellen: Socket, Aikido, The Hacker News, The Register ]
Zuerst veröffentlicht auf CortexFlow. Kostenlose n8n-Vorlagen: https://cortexflow.tech/templates/
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
Posted on Oct 9 • Originally published at cortexflow.tech
On October 8, 2026, the npm package tensorlake — the TypeScript SDK for Tensorlake's AI agent infrastructure — was compromised by a new Shai-Hulud worm variant. Version 0.5.144 shipped a preinstall hook that stole npm tokens, GitHub tokens, AWS keys, SSH keys,.env files, crypto wallets, and browser passwords from every machine that installed it. The version was pulled within minutes, but the malware persists on infected hosts.
If you self-host n8n, this is your threat model: you live on npm. Every community node you install, every Docker rebuild that runs npm install, every npx in your CI pipeline runs install scripts. This article walks through exactly how this attack worked — and the concrete checklist that keeps your secrets out of the next one.
According to Aikido's analysis, the infection didn't start with a typo-squatted package. It started inside the legitimate tensorlake GitHub repository. On October 7, the threat actor made verified commits under the identity of a maintainer — the malware was introduced in commit 41b38f0 via direct file upload, and the actor then bumped the version to trigger a publish. The repository was compromised for roughly 20 hours before version 0.5.144 went live on npm.
Your dependency can be poisoned at the source, not just by a lookalike name. The registry did everything "right" — the package was real, the version was real, the publisher identity was stolen at the repo level.
Timeline, per Socket (who flagged the malicious release 11 minutes after it published, at 01:23:10 UTC on October 8):
With ~12,000 weekly downloads and 1k+ GitHub stars, the package's reach is far from trivial — even a minutes-long window can hit CI pipelines that install the latest version on every run.
A compromised package doesn't attack your server — it attacks the developer machine that installs it.
The poisoned release carried an npm preinstall hook — a script that runs automatically the moment you install the package, before your code ever touches it. Here's the chain:
The stolen-data list reads like an inventory of a working developer's life: npm tokens, GitHub tokens, AWS credentials and secrets, HashiCorp Vault data, Kubernetes credentials, SSH keys,.env files, crypto wallets, browser passwords, Anthropic Claude config files, and messaging app data. This variant also targets 14 cryptocurrency browser extensions specifically — Aikido notes this suggests an operator more focused on quickly monetizing infected developer endpoints than on further supply-chain propagation.
The nasty part Socket warns about: persistence can survive removing the dependency. And per The Register's reporting, this variant monitors certain stolen GitHub tokens — if one is revoked, the malware can trigger deletion of the infected user's home directory under specific conditions. That means the cleanup order matters: disable the malicious token monitor before you revoke credentials, or the attacker burns the machine out of spite.
Most self-hosted n8n setups depend on npm in at least one of these ways:
The deeper problem: a workflow automation server is a secrets concentration point. Your n8n host holds API keys for OpenAI, Stripe, your database, your CRM — the exact kind of material this worm was built to harvest. An infected build machine doesn't just compromise one account; it compromises the keys that run your business.
A self-hosted automation server is a secrets concentration point — exactly what this worm hunts.
This is a how-to embedded in the news, because the next Shai-Hulud wave will use the same shape.
Search your lockfiles and install history:
grep -r "tensorlake" package-lock.json yarn.lock pnpm-lock.yaml 2>/dev/null npm ls tensorlake 2>/dev/null Enter fullscreen mode Exit fullscreen mode If the answer is yes: do not just uninstall. Uninstalling removes the package but not the persistence. Socket's guidance: rebuild the affected system from a trusted source before restoring access to secrets, and rotate every credential the machine could see — then revoke. And per researcher warnings, neutralize the token monitor before revoking affected tokens.
Most install scripts are conveniences, not necessities. Disable them:
npm config set ignore-scripts true Enter fullscreen mode Exit fullscreen mode Why it works: preinstall/preinstall hooks — the exact mechanism this worm used — simply never execute. If a package genuinely needs its build step (rare for apps), allow it explicitly per-package. In Docker builds, this one line removes the install-time attack surface from every image you build.
Floating ranges ( ^0.5.144 ) in a CI pipeline that runs nightly is how a 20-hour malicious window becomes your incident. Pin exact versions, commit the lockfile, and make dependency updates a deliberate, reviewable PR — not an automatic pull. n8n's own 3.0 guidance on unverified community nodes points the same direction: treat every installed package as a trust decision.
Run npm install in throwaway CI runners or containers with no long-lived credentials mounted — never on the machine that holds your production secrets. If your n8n host and your build machine are the same box, that is the single biggest structural fix available to you.
Socket flagged this release in 11 minutes. Tools like Socket's scanner or Aikido's Safe Chain intercept npm / npx installs and check packages against malware intel before they run. One of them on your CI is cheap insurance against the next wave — the August keyv/flat-cache compromise used the same ChainDrop family, and the pattern is clearly not done.
Shai-Hulud has evolved from generic npm typosquatting into a purpose-built AI-infrastructure hunter. The Tensorlake compromise is the first public case of the worm jumping to an AI agent platform — and the operator's pivot toward crypto wallets and browser stores suggests these campaigns are being run as profitable criminal operations, not one-off stunts.
For agent builders, the takeaway is structural: your automation stack's security is the union of every dependency's security. The AI Agent node you configured perfectly means nothing if the install script that delivered your community node ran setup.mjs first. Secrets hygiene, install isolation, and script-disabled installs are the cheapest defenses you have — adopt them before you need them.
Next: run the grep in step 1 across your projects today — and if any lockfile shows 0.5.144, treat it as an active incident, not a cleanup task.
No. The malicious code only ran on machines that installed tensorlake@0.5.144 during the window before it was removed from npm. If you never had it in a lockfile or install log, you're not affected by this specific incident — but the hardening steps above protect you from the next one.
A normal compromised package only runs when you execute its code. A preinstall hook runs automatically during npm install, with your user's permissions, on the machine doing the install — which often holds CI secrets, AWS keys, and SSH credentials. You get infected without ever importing the library.
Partially. Docker isolates the running workflow from the host, but RUN npm install in your Dockerfile still executes preinstall hooks during the build — and build environments often carry registry credentials. The fix is npm config set ignore-scripts true in your Dockerfiles plus multi-stage builds that don't leak build-time secrets.
Socket flagged tensorlake@0.5.144 at 01:23:10 UTC on October 8, 2026 — roughly 11 minutes after publication. The version was then removed from the npm registry. Speed of detection doesn't help hosts that installed during the window, which is why scanning must happen before install.
[Sources: Socket, Aikido, The Hacker News, The Register ]
Originally published on CortexFlow. Free n8n templates: https://cortexflow.tech/templates/