Der Shai-Hulud npm-Wurm: Wenn lokale Entwickler-Rechner zur grössten Schwachstelle werden

Der blinde Fleck in unseren ach so sicheren Pipelines

Wir Schweizer IT-Teams klopfen uns gerne auf die Schulter. Wir investieren Millionen-Budgets in Schweizer Franken in modernste DevOps-Security, härten unsere CI/CD-Pipelines nach allen Regeln der Kunst und fühlen uns hinter unseren Enterprise-Firewalls in Zürich, Bern oder Genf absolut sicher. Doch was viele nicht wissen: Der eigentliche Angriff findet heute oft weit vor der Pipeline statt. Nämlich genau dort, wo wir am verletzlichsten sind – lokal auf unseren Entwickler-Laptops.

Genau hier setzt die berüchtigte Hacker-Gruppierung TeamPCP mit ihrer 'Mini Shai-Hulud' Kampagne an. Sie haben eindrucksvoll und erschreckend bewiesen, wie extrem verwundbar wir bei einem vermeintlich simplen und alltäglichen 'npm install' sind. Man zieht sich schnell ein Paket für ein neues Feature, und im Hintergrund nimmt das Unheil bereits seinen Lauf, während man noch gemütlich den ersten Kaffee des Tages trinkt.

“This campaign reflects a broader shift in supply chain attacks from isolated package compromise to identity-driven propagation through trusted CI/CD infrastructure. Once attackers gain access to publishing workflows and pipeline identities, the software delivery process itself becomes the distribution mechanism.”

Selbst wenn die Pipeline komplett abgeriegelt und überwacht ist, ermöglicht ein kompromittiertes npm-Paket eine lokale Exfiltration von sensiblen Credentials. Das passiert, noch bevor der geschriebene Code je einen firmeninternen Server oder das GitHub-Repository sieht. Der Entwickler-Rechner wird zum Einfallstor, das all unsere teuren Cloud-Security-Lösungen elegant umgeht.

Shai-Hulud enttarnt: Ein Wurm, der sich selbst verbreitet

Shai-Hulud – passenderweise benannt nach den riesigen, alles verschlingenden Sandwürmern aus dem Dune-Universum – ist kein gewöhnlicher Supply-Chain-Angriff. Wir sprechen hier von einem hochkomplexen, sich selbst verbreitenden Credential-Stealer. Die Malware profiliert die lokale Ausführungsumgebung und zielt präzise auf Cloud-Zugänge, Krypto-Wallets, KI-Tools und CI-Systeme ab.

