Veröffentlicht am 07.07.2026
Sechs npm-Pakete, die aussahen wie harmlose Hilfswerkzeuge für den weit verbreiteten JavaScript-Bundler Rollup, entpuppten sich als vollständige Fernsteuerungs-Werkzeuge nordkoreanischer Hacker. Wer eines dieser Pakete zwischen Anfang Mai und Anfang Juli 2026 in ein Projekt einbaute, gab Angreifern potenziell die komplette Kontrolle über seine Entwickler-Maschine – inklusive AWS-Zugangsschlüsseln, SSH-Schlüsseln, gespeicherten Browser-Passwörtern und Krypto-Wallets. Die Sicherheitsforscher von JFrog haben die Kampagne am 30. Juni 2026 aufgedeckt und der berüchtigten Lazarus-Gruppe zugeschrieben, einem staatlich gesteuerten Angreiferteam aus Nordkorea.
Alle sechs Pakete wurden inzwischen aus dem npm-Registry (dem zentralen Paketverzeichnis für JavaScript-Software) entfernt. Doch das Problem ist damit nicht gelöst: Jeder, der die Pakete im Zeitfenster zwischen Veröffentlichung und Entfernung installiert hat, war bereits kompromittiert. In diesem Artikel erklären wir, was genau passiert ist, wer betroffen sein könnte, wie Sie das prüfen und was Sie jetzt konkret tun müssen.
JFrog Security Research entdeckte sechs bösartige npm-Pakete, die sich als legitime „Polyfill“-Werkzeuge für Rollup tarnten. Ein Polyfill ist ein Stück Code, das ältere Umgebungen mit neueren Funktionen nachrüstet – etwas völlig Alltägliches in der Webentwicklung. Die Angreifer imitierten dabei gezielt das echte und sehr populäre Paket rollup-plugin-polyfill-node, das rund 295.000 Downloads pro Woche und über 1,2 Millionen Downloads im letzten Monat verzeichnet.
Die Fälschungen kopierten die README-Beschreibung, die Repository-Metadaten und die Paketstruktur des Originals nahezu identisch. Bei einer schnellen Durchsicht der Abhängigkeiten fiel damit kaum etwas auf. Die sechs Pakete verteilten sich auf drei Angriffspfade:
JFrog-Forscher Yair Benamou fasst die Tarnung so zusammen:
„Die Lookalike-Pakete platzieren sich im gleichen Namensraum aus rollup, polyfill, core und node, was bei einer schnellen Abhängigkeitsprüfung plausibel aussehen kann. Die Payload ist zudem umfangreicher als ein simpler Downloader. Sobald die späteren Stufen laufen, erlangt der Angreifer sowohl Sammel- als auch Kontrollfähigkeiten.“
Der Angriff läuft in mehreren Stufen ab. Das Besondere und Gefährliche daran: Die Schadlogik wird nicht beim Installieren des Pakets ausgeführt (dem klassischen npm install), sondern erst beim Import – also wenn ein Entwickler oder eine automatisierte Build-Pipeline das Paket mit require() tatsächlich verwendet.
Das ist kein Zufall. Seit npm v12 (Juli 2026) werden sogenannte postinstall-Skripte – automatisch beim Installieren ausgeführter Code – standardmäßig blockiert. Diese neue Schutzmaßnahme läuft bei diesem Angriff ins Leere, weil der Schadcode eben nicht beim Installieren, sondern beim Verwenden zuschlägt. Sicherheitsanalyst Clayton Lewis von TechTimes bringt es auf den Punkt:
„Der Rollup-Polyfill-Angriff wird durch [npm v12s Skript-Blockade] nicht gestoppt. Der Schadcode läuft nicht während npm install. Er läuft, wenn ein Entwickler oder ein CI-Job das Paket per require() als Teil eines Builds oder einer Konfigurationsdatei einbindet. Das ist Import-Time-Ausführung, keine Install-Time-Ausführung – eine andere Angriffsfläche, die die Skript-Blockade von npm v12 nicht abdeckt.“
Um Sicherheits-Scanner auszutricksen, war nur der CommonJS-Einstiegspunkt (die Datei dist/index.js) mit einer Hintertür versehen – die alternative ESM-Variante blieb sauber. Der Nachlade-Befehl für die zweite Schadstufe war zudem Base64-kodiert hinter einem harmlos klingenden SVG-Prüfnamen versteckt. Dekodiert lautete er: npm install swift-parse-stream --no-save --silent --no-audit --no-fund. Das Flag --no-save sorgt dafür, dass das nachgeladene Schadpaket nicht in der package.json oder package-lock.json auftaucht – es bleibt also unsichtbar in den Projektdateien.
Die zweite Stufe holt sich von einem externen Dienst (jsonkeeper.com) ein Datenobjekt und führt dessen Inhalt direkt aus. Zuvor prüft das Skript jedoch über mehr als 15 Umgebungsvariablen (etwa CODESPACE_NAME, VERCEL, AWS_REGION oder DOCKER), ob es in einer Sandbox, einer Cloud-Entwicklungsumgebung oder einer Analyse-Infrastruktur läuft. Wird eine solche Umgebung erkannt, beendet sich der Schadcode selbst – so entgeht er automatisierten Untersuchungen. Nur auf einer echten Entwickler-Workstation lädt er den eigentlichen, rund 114 KB großen und AES-256-verschlüsselten Schadcode vom Kommando-Server (Command-and-Control, kurz C2) mit der IP-Adresse 216.126.236.244 herunter.
Der entschlüsselte Payload besteht aus vier Komponenten:
.env, .pem, .key, SSH-Schlüsseln, Krypto-Wallet-Phrasen sowie Konfigurationen für AWS, Azure, Google, Anthropic Claude und Foundry (Upload an Port 4806).JFrog weist darauf hin, warum gerade Build-Werkzeuge ein so attraktives Ziel sind:
„Rollup-Plugins werden häufig aus lokalen Konfigurationsdateien, Entwickler-Workstations und CI-Jobs geladen. Diese Umgebungen haben oft Zugriff auf sensible Werte wie Quellcode, npm-Tokens, Git-Zugangsdaten, Cloud-Schlüssel, SSH-Schlüssel, Browserdaten und Projektgeheimnisse.“
Für ein deutsches KMU, das lediglich eine Website betreibt, aber keine eigene JavaScript-Entwicklung macht, ist das direkte Risiko begrenzt. Kritisch wird es jedoch in diesen Konstellationen:
Diese Kampagne ist kein Einzelfall. Der Dienst Socket.dev verfolgt die zugrundeliegende „Contagious Interview“-Kampagne seit 2024 und hat über 1.700 bösartige Pakete dokumentiert. Sicherheitsforscher Kirill Boychenko von Socket.dev beschreibt das Vorgehen als „gut ausgestattete, produktive und systematische Fabrik-Modell-Bedrohung, die npm, PyPI und VS Code als erneuerbare Zugangskanäle in Entwicklerumgebungen behandelt“.
npm list rollup-packages-polyfill-core rollup-runtime-polyfill-core swift-parse-stream quirky-token react-icon-svgs rollup-plugin-polyfill-connect. Erscheint eines der Pakete, ist das Projekt betroffen.npm ls --all 2>/dev/null | grep -E "rollup-packages-polyfill-core|rollup-runtime-polyfill-core|swift-parse-stream|quirky-token|react-icon-svgs|rollup-plugin-polyfill-connect"./tmp unter Linux/macOS, %TEMP% unter Windows) auf die Dateien pack, scdata, ldata und events.json.ps aux | grep -E "scdata|ldata" (Linux/macOS) bzw. Get-Process | Where-Object {$_.CommandLine -match "scdata|ldata"} (Windows PowerShell).~/.npm/_logs/.ls -la ~/.aws/credentials ~/.ssh/id_rsa – unerwartete Zugriffszeiten sind ein Warnsignal.Sicherheitsforscherin Rebecca Sutton von Aardwolf Security warnt eindringlich davor, sich auf die Entfernung der Pakete zu verlassen: „Alle sechs Pakete wurden inzwischen aus dem Registry entfernt. Das schließt aber nur die Tür im Nachhinein. Wer sie zwischen Veröffentlichung und Entfernung installiert hat, war für dieses gesamte Zeitfenster exponiert. Die Entfernung aus npm macht einen bereits erfolgten Diebstahl nicht ungeschehen.“
npm uninstall rollup-packages-polyfill-core rollup-runtime-polyfill-core swift-parse-stream quirky-token react-icon-svgs rollup-plugin-polyfill-connect, danach npm install für saubere Abhängigkeiten. Als legitimen Ersatz verwenden Sie das echte Paket rollup-plugin-polyfill-node.npm token revoke), GitHub-/GitLab-Tokens, Cloud- und KI-API-Keys (Azure, Google Cloud, Anthropic Claude, AWS Bedrock), im Browser gespeicherte Passwörter sowie Krypto-Wallet-Seed-Phrasen (neue Wallets anlegen, Guthaben transferieren).pack, scdata, ldata, vhost.ctl suchen und entfernen; laufende Node.js-Prozesse dieser Komponenten beenden.ignore-scripts=true in der .npmrc setzen und Lockfiles auf Integrität prüfen.Wurde eine Entwickler-Workstation oder ein CI/CD-System kompromittiert, auf dem personenbezogene Daten oder Zugangsdaten zu Systemen mit Kundendaten zugänglich waren, liegt gemäß Art. 4 Nr. 12 DSGVO eine Verletzung des Schutzes personenbezogener Daten vor. Dann greift Art. 33 DSGVO: Sie müssen die Datenpanne unverzüglich, möglichst binnen 72 Stunden nach Bekanntwerden, der zuständigen Datenschutzaufsichtsbehörde melden (je nach Bundesland etwa dem BayLDA, der LfDI Baden-Württemberg oder dem BfDI).
Besteht ein hohes Risiko für die Rechte und Freiheiten betroffener Personen, sind nach Art. 34 DSGVO auch die Betroffenen selbst zu benachrichtigen. Als besonders kritisch gilt der Diebstahl von AWS-Keys oder Datenbankpasswörtern, die Zugang zu Kundendaten ermöglichen. Dass unzureichende technische Schutzmaßnahmen (Art. 32 DSGVO) teuer werden können, zeigen Beispiele wie das Bußgeld von 40.000 Euro der LfDI Baden-Württemberg (2019) oder die 1,5 Millionen Euro der französischen CNIL gegen Dedalus Biology (2022). Dokumentieren Sie den Vorfall daher gemäß Art. 33 Abs. 5 DSGVO und ziehen Sie im Zweifel Ihren Datenschutzbeauftragten hinzu.
Dieser Angriff zeigt, wie professionell und geduldig staatlich gestützte Angreifer inzwischen vorgehen: kopierte README-Dateien, plausible Metadaten, funktionsfähig aussehender Code – und eine ausgeklügelte Ausführung erst beim Import, die sogar die neuesten npm-Schutzmaßnahmen umgeht. JFrog mahnt daher zu Recht: „Lookalike-Build-Abhängigkeiten verdienen sorgfältige Prüfung, auch wenn der Name kein offensichtlicher Tippfehler ist. Ein kopiertes README, ein vertrauenswürdiger Repository-Link und funktional aussehender Paketcode können ausreichen, um eine ernsthafte Kompromittierung zu verbergen.“
Für KMU heißt das konkret: Fragen Sie Ihre Webagentur oder Ihre Entwickler proaktiv, ob eines der sechs Pakete im Einsatz war. Prüfen Sie Ihre Projekte anhand der obigen Schritte. Und behandeln Sie im Zweifel jeden betroffenen Rechner als kompromittiert – denn die Entfernung der Pakete aus dem Registry schützt nur vor künftigen, nicht vor bereits erfolgten Infektionen. Wer schnell handelt und seine Zugangsdaten rotiert, begrenzt den Schaden erheblich.