jscrambler-npm-Paket kompromittiert: plattformübergreifender Rust-Infostealer in Version 8.14.0–8.20.0

TL;DR — 90 Sekunden

Betroffen?

jscrambler 8.14.0/8.16.0/8.17.0/8.18.0/8.20.0 sowie jscrambler-webpack-plugin 8.6.2, gulp-jscrambler 8.6.2, grunt-jscrambler 8.5.2, jscrambler-metro-plugin 9.0.2. Sichere Versionen: 8.22.0 bzw. 8.6.3/8.6.3/8.5.3/9.0.3.

Risiko?

Plattformübergreifender Rust-Infostealer: Cloud-Keys (AWS Secrets Manager, GCP-Metadata, Azure IMDS), Krypto-Wallets (MetaMask, Phantom, Exodus), KI-Tool-Configs (Claude Desktop, Cursor-MCP-Server), Browser-/Discord-/Slack-Sessions, Kubernetes-API-Zugänge. Persistenz via Windows-Scheduled-Tasks/macOS-LaunchAgents; auf Linux werden eBPF-Programme direkt in den Kernel geladen.

Sofortmaßnahme?

Betroffene Version(en) sofort entfernen, auf 8.22.0 (bzw. die jeweilige sichere Version) aktualisieren, alle in CI/Dev-Umgebungen erreichbaren Credentials rotieren.

Empfehlung?

Auch wenn nur ~1.479 Downloads über alle bösartigen Versionen gemeldet sind: Wer jscrambler in CI/CD einsetzt, sollte Installationslogs auf dist/setup.js-Ausführung prüfen, unabhängig von der exakten installierten Version.

Kritikalität?

hoch (Hero-Badge) — Kernel-Level-Zugriff unter Linux via eBPF, breite Credential-Abdeckung.

Was ist passiert?

Der Vorfall begann mit einem kompromittierten npm-Publish-Credential, über das ein Angreifer die Version 8.14.0 von jscrambler veröffentlichen konnte — ohne passende Commits im öffentlichen Repository. Socket entdeckte die kompromittierte Version rund sechs Minuten nach Veröffentlichung. Jscrambler selbst erkannte den Vorfall „innerhalb von Sekunden“ über automatische Benachrichtigungen an Paket-Maintainer und deprecatete die Version umgehend.

Der Angreifer blieb aktiv: Am selben Tag folgten 8.16.0 und 8.17.0 (weiterhin über einen preinstall-Hook ausgeliefert), dann 8.18.0 und 8.20.0 — hier verschwindet der Install-Hook komplett, stattdessen wird derselbe Dropper als selbstausführende Funktion beim Modul-Import injiziert, um Scanner zu umgehen, die ausschliesslich Install-Skripte prüfen. Die Payload besteht aus plattformspezifischen Binaries für Linux, macOS und Windows, eingebettet in einem obfuskierten Container (dist/intro.js, laut Analyse rund 7,8 MB), geladen über einen kleinen Loader (dist/setup.js).

Betroffen sind neben dem Hauptpaket vier abhängige Pakete: jscrambler-webpack-plugin 8.6.2, gulp-jscrambler 8.6.2, grunt-jscrambler 8.5.2 und jscrambler-metro-plugin 9.0.2.

Wer ist betroffen?

Laut Jscrambler-Advisory liegen die Gesamt-Downloads über alle bösartigen Versionen bei rund 1.479 — die tatsächliche Kompromittierungsrate (wie viele Installationen die Payload tatsächlich ausgeführt haben) ist damit nicht beziffert. Primär betroffen sind Entwicklungsumgebungen und CI/CD-Systeme mit Zugriff auf Deployment-Token und Quellcode.

Auswirkungen

Der Infostealer zielt breit: Cloud-Zugangsdaten (AWS, Azure, GCP), Krypto-Wallets (MetaMask, Phantom, Exodus), Passwort-Manager, Browser-Sessions sowie — bemerkenswert — Konfigurationen von KI-Tools wie Claude Desktop und Cursor-MCP-Servern. Für CI/CD-Umgebungen besonders relevant: Kubernetes-API-Zugriff wird ebenfalls erfasst. Persistenz erfolgt plattformabhängig über Windows-Scheduled-Tasks bzw. macOS-LaunchAgents, inklusive Anti-Debugging-Prüfungen. Unter Linux lädt die Malware eBPF-Programme direkt in den Kernel — ein deutlich tieferer Zugriffsgrad als klassische Userspace-Stealer. Die Exfiltration läuft laut Socket-Analyse über TLS (rustls-Bibliothek) mit Multipart-Form-Uploads; konkrete C2-Domains/IPs sind in den öffentlichen Analysen nicht disclosed.

Für Teams, die jscrambler zum Schutz eigener Production-Bundles einsetzen, liegt die Ironie auf der Hand: ein Sicherheits-Tool wurde selbst zum Einfallstor.

Mitigation / Sofortmassnahmen

Hinweis: Basierend auf dem offiziellen Jscrambler-Advisory und der Socket-Analyse — konkrete Versionsstände gegen die Originalquellen abgleichen.

Operativer Entscheidungsblock

• Jetzt handeln, wenn … eine der betroffenen Versionen (siehe Tabelle) in package.json/Lockfile auftaucht — auch transitiv.
• Mit Priorität prüfen, wenn … Sie jscrambler oder verwandte Pakete überhaupt einsetzen, unabhängig von der aktuell gepinnten Version.
• Nur beobachten, wenn … Sie keines der genannten Pakete referenzieren.

Schritt 1 — betroffene Version entfernen und aktualisieren

# Lockfile / package.json auf betroffene Versionen prüfen
grep -E "jscrambler|gulp-jscrambler|grunt-jscrambler" package-lock.json yarn.lock pnpm-lock.yaml 2>/dev/null
# hart auf die sichere Version pinnen
npm install jscrambler@8.22.0 --save-exact
npm install jscrambler-webpack-plugin@8.6.3 gulp-jscrambler@8.6.3 grunt-jscrambler@8.5.3 jscrambler-metro-plugin@9.0.3 --save-exact 2>/dev/null

Schritt 2 — Installationslogs und CI-Historie prüfen

# CI-Build-Logs auf Ausführung von dist/setup.js durchsuchen
grep -RIn "dist/setup.js\|dist/intro.js" ci-logs/ 2>/dev/null
# Node-Modules-Cache auf betroffene Versionen prüfen
find . -path "*/node_modules/jscrambler/package.json" -exec grep -H '"version"' {} \;

Schritt 3 — Credentials rotieren

- AWS/Azure/GCP-Keys aller CI-Runner, die das Paket installiert haben
- npm-/Registry-Publish-Token
- Deployment- und Repository-Tokens
- Browser-/Discord-/Slack-Sessions auf betroffenen Entwickler-Maschinen

Schritt 4 — Install-Skripte grundsätzlich einschränken

# CI: keine Install-Skripte automatisch ausführen
npm ci --ignore-scripts
# und danach gezielt genehmigen, was wirklich gebraucht wird
npm approve-scripts

Detection / Prüfung

Version & Lockfile prüfen

npm ls jscrambler jscrambler-webpack-plugin gulp-jscrambler grunt-jscrambler jscrambler-metro-plugin 2>/dev/null

Auf Ausführungsspuren prüfen

# wurden setup.js/intro.js jemals ausgeführt? CI-Logs und Shell-History prüfen
grep -RIn "dist/setup.js\|dist/intro.js" . 2>/dev/null
# ungewöhnliche geplante Tasks (Windows) bzw. LaunchAgents (macOS) auf Build-Maschinen
schtasks /query /fo LIST /v 2>nul | findstr /i "jscrambler"
ls ~/Library/LaunchAgents/ 2>/dev/null | grep -i jscrambler

Laufzeit-Indikatoren

- unerwarteter ausgehender TLS-Traffic von Build-/CI-Runnern kurz nach npm install
- neue eBPF-Programme auf Linux-Build-Hosts (bpftool prog list)
- unbekannte AWS-/GCP-/Azure-API-Aufrufe kurz nach CI-Läufen mit betroffenem Paket

Betreiberempfehlung

Mid-Market

Prüfen Sie Lockfiles auf die betroffenen Versionen, aktualisieren Sie auf 8.22.0 (bzw. die jeweils sichere Version) und rotieren Sie vorsorglich Zugangsdaten aus CI-Umgebungen, die das Paket je installiert haben — selbst wenn kein Kompromittierungsnachweis vorliegt.

Enterprise

SBOM-/Dependency-Scan über alle Repositories nach den fünf betroffenen Paketen, inklusive transitiver Abhängigkeiten. Besonders relevant: Der Angriff funktioniert ab Version 8.18.0 ohne Install-Hook — Scanner, die ausschliesslich preinstall/postinstall-Skripte prüfen, übersehen diese Varianten. Statische Analyse auf Modul-Import-Ebene ergänzen.

CI/CD

Standardmässig --ignore-scripts in CI-Pipelines, explizite Allowlist über npm approve-scripts für tatsächlich benötigte Install-Skripte, und ein Blick auf ausgehenden Netzwerk-Traffic von Build-Runnern (Egress-Filtering hätte die TLS-Exfiltration zumindest erschwert).

Fazit

Der jscrambler-Vorfall zeigt zwei Dinge gleichzeitig: Wie schnell Angreifer nach einem kompromittierten Publish-Credential iterieren (fünf bösartige Versionen an einem Tag), und wie gezielt neuere npm-Supply-Chain-Malware inzwischen Scanner umgeht, die nur auf Install-Skripte schauen. Dass ausgerechnet ein Sicherheits-Tool betroffen war, unterstreicht: Vertrauen in eine Paket-Kategorie ist kein Ersatz für Versions-Pinning, Lockfile-Audits und Egress-Kontrolle in CI.

Quellen

• Jscrambler — offizielles Security Advisory: Unauthorized Publication of a Malicious npm Package (11.07.2026)
• The Hacker News — Compromised jscrambler 8.14.0 npm Release Drops Rust Infostealer During Install
• Socket — jscrambler Supply Chain Attack (technische Analyse, Erkennung binnen 6 Minuten)