• TanStack Ökosystem (mit 42 Paketen und 84 betroffenen Versionen)
• Mistral AI und Guardrails AI (KI-Tools stehen massiv im Fokus)
• Zahlreiche kleinere Helfer wie @tnf-dev/* Pakete
• Diverse Capacitor-Plugins für die mobile Entwicklung
• UiPath und OpenSearch Infrastruktur-Komponenten

Besonders erschreckend an dieser Entwicklung: Der Wurm hat die traditionellen Grenzen von npm längst gesprengt. Mittlerweile infiziert die Malware auch PyPI-Pakete im Python-Ökosystem. Laut Daten von OX Security katapultiert das die Reichweite der betroffenen Pakete auf über 518 Millionen kumulierte Downloads. Eine Zahl, bei der jedem CISO der kalte Schweiss ausbrechen dürfte.

Anatomie eines Albtraums: OIDC-Hijacking und gültige SLSA-Zertifikate

Wie kommt der Schadcode überhaupt in diese prominenten Pakete? Die Angreifer nutzen eine raffinierte Methode: Sie kapern GitHub OIDC-Token über verwaiste Commits in Forks. Anstatt mühsam npm-Passwörter zu knacken, tauschen sie ein GitHub OIDC-Token gegen ein temporäres Publish-Token ein. Damit umgehen sie die klassische Zwei-Faktor-Authentifizierung (2FA) komplett und kapern den legitimen Release-Prozess.

“In an extremely rare escalation, the compromised packages carry valid SLSA Build Level 3 provenance attestations, making this the first documented npm worm that produces validly attested malicious packages.”

Das Resultat ist ein absolutes Novum in der Security-Geschichte. Die kompromittierten Pakete tragen gültige SLSA Build Level 3 Provenance-Attestierungen. Für jedes automatisierte Sicherheitstool in unserer Pipeline sehen diese Pakete absolut legitim aus. Spannend wird es bei der Exfiltration der gestohlenen Daten: Um Enterprise-Firewalls zu umgehen, nutzt die Malware das dezentrale Session Protocol über Domains wie filev2.getsession.org. Als Fallback wird sogar die GitHub GraphQL API als toter Briefkasten missbraucht.

Der Dead-Man's Switch: Warum blinder Aktionismus jetzt gefährlich ist

Wer denkt, er könne die Malware nach einer Entdeckung einfach deinstallieren, irrt gewaltig. Die Entwickler hinter Shai-Hulud haben ganze Arbeit geleistet. Die Malware nistet sich extrem tief im System ein, setzt Persistenz-Hooks in Editoren wie Microsoft Visual Studio Code (VS Code) sowie Claude Code und überlebt so jeden Neustart des Rechners mühelos.

• Ein verstecktes Shell-Skript pollt alle 60 Sekunden den GitHub API Endpoint.
• Es prüft kontinuierlich, ob das von der Malware generierte npm-Token noch gültig ist.
• Das Token trägt die warnende Beschreibung: IfYouRevokeThisTokenItWillWipeTheComputerOfTheOwner.
• Bei einem Widerruf wird sofort eine destruktive Routine gestartet.
• Der Befehl rm -rf ~/ wird auf dem betroffenen System ausgeführt.

Ein völlig neues Level der Aggression zeigt dieser eingebaute Dead-Man's Switch. Widerruft ein panischer Entwickler oder ein übereifriger Security-Admin das kompromittierte Token im Dashboard, schnappt die Falle unweigerlich zu. Aus einem stillen Datendieb wird in Sekundenbruchteilen ein zerstörerischer Wiper, der das gesamte Home-Verzeichnis des Entwicklers unwiderruflich löscht.

Ein simpler, aber genialer Schutzschild: pnpm minimumReleaseAge

Wie schützt man sich und sein Team vor Zero-Minute-Malware, die obendrein noch gültig signiert ist? Die Antwort liegt in der simplen, aber hochgradig effektiven Verzögerung. Die allermeisten bösartigen Pakete werden von der wachsamen Community oder automatisierten Scannern glücklicherweise innerhalb der ersten Stunde nach Veröffentlichung entdeckt und aus der Registry entfernt.

Genau hier setzt der moderne Package Manager pnpm an. Mit Version 10.16.0 wurde das Feature 'minimumReleaseAge' eingeführt. Es definiert präzise, wie viele Minuten vergehen müssen, bevor ein neu publiziertes Paket von der CLI installiert werden darf. Seit Version 11 liegt der Standardwert sogar bei 1440 Minuten, was exakt 24 Stunden entspricht.

minimumReleaseAge: 1440

Ein derart simpler Konfigurationseintrag in der .npmrc schützt Entwickler zuverlässig davor, versehentlich brandneue Malware herunterzuladen. Der Angreifer kann zwar ein Paket publizieren, aber pnpm weigert sich schlichtweg, es zu installieren, bis die kritische Phase der Entdeckung verstrichen ist. Das verschafft den Security-Teams den zwingend nötigen Puffer.

Feintuning für den Alltag: Ausnahmen geschickt definieren

Natürlich ist die IT-Welt nicht schwarz-weiss. Es gibt immer wieder Situationen, in denen man im Projektalltag nicht 24 Stunden auf ein kritisches Bugfix-Update warten kann oder will. Für genau diese Fälle haben die Maintainer von pnpm mitgedacht und das Feature 'minimumReleaseAgeExclude' implementiert.

minimumReleaseAge: 1440
minimumReleaseAgeExclude: ['webpack', 'react', '@myorg/*']

Mit dieser Konfiguration kann man spezifische, hochgradig vertrauenswürdige Pakete wie React oder Webpack von der strengen Verzögerungsregel ausnehmen. Seit Version 10.17.0 lassen sich sogar Wildcard-Patterns definieren. Das ist besonders für Schweizer Unternehmen Gold wert: Man kann beispielsweise alle internen Pakete der eigenen Organisation sofort zur Installation freigeben, während externe Abhängigkeiten weiterhin rigoros in Quarantäne bleiben.

Ein Paradigmenwechsel in der IT-Sicherheit

Die Shai-Hulud-Kampagne markiert einen definitiven Wendepunkt in unserer Branche. Der Fokus der Angreifer verschiebt sich massiv. Es geht nicht mehr nur um die reine Kompromittierung eines einzelnen Pakets, sondern um die identitätsgesteuerte Verbreitung über eigentlich vertrauenswürdige CI/CD-Infrastrukturen hinweg. Das blinde Vertrauen in etablierte Mechanismen wie SLSA-Zertifikate wurde nachhaltig erschüttert.

“This latest activity shows the campaign continuing to propagate across both npm and PyPI, with affected packages spanning search infrastructure, AI tooling, aviation-related developer packages, enterprise automation, frontend tooling, and CI/CD-adjacent ecosystems.”

Für Schweizer Dev-Teams und Security-Verantwortliche gilt bei einem konkreten Verdacht in erster Linie: Ruhe bewahren. Blinder Aktionismus ist fatal. Das betroffene System muss sofort vom Firmennetzwerk isoliert und forensisch gespiegelt werden, bevor irgendwelche Tokens widerrufen werden – der Dead-Man's Switch verzeiht keine Fehler. Prävention durch intelligente Tools wie pnpm in Kombination mit einer gesunden Portion Skepsis gegenüber frischen Releases ist heute keine Kür mehr, sondern die absolute Pflicht für jedes professionelle Entwicklungsteam.