Malware mit Shai-Hulud-Thema in der PyTorch-Lightning-Bibliothek für AI-Training entdeckt | Semgrep

• Die PyPI-Versionen lightning 2.6.2 und 2.6.3 wurden nach ihrer Veröffentlichung am 30. April 2026 für einen Supply-Chain-Angriff missbraucht; bereits pip install lightning konnte ein verstecktes Verzeichnis _runtime und eine verschleierte JavaScript-Payload ausführen
• Die bösartige Payload wird beim Import des Moduls automatisch ausgeführt und stiehlt Zugangsdaten, Authentifizierungs-Token, Umgebungsvariablen und Cloud-Geheimnisse; außerdem versucht sie, GitHub-Repositories zu kompromittieren
• Der Einstiegspunkt dieses Angriffs ist zwar PyPI, die Wurmverbreitung erfolgt jedoch über npm; findet die Malware npm-Publishing-Zugangsdaten, injiziert sie setup.mjs als Dropper und router_runtime.js in veröffentlichbare Pakete und publiziert anschließend eine neue Patch-Version
• Für den Datenabfluss werden vier parallele Kanäle genutzt: HTTPS-POST, ein Dead-Drop über die GitHub-Commit-Suche, öffentlich zugängliche GitHub-Repositories unter Kontrolle der Angreifer und direkte Pushes in Repositories der Opfer; als Indikatoren bleiben das Commit-Präfix EveryBoiWeBuildIsAWormyBoi und die Repository-Beschreibung "A Mini Shai-Hulud has Appeared" zurück
• Die Malware verankert sich über den SessionStart-Hook in .claude/settings.json von Claude Code und über Tasks mit runOn: folderOpen in .vscode/tasks.json von VS Code, sodass der Dropper jedes Mal beim Öffnen des Repositories ausgeführt wird; Maschinen, die das bösartige Paket im betroffenen Zeitraum importiert haben, sollten als vollständig kompromittiert gelten

---

Betroffene Pakete und Prüfverfahren

• lightning ist ein Deep-Learning-Framework, das häufig im Dependency-Tree von Teams enthalten ist, die Bildklassifikatoren bauen, LLMs feintunen, Diffusionsmodelle ausführen oder Zeitreihenprognosen entwickeln

• Betroffene Pakete

  • lightning Version 2.6.2
  • lightning Version 2.6.3

• Prüfverfahren für Semgrep-Kunden

  • Wenn in letzter Zeit kein Projekt-Scan durchgeführt wurde, sollte ein neuer Scan gestartet werden
  • Auf der Advisories-Seite kann geprüft werden, ob ein Projekt diese Paketversionen kürzlich installiert hat
  • Mit dem Dependency-Filter lassen sich Treffer prüfen; wenn „No matching dependencies“ angezeigt wird, bedeutet das, dass das Projekt die bösartige Abhängigkeit aktuell nicht aktiv verwendet
  • Wenn Treffer vorhanden sind, sollten die unerwarteten Dateien in den Verzeichnissen .claude/ und .vscode/, die unten als Kompromittierungsindikatoren aufgeführt sind, im Repository geprüft werden
  • GitHub-Token, Cloud-Zugangsdaten und API-Keys, die sich in betroffenen Umgebungen befunden haben könnten, sollten ausgetauscht werden
  • Allgemeine Hinweise zur Reaktion auf Supply-Chain-Angriffe und zu Wartezeiten finden sich unter $foo compromised in $packagemanager und Attackers are Still Coming for Security Companies

Wie sich der Angriff von PyPI auf npm ausbreitet

• Anders als mini Shai-Hulud, das npm direkt ins Visier nahm, liegt der Einstiegspunkt dieses Angriffs bei PyPI
• Die bösartige Payload ist weiterhin JavaScript, und die Wurmverbreitung erfolgt über npm
• Findet die ausgeführte Malware npm-Publishing-Zugangsdaten, injiziert sie setup.mjs als Dropper und router_runtime.js in alle Pakete, die mit diesem Token veröffentlicht werden können
• Anschließend setzt sie scripts.preinstall so, dass der Dropper ausgeführt wird, erhöht die Patch-Version und veröffentlicht das Paket erneut
• Nachgelagerte Entwickler, die das jeweilige Paket installieren, führen die komplette Malware auf ihren Maschinen aus; darauf folgen Token-Diebstahl und eine weitere Wurminfektion von Paketen

Methode des Datenabflusses

• Die Exfiltrationsfunktion teilt Mechanismen und Design mit der früheren Kampagne Mini Shai-Hulud und verwendet vier parallele Kanäle, damit Daten selbst dann abfließen, wenn einzelne Pfade blockiert werden
• Der Angriff enthält ein Shai-Hulud-Thema, darunter die Erstellung eines öffentlichen Repositories mit dem Namen EveryBoiWeBuildIsaWormBoi
• Die Struktur der Angriffsspuren entspricht der früheren Kampagne mini Shai-Hulud; die bösartigen Commit-Nachrichten verwenden jedoch das Präfix EveryBoiWeBuildIsAWormyBoi, um sich vom ursprünglichen Mini-Shai-Hulud-Angriff zu unterscheiden

• C2-Übertragung per HTTPS POST

  • Exfiltrierte Daten werden sofort über Port 443 per POST an Server unter Kontrolle der Angreifer gesendet
  • Domain und Pfad sind als verschlüsselte Strings in der Payload gespeichert, um die statische Analyse zu erschweren

• Dead-Drop über GitHub-Commit-Suche

  • Die Malware pollt die GitHub-Commit-Such-API und sucht nach Commit-Nachrichten mit dem Präfix EveryBoiWeBuildIsAWormyBoi
  • Die Commit-Nachrichten transportieren ein doppelt Base64-kodiertes Token im Format EveryBoiWeBuildIsAWormyBoi:<base64(base64(token))>
  • Das decodierte Token wird anschließend zur Authentifizierung eines Octokit-Clients für weitere Aktionen verwendet

• Öffentliches GitHub-Repository unter Kontrolle der Angreifer

  • Es wird ein neues öffentliches Repository mit einem zufällig gewählten Dune-Wortnamen und der Beschreibung "A Mini Shai-Hulud has Appeared" erstellt
  • Diese Beschreibung kann direkt auf GitHub gesucht werden
  • Gestohlene Zugangsdaten werden als results/results-<timestamp>-<n>.json committet; über die API sind sie Base64-kodiert, intern aber normales JSON
  • Dateien über 30 MB werden in nummerierte Chunks aufgeteilt
  • Als Tarnung wird die Commit-Nachricht chore: update dependencies verwendet

• Direkter Push in Opfer-Repositories

  • Erhält die Malware ein GitHub-Server-Token mit Präfix ghs_, pusht sie Exfiltrationsdaten direkt auf alle Branches von GITHUB_REPOSITORY des Opfers

Ziele der Exfiltration

• Die Malware zielt auf Zugangsdaten in lokalen Dateien, der Umgebung, CI/CD-Pipelines und bei Cloud-Anbietern

• Dateisystem

  • Es werden mehr als 80 Pfade zu Dateien mit Zugangsdaten nach Token wie ghp_, gho_ und npm_ durchsucht
  • Pro Datei werden bis zu 5 MB verarbeitet

• Shell und Umgebungsvariablen

  • gh auth token wird ausgeführt
  • Alle Umgebungsvariablen aus process.env werden ausgegeben

• GitHub Actions

  • Auf Linux-Runnern wird mit dem eingebauten Python der Prozessspeicher von Runner.Worker gedumpt
  • Alle Geheimnisse mit Markierung "isSecret":true sowie GITHUB_REPOSITORY und GITHUB_WORKFLOW werden extrahiert

• GitHub-Organisationen

  • Es wird geprüft, ob ein Token die Scopes repo und workflow besitzt
  • Organisationsgeheimnisse für GitHub Actions werden durchlaufen

• AWS

  • Über Umgebungsvariablen, Profile in ~/.aws/credentials, IMDSv2 169.254.169.254 und ECS 169.254.170.2 wird versucht, sts:GetCallerIdentity aufzurufen
  • Alle Werte aus Secrets Manager und SSM-Parametern werden aufgelistet und abgerufen

• Azure

  • Mit DefaultAzureCredential werden Subscriptions aufgelistet und Geheimnisse in Key Vault gelesen

• GCP

  • Die Authentifizierung erfolgt mit GoogleAuth
  • Alle Geheimnisse im Secret Manager werden aufgelistet und abgerufen
  • Der Zielbereich umfasst lokale Entwicklungsumgebungen, CI-Runner und alle drei großen Cloud-Anbieter
  • Alle Maschinen, die das bösartige Paket im betroffenen Zeitraum importiert haben, sollten als vollständig kompromittiert gelten

Persistenz über Entwickler-Tools

• Nachdem die Malware in ein Repository gelangt ist, zielt sie auf weit verbreitete Entwickler-Tools wie Claude Code und VS Code, um Persistenz-Hooks zu verankern

• Claude Code

  • Die Malware schreibt in .claude/settings.json, die Konfigurationsdatei von Claude Code im Repository, einen SessionStart-Hook mit matcher: "*"
  • Der Hook verweist auf node .vscode/setup.mjs
  • Er wird jedes Mal ausgeführt, wenn ein Entwickler Claude Code in einem infizierten Repository öffnet; weder die Nutzung weiterer Tools noch weitere Benutzeraktionen sind dafür nötig

• VS Code

  • Für VS-Code-Nutzer wird in .vscode/tasks.json ein Task mit runOn: folderOpen eingetragen
  • Dadurch wird bei jedem Öffnen des Projektordners node .claude/setup.mjs ausgeführt

• Dropper setup.mjs

  • Beide Hooks rufen setup.mjs auf, einen in sich geschlossenen Bootstrapper für die Bun-Runtime
  • Wenn Bun nicht installiert ist, wird bun-v1.3.13 unauffällig aus den GitHub-Releases heruntergeladen
  • Unterstützt werden Linux x64, Linux arm64, Linux musl, macOS x64, macOS arm64, Windows x64 und Windows arm64
  • Anschließend wird die vollständige 14,8-MB-Payload .claude/router_runtime.js ausgeführt und in /tmp wieder aufgeräumt

• Bösartiger GitHub-Actions-Workflow

  • Verfügt die Malware über ein GitHub-Token mit Schreibrechten, pusht sie einen Workflow namens Formatter in das Repository des Opfers
  • Bei jedem Push werden über ${{ toJSON(secrets) }} sämtliche Repository-Geheimnisse ausgegeben
  • Die Ergebnisse werden als herunterladbares Actions-Artefakt mit dem Namen format-results hochgeladen
  • Die Actions sind auf eine bestimmte Commit-SHA gepinnt, damit sie legitim wirken
  • Repositories, die in CI das infizierte Paket lightning bezogen haben und über ein Token mit Schreibrechten verfügen, sollten diese Dateien prüfen

Kompromittierungsindikatoren

• Suchbare Indikatoren

  • Commit-Nachrichten mit dem Präfix EveryBoiWeBuildIsAWormyBoi dienen als Träger für Dead-Drop-Token und können über die GitHub-Commit-Suche gefunden werden
  • GitHub-Repositories mit der Beschreibung "A Mini Shai-Hulud has Appeared" sind Angreifer-Repositories für den Datenabfluss und direkt durchsuchbar

• Pakete

  • lightning@2.6.2
  • lightning@2.6.3

• Dateien und Systemartefakte

  • _runtime/start.py: Python-Loader, der die Payload beim Import initialisiert
  • _runtime/router_runtime.js: verschleierte JavaScript-Payload und 14,8-MB-Bun-Runtime
  • _runtime/: Verzeichnis, das den bösartigen Paketversionen hinzugefügt wurde
  • .claude/router_runtime.js: in Opfer-Repositories injizierte Kopie der Malware
  • .claude/settings.json: in Opfer-Repositories injizierte Hook-Konfiguration für Claude Code
  • .claude/setup.mjs: in Opfer-Repositories injizierter Dropper
  • .vscode/tasks.json: in Opfer-Repositories injizierter automatisch ausgeführter VS-Code-Task
  • .vscode/setup.mjs: in Opfer-Repositories injizierter Dropper