FlawOpen

flawopen.com/Incidents/shai-hulud-npm-worm-september-2025

● npm ecosystem · CWE-506 / CWE-829 · September 2025 · Kritisch
Sicherheitsforschung · FlawOpen

Shai-Hulud: der npm-Wurm vom September 2025 und Vertrauen bei der Installation

Die Shai-Hulud-Kampagne im September 2025 nutzte kompromittierte npm-Wartungskonten und schädliche postinstall-Hooks, um Zugangsdaten zu stehlen und weitere infizierte Pakete zu veröffentlichen.[1]

💡 Einfache Erklärung (ELI5)

Stellen Sie sich eine Fabrik vor, die eine Kiste mit Teilen erhält, deren Auspackanleitung sich selbst ausführt. Sie kopiert die Versandabzeichen der Fabrik und nutzt sie, um manipulierte Kisten an andere Fabriken zu senden. Das Abschalten automatischer Anleitungen schließt diesen Zugang, aber die Teile müssen vor Gebrauch weiter geprüft werden.[1]

Kernkonzepte & Begriffe

Lifecycle hook
Im September führte npm postinstall während der Installation schädlichen Code aus. Das ist Paketverhalten und keine npm-Speicherschwachstelle mit CVE.
Publishing credential
Ein npm-Token gewährt die für Konto oder Paket festgelegten Rechte. Gestohlene Veröffentlichungsrechte ließen den Wurm wachsen; Ablauf, Umfang und MFA hängen von Regeln ab.
Trusted publishing / OIDC
OIDC ermöglicht einem berechtigten CI-Ablauf kurzlebige Veröffentlichungsrechte ohne gespeichertes npm-Token. Ein kompromittierter berechtigter Ablauf bleibt gefährlich.

Framework-Zuordnungen

  • CWE-Referenz für die in diesem Leitfaden beschriebene Schwachstelle: CWE-506 CWE-829

Vorfall-Zeitstrahl

2025-09-14

GitHub wurde nach eigenen Angaben über Shai-Hulud informiert.[1]

2025-09-22

GitHub meldete die Entfernung von mehr als 500 kompromittierten Paketen und blockierte Uploads mit passenden Malware-Merkmalen.[1]

Schritt-für-Schritt Angriffsablauf

Schritt 1

Kompromittierte Ausgabe

Ein Wartungskonto veröffentlichte ein verändertes Paket. Phishing war eine Vermutung zum ersten Zugang, kein Beleg für jedes betroffene Konto.[1], [2]

Schritt 2

Ausführung bei Installation

Der postinstall-Hook vom September lief mit den Rechten des Entwicklers oder der CI. preinstall aus November gehört nicht rückwirkend zu dieser Welle.[1], [3], [2]

Schritt 3

Zugangsdaten gefährdet

Der Schadcode suchte in Konfiguration und Umgebung nach npm-, GitHub- und Cloud-Daten; mehr als Veröffentlichungs-Token waren betroffen.[1], [2]

Schritt 4

Vervielfältigung

Gestohlene Veröffentlichungsrechte ermöglichten Änderungen und neue Ausgaben weiterer Pakete, die das Opfer betreute.[1], [2]

Quellcode: Verwundbar vs. Sicher

Sicherer Vergleich von Installationsplänen in Python: Keine Funktion startet npm, liest Zugangsdaten oder kontaktiert die Registry. Das Beispiel folgt der npm-v10-Dokumentation. Der gehärtete Plan verlangt eine geprüfte Sperrdatei, unterdrückt Lebenszyklus-Skripte und übernimmt keine Umgebungsvariablen. Ein echter Runner braucht ein bekanntes npm-Programm sowie isoliertes Home und isolierte Konfiguration ohne Geheimnisse oder sensible Einbindungen. --ignore-scripts sichert weder spätere Importe noch ausdrücklich gestartete Skripte; eine Sperrdatei bestätigt keinen harmlosen Code.

VERWUNDBARE IMPLEMENTIERUNG
def install_plan(reviewed_lockfile, inherited_env):
    # Gibt nur einen Plan zurück: Es werden weder Pakete installiert noch Befehle ausgeführt.
    return {"argv": ["npm", "ci"],
            "env": dict(inherited_env)}
GEHÄRTETER SICHERHEITS-PATCH
def install_plan(reviewed_lockfile, inherited_env):
    # Gibt nur einen Plan zurück: Es werden weder Pakete installiert noch Befehle ausgeführt.
    if reviewed_lockfile is not True:
        raise ValueError("Review the lockfile before installation")
    return {"argv": ["npm", "ci", "--ignore-scripts"],
            "env": {}}

Checkliste für Engineering & Systemsicherheit

Quellen