Shai-Hulud kehrt zurück: Mehr als 300 NPM-Pakete infiziert

 (helixguard.ai)
17 Punkte von GN⁺ 2025-11-25 | 5 Kommentare | Auf WhatsApp teilen
  • In der NPM-Registry wurden mehr als 1.000 Komponenten innerhalb weniger Stunden nach demselben Muster infiziert und neue Versionen mit Schadcode veröffentlicht
  • Die bösartigen Pakete tarnten sich als Installationsskript für die Bun-Runtime und fügten setup_bun.js sowie das obfuskierte bun_environment.js hinzu; bei der Ausführung wurden mit TruffleHog lokale Zugangsdaten abgegriffen
  • Gesammelte sensible Daten wie AWS/GCP/Azure-, GitHub- und NPM-Tokens wurden über einen GitHub-Actions-Runner namens SHA1HULUD nach außen übertragen
  • Das bösartige Skript führte automatisch npm publish aus und übernahm damit eine wurmartige Selbstreplikation, wodurch letztlich mehr als 27.000 GitHub-Repositories infiziert wurden
  • Der Vorfall gilt als erneutes Beispiel dafür, wie stark die Bedrohung der Supply-Chain-Sicherheit im gesamten Open-Source-Ökosystem ist

Überblick über den Angriff

  • Am 24. November 2025 erkannte HelixGuard in der NPM-Registry, dass mehr als 1.000 Pakete innerhalb weniger Stunden mit derselben Methode infiziert worden waren
    • Die neuen Versionen gaben vor, die Bun-Runtime hinzuzufügen, und enthielten das Skript preinstall: node setup_bun.js
    • Die mit ausgelieferte Datei bun_environment.js war obfuskierter Schadcode, der beim Ausführen TruffleHog herunterlud und startete
  • TruffleHog scannte die lokale Umgebung und stahl dabei NPM-Tokens, AWS/GCP/Azure-Zugangsdaten, Umgebungsvariablen und mehr
  • Die abgegriffenen Informationen wurden genutzt, um den GitHub-Actions-Runner SHA1HULUD zu erstellen, und über ein GitHub-Repository mit der Beschreibung Sha1-Hulud: The Second Coming. nach außen exfiltriert
  • HelixGuard weist darauf hin, dass hinter diesem Angriff wahrscheinlich derselbe Akteur steckt wie beim „Shai-Hulud“-Vorfall im September 2025

Analyse des Schadcode-Verhaltens

  • Bei der Analyse des Pakets @asyncapi/specs zeigte sich beispielhaft, dass die in NPM veröffentlichte Version infiziert war, während das ursprüngliche GitHub-Repository sicher blieb
  • Die Angreifer modifizierten package.json, fügten setup_bun.js hinzu und konfigurierten das Skript so, dass es bun_environment.js aufruft
  • bun_environment.js ist eine stark obfuskierte JavaScript-Datei mit einer Größe von mehr als 10 MB; ihre Hauptfunktionen sind:
    • Sammeln von Cloud-Zugangsdaten und Tokens aus Umgebungsvariablen
    • Scannen nach geheimen Schlüsseln mit TruffleHog
    • Datenexfiltration über GitHub Actions
  • Zusätzlich änderte der Code package.json, fügte die Infektionslogik ein und führte automatisch npm publish aus, um sich wurmartig weiterzuverbreiten

GitHub-Infektion und Datenexfiltration

  • Das bösartige Skript erstellt die Datei .github/workflows/formatter_123456789.yml und registriert den Runner SHA1HULUD
  • Dieser Workflow verpackt die Geheimnisse des Repositories in eine Datei actionsSecrets.json, die doppelt mit Base64 kodiert ist
  • Anschließend wird ein GitHub-Repository mit zufälligem Namen und der Beschreibung Sha1-Hulud: The Second Coming. erstellt, um die Daten hochzuladen
  • HelixGuard bestätigte, dass mehr als 27.000 GitHub-Repositories infiziert wurden
  • Zu den gestohlenen Geheimnissen gehörten Zugangsdaten für verschiedene Dienste wie AWS_ACCESS_KEY_ID, SLACK_WEBHOOK_URL, CODECOV_TOKEN und WEBFLOW_TOKEN

Liste infizierter Pakete

  • HelixGuard berichtet, dass Hunderte von NPM-Paketen infiziert wurden
    • Dazu gehören unter anderem Pakete wichtiger Organisationen wie @asyncapi, @ensdomains, @posthog, @zapier, @postman und @voiceflow
    • Bei jedem Paket waren mehrere Versionen betroffen, etwa @asyncapi/specs@6.8.2 und @postman/csv-parse@4.0.5
  • Die infizierten Pakete tarnten sich überwiegend als legitime Open-Source-Projekte; der Schadcode wurde in den automatisierten Veröffentlichungsprozess eingeschleust

Auswirkungen auf die Sicherheit

  • Dieser Angriff zeigt, wie Schwachstellen in der Supply-Chain-Sicherheit ausgenutzt werden können, um das Open-Source-Ökosystem in großem Maßstab zu infizieren
  • Er macht deutlich, dass die Sicherheit der gesamten Entwicklungsinfrastruktur rund um NPM, GitHub und Cloud-Zugangsdaten stärker abgesichert werden muss
  • HelixGuard empfiehlt, die Installation infizierter Pakete sofort zu stoppen und betroffene Tokens sowie Zugangsdaten umgehend zu widerrufen

Verwandte Beiträge

5 Kommentare

 
ahwjdekf 2025-11-27

Das JS-Ökosystem ist wirklich ein chaotischer Müllhaufen.
 
developerjhp 2025-11-25

Ich habe ein Skript für einen Echtzeit-Scanner erstellt.

Im Pfad des verdächtigen Repositorys
npx sha1-hulud-scanner
eingeben.

Quellcode: https://github.com/developerjhp/sha1-hulud-scanner
 
GN⁺ 2025-11-25
Hacker News-Kommentare

  • Ein Tipp: PNPM statt NPM verwenden
    PNPM 10.x blockiert mehrere Angriffsvektoren
    1️⃣ Standardmäßig werden keine Post-Install-Skripte ausgeführt, dafür ist eine manuelle Freigabe nötig
    2️⃣ Man kann festlegen, dass erst nach einer gewissen Zeit nach Veröffentlichung einer neuen Version installiert wird, z. B. nach 4 Tagen
    NPM ist in Produktions-CLI-Umgebungen zu instabil
    Publisher-Keys sollten auf minimale Rechte beschränkt, nur an bestimmte Pakete gebunden und per IP auf CI/CD-Runner eingeschränkt werden
    Publish-Keys sollten nicht lokal liegen; stattdessen bei Bedarf OIDC Trusted Publisher oder tokenbasierten Zugriff in Betracht ziehen

    • NPM wirkt wie das Ergebnis von zu viel Technical Debt
      Allein bei den Lockfiles gab es gefühlt fünf Anläufe, und trotzdem ist es noch nicht ganz sauber
      Wenn man sich Struktur und Commit-Historie ansieht, arbeitet das Team zwar hart an Verbesserungen, aber es fühlt sich an, als hätten sie in einem sehr tiefen Loch angefangen
      Noch immer wird ein vorzeitiges EOF bei Dateiübertragungen nicht erkannt, unvollständige Dateien bleiben im Cache liegen, und bei langsamen Internetverbindungen führt das zu viel Zeitverlust durch fehlgeschlagene Updates
    • Ich bevorzuge den Ansatz mit dynamischen Secrets von HashiCorp Vault / OpenBao
      Anfangs ist das komplex, aber man kann Secrets als Leases verwalten
      Für jeden CI-Build wird ein Lease erstellt und beim Beenden automatisch verworfen; TTL und automatische Rotation werden ebenfalls unterstützt
      Dadurch lassen sich langfristige Zugangsdaten verbergen, und es werden nur zum Build-Zeitpunkt kurzlebige Tokens ausgegeben
      Dass solche Angriffe im Unternehmen echte Sicherheitsdiskussionen anstoßen, ist immerhin positiv
    • Einfach npm ci verwenden
      Dann werden nur die in package-lock.json festgelegten Versionen installiert, was das Risiko von Angriffen durch automatische Updates reduziert
      Wichtig ist die Gewohnheit, Updates nur gezielt durchzuführen
    • Im Python-Ökosystem bekommt man mit der Option pip install --only-binary=:all: einen ähnlichen Schutz
      Damit werden Source-Distributionen komplett blockiert und nur Wheels installiert
      Das kann allerdings Versionsbeschränkungen mit sich bringen
      In uv lässt sich mit der Option --exclude-newer die Funktion einer minimalen Release-Wartezeit wie bei PNPM nachbilden
    • Ich habe vor Kurzem einen Artikel über „dependency cooldown“ gelesen und konnte dem sehr zustimmen
      Ich pinne alle Abhängigkeiten und prüfe Dependabot-Benachrichtigungen manuell
      Ob das übertrieben oder einfach eine gute Gewohnheit ist, darüber bin ich mir noch nicht sicher

  • Heute besonders passend dazu: „We should all be using dependency cooldowns”
    Automatische Dependency-Updates können gefährlicher sein als eine eintägige Schwachstelle
    Ein infiziertes Paket, das sich bereits in Tausenden Lockfiles verbreitet hat, zurückzurollen, ist deutlich schwieriger

    • Ich denke, es ist besser, nur dann zu aktualisieren, wenn es wirklich nötig ist
      Wenn etwas gut funktioniert, gibt es keinen Grund, es unnötig anzufassen
    • Andererseits muss dann jemand anders die Bugs beheben, und wenn alle Cooldowns verwenden, treten wir am Ende vielleicht auf der Stelle
    • In Pythons uv kann man mit uv lock --exclude-newer $(date --iso -d "24 hours ago") einen ähnlichen Effekt erzielen
      Eine zugehörige Diskussion gibt es in Issue #14992
    • Mit npm-check-updates geht das ebenfalls einfach
      Mit npx npm-check-updates -c 7 lässt sich ein Cooldown von 7 Tagen setzen
      Siehe die Dokumentation zu npm-check-updates
    • Ich stimme dieser Logik nicht zu
      Ein Cooldown kann die Verbreitungszeit einer 0-Day-Schwachstelle verlängern
      Wenn alle denselben Cooldown verwenden, führt das nur zu einer verzögerten Entdeckung

  • Ich bin Mitgründer von PostHog
    Wir waren von diesem Angriff betroffen
    Die infizierten Versionen sind posthog-node 4.18.1, 5.13.3, 5.11.3 / posthog-js 1.297.3 / posthog-react-native 4.11.1 / posthog-docusaurus 2.0.6
    Wir haben alle Keys und Passwörter ausgetauscht und neue Versionen veröffentlicht
    Wir analysieren aktuell die Ursache und werden Updates auf status.posthog.com veröffentlichen

    • Ich empfehle, einen Alarm auszulösen, wenn ein neues Paket-Release nicht mit einer CI/CD-Ausführung verknüpft ist
    • Ich frage mich, ob das infizierte JS tatsächlich Auswirkungen auf echte Nutzer hatte
      Wenn eine Website die infizierte Version ausgeliefert hat, würde ich gern wissen, ob Besucher dadurch betroffen waren
    • Wenn die Ursache noch unbekannt ist, besteht die Möglichkeit, dass sich der Angriff weiterhin ausbreitet
    • Auch die neueste Version könnte wieder infiziert sein; ich frage mich, warum man ihr diesmal vertrauen sollte
    • Gut, dass das Update hier sichtbarer ist als die Mitteilung auf Twitter. Hoffentlich gelingt die Wiederherstellung gut

  • Ernst gemeinte Frage: Ist es sinnvoll, heute noch ein neues Projekt mit Node zu starten?
    Ich baue gerade ein SaaS-Frontend mit Astro und bin bei jedem Dependency-Update nervös
    Das Fehlen von Sicherheit im npm-Ökosystem wirkt auf mich extrem gravierend

    • Das Problem ist nicht Node oder JS, sondern das Packaging-Modell
      Auch Ökosysteme wie Rust, die von unzähligen Subpaketen abhängen, werden so etwas irgendwann erleben
      Vielleicht ist es aus Sicherheitssicht sogar klüger, wie bei C, C++ oder Odin ganz ohne Paketmanager zu arbeiten
    • Ich denke eher, dass es ein Problem von npm selbst ist als von Node
      In letzter Zeit vertraue ich JSR von Deno mehr
      JSR-basierte Pakete werden auch nach npm querveröffentlicht, und es gibt ebenfalls Deno-spezifische Pakete
      Zum Beispiel hat Lume mich als langsamer, aber stabiler SSG beeindruckt
    • Das ist kein ausschließliches Node-Problem
      npm ist nur das größte Repository und deshalb für Angreifer besonders wertvoll
      Das kann genauso gut bei RubyGems oder Cargo passieren
    • Die Forderung, Node zu meiden, geht zu weit
      Es ist einfach das am weitesten verbreitete Ökosystem, daher konzentrieren sich Angriffe darauf
      Man muss Abhängigkeiten nur sorgfältig verwalten und nicht jeden Tag aktualisieren
    • Wir haben unsere Plattform zur Analyse von Produktsicherheit in PHP entwickelt
      Ein Vorteil ist, dass man für das Rendern einer Seite nicht über 100 Abhängigkeiten braucht
      Siehe Projektlink

  • Ich entwickle inzwischen alles nur noch in Podman-Containern
    Ungelesener Code wird bei mir immer in einer isolierten Umgebung ausgeführt
    Perfekt ist das nicht, aber ich halte es für eine minimale Sicherheitsgewohnheit

    • Bei den meisten Menschen geht in 99,99 % der Fälle nichts schief, daher stumpft ihr Risikogefühl ab
      Sicherheit ist meist ein Bereich, der an Experten delegiert wird, deshalb ist es in der Praxis schwer, daran etwas zu ändern
    • npm-Pakete haben sehr tiefe Dependency-Bäume; ich frage mich, wie Container-Isolation in so einem Fall konkret funktioniert
    • Mich würde interessieren, wie man npm-Pakete wie das PostHog-SDK konkret innerhalb eines Containers handhabt
    • Podman ist sicherer als Docker, und bei Bedarf könnte man zusätzliche Isolation wie QEMU in Betracht ziehen
    • Ich logge mich für die Entwicklung sogar per SSH als anderer lokaler Benutzer ein und nutze tmux

  • Vor 12 Jahren war NPM einmal komplett down
    Damals war es einfach ein Open-Source-Projekt, heute gehört es zu Microsoft
    Wenn eines der größten Unternehmen der Welt dahintersteht, sollte es solche Probleme doch lösen können, oder?
    Trotzdem hat sich offenbar nicht viel geändert

    • MS kann nicht einmal Windows ordentlich verwalten
      Alles, womit sich über Enterprise-Lizenzen kein Geld verdienen lässt, wird vernachlässigt
      Deshalb wirkt Windows 11 wie ein einziges Marketingprodukt

  • Wir überwachen die laufenden Angriffsaktivitäten und aktualisieren die Liste infizierter Pakete im Wiz-Blog
    Wir reverse engineeren aktuell die schädliche Payload und wollen die Ergebnisse in den nächsten Stunden teilen

  • Der PostHog-Chat „Talk to a human“ war in Wirklichkeit eine Bot-Antwort, was ziemlich frustrierend war
    Auch der Link zum Notfall-Support wurde nicht sauber angezeigt
    Deshalb die Frage: Welche Versionen sollte man vermeiden?

    • Ich bin Mitgründer. Wir haben es bereits im Hauptthread und auf status.posthog.com angekündigt
      Die infizierten Versionen sind posthog-node 4.18.1, 5.13.3, 5.11.3 / posthog-js 1.297.3 / posthog-react-native 4.11.1 / posthog-docusaurus 2.0.6
      Wenn du auf die neueste Version aktualisierst, bist du sicher
    • Ich habe dieselbe Liste der Versionen auch im Slack-Channel gesehen

  • Ich frage mich, warum es immer im Node-Ökosystem zu solchem Paket-Chaos kommt
    Ich verstehe nicht, warum diese Community komplexe Install-Hooks und automatische Updates für gutes Engineering hält
    Da versteht man, warum der Erfinder von Node schon gegangen ist

    • Node ist das neue PHP
      Riesiges Ökosystem, von Einsteigerentwicklern geprägt, wenig Sicherheitsbewusstsein, und selbst für kleinste Funktionen werden Bibliotheken eingebunden
    • Ein ernstzunehmendes Ökosystem braucht Paket-Maintainer
      Wie bei Debian sollte es vertrauenswürdige Betreuer geben, die Dinge prüfen, aber die JS-Community lehnt das als Gatekeeping ab
      Deshalb wiederholt sich so etwas immer wieder
    • Andere herabzusetzen, um sich überlegen zu fühlen, bringt nur kurz etwas
      Mit so einer Haltung ändert sich am Ende nichts

  • Etwas off topic, aber ich frage mich, wer HelixGuard eigentlich ist
    Die Website ist chaotisch und es gibt kaum Informationen
    Angeblich ist ein Krypto-Exchange Kunde, was etwas verdächtig wirkt
 
laeyoung 2025-11-25

2️⃣ Man kann festlegen, dass eine Installation erst nach einer bestimmten Zeitspanne (z. B. 4 Tagen) nach der Bereitstellung eines neuen Releases erfolgt.

Das ist wirklich eine tolle Funktion. Auch Google lädt gelegentlich fehlerhafte Versionen auf NPM hoch, die wegen Bugs nicht funktionieren; dann denke ich manchmal erst, der Fehler liege bei mir, und bin entsprechend irritiert.