Veröffentlicht am 17.07.2026
Am 14. Juli 2026 wurden vier weit verbreitete npm-Pakete des AsyncAPI-Projekts mit einer Schadsoftware versehen – nicht durch einen gestohlenen Login und nicht durch einen unehrlichen Entwickler, sondern durch einen gekaperten Bauautomatismus (die sogenannte CI/CD-Pipeline, also die automatisierte Kette, die aus Quellcode fertige Software-Pakete erzeugt und veröffentlicht). Das perfide Ergebnis: Die vergifteten Pakete trugen gültige, echte Herkunftsnachweise und wurden über den offiziellen Veröffentlichungsweg publiziert. Für herkömmliche Sicherheitsscanner sahen sie legitim aus. Zusammen kamen die betroffenen Pakete auf rund 2,9 Millionen Downloads pro Woche.
Wenn Sie in Ihrem Unternehmen Node.js und npm einsetzen – für Ihre Website, für API-Dokumentation, für Code-Generierung oder in Ihrer Entwicklungs- und Build-Umgebung – sollten Sie diesen Artikel bis zum Ende lesen. Weiter unten finden Sie konkrete Befehle, mit denen Sie in wenigen Minuten prüfen können, ob Sie betroffen sind.
Ein Angreifer verschaffte sich Schreibzugriff auf zwei GitHub-Repositories des AsyncAPI-Projekts und schmuggelte darüber Schadcode in vier npm-Pakete ein:
Der eingeschleuste Code lud eine Schadsoftware namens Miasma RAT nach – ein „RAT“ ist ein Remote Access Trojaner, also ein Programm, das Angreifern die Fernsteuerung eines Systems erlaubt. Diese Malware stiehlt Zugangsdaten: gespeicherte Browser-Passwörter, SSH-Schlüssel, npm- und GitHub-Tokens sowie Cloud-Zugangsdaten von AWS, Google Cloud und Azure – und darüber hinaus auch Krypto-Wallets.
Das Angriffsfenster war kurz, aber real: Die drei Generator-Pakete waren rund 4 Stunden und 7 Minuten verfügbar (07:10 bis 11:18 UTC), das besonders stark genutzte @asyncapi/specs etwa 2 Stunden und 48 Minuten. Bis 11:18 UTC am selben Tag waren alle fünf bösartigen Versionen aus dem npm-Registry entfernt. Das Problem: Wer in diesem Zeitfenster installiert oder das betroffene Modul geladen hat, ist weiterhin gefährdet.
Der Angriff verlief in mehreren Stufen und ist ein Musterbeispiel dafür, wie professionell moderne Lieferketten-Angriffe (Supply-Chain-Angriffe) inzwischen ablaufen.
Im Kern stand eine seit Monaten bekannte Fehlkonfiguration in einem GitHub-Actions-Workflow. GitHub Actions ist die Automatisierung, die auf GitHub Code testet und veröffentlicht. Der betroffene Workflow nutzte einen Auslöser (pull_request_target), der Code aus einem fremden, nicht vertrauenswürdigen Änderungsvorschlag ausführte – und dabei vollen Zugriff auf die geheimen Zugangsschlüssel des Projekts hatte. Dieses gefährliche Muster ist als „Pwn Request“ bekannt.
Besonders bitter: Diese Schwachstelle war nicht neu. Die Sicherheitsforscherin Florence Njeri hatte sie bereits am 29. April 2026 gemeldet, ein Korrektur-Vorschlag existierte seit dem 17. Mai. Er blieb jedoch 58 Tage lang ungemergt – also unbestätigt und nicht eingespielt. Wiz Research bringt es auf den Punkt:
„Leider war das Potenzial für diese Schwachstelle bereits Monate vor dem Angriff erkannt worden.“ – Wiz Research
Um 05:08 UTC öffnete der Angreifer 37 Änderungsvorschläge (Pull Requests) auf einmal – ein Ablenkungsmanöver. Nur einer davon enthielt die eigentliche Schadlast: verschleierten JavaScript-Code, der den Zugangstoken des Projekt-Bots („asyncapi-bot“) an einen anonymen Ablageort im Netz weiterleitete. Mit diesem gestohlenen Token konnte der Angreifer anschließend selbst Code ins Projekt schreiben.
Und hier liegt das eigentlich Beunruhigende: Der Angreifer ließ die legitime Veröffentlichungspipeline die Arbeit machen. Die daraus entstandenen Pakete trugen gültige sogenannte SLSA-Provenance-Attestierungen – digitale Herkunftsnachweise, die beweisen, dass der autorisierte Workflow die Pakete erzeugt hat. Rohan Prabhu von StepSecurity, der Primärquelle dieses Vorfalls, erklärt das Kernproblem:
„Die resultierenden Pakete tragen legitime SLSA-Provenance-Attestierungen, die nur beweisen, dass der autorisierte Workflow des Projekts sie erzeugt hat – nicht, dass die auslösenden Commits legitim waren. Provenance schützt nicht gegen kompromittierte Push-Zugangsdaten.“ – Rohan Prabhu, StepSecurity
Viele Entwickler verlassen sich auf die Schutzmaßnahme npm install --ignore-scripts, die verhindert, dass Pakete bei der Installation automatisch Skripte ausführen. Bei diesem Angriff ist diese Maßnahme wirkungslos. Der Schadcode feuert nämlich nicht bei der Installation, sondern erst, wenn das betroffene Modul im Programm tatsächlich geladen (require() bzw. import) wird. Das Socket Research Team formuliert es klar:
„Das ist kein Install-Hook-Angriff. Der Schadcode braucht kein preinstall, postinstall oder irgendein Lifecycle-Skript. Er läuft, wenn das infizierte Modul von Node.js geladen wird.“ – Socket Research Team
Zusätzlich war der Schadcode hinter rund 880 führenden Leerzeichen versteckt – in einem Code-Editor also weit rechts außerhalb des sichtbaren Bereichs.
Wird ein vergiftetes Modul geladen, startet ein versteckter Hintergrundprozess, der die eigentliche Malware von IPFS (einem dezentralen Datei-Netzwerk) herunterlädt und als Datei sync.js in einem versteckten Verzeichnis ablegt. Der Miasma RAT ist ein hochentwickeltes, modular aufgebautes Framework mit 744 Modulen und sechs voneinander unabhängigen Kommunikationskanälen zu den Angreifern – unter anderem klassisches HTTP, aber auch ein Ethereum-Smart-Contract und das BitTorrent-Netzwerk.
Er sammelt Zugangsdaten, richtet Persistenz ein (er überlebt Neustarts über systemd, crontab, macOS launchd oder die Windows-Registry) und kann Befehle ausführen. Weitere Fähigkeiten wie Wurm-Verbreitung und das Vergiften von KI-Coding-Werkzeugen waren im Code enthalten, in dieser Version aber deaktiviert – ein Warnsignal für künftige Kampagnen. Microsoft Defender erkennt die Artefakte inzwischen als Trojan:JS/MiasmStealer.SC und Trojan:Script/Supychain.A.
Betroffen sind Unternehmen, die Node.js/npm in ihrer Entwicklungs- oder Build-Umgebung einsetzen und eine der bösartigen Versionen im Angriffsfenster installiert oder geladen haben. Wichtig ist der Blick auf transitive Abhängigkeiten – also Pakete, die indirekt über andere Pakete hereingezogen werden: @asyncapi/specs (allein rund 2,66 Millionen Downloads pro Woche) wird über das Paket @asyncapi/parser (970.000 Downloads/Woche) automatisch mitgezogen. Sie können also betroffen sein, ohne @asyncapi/specs jemals direkt installiert zu haben.
Besonders erhöht ist das Risiko, wenn Ihre CI/CD-Pipeline Zugriff auf Produktionssysteme, Datenbanken oder Cloud-Zugangsdaten hat.
package-lock.json, yarn.lock oder pnpm-lock.yaml und suchen Sie nach den betroffenen Versionen. Befehl:grep -E '@asyncapi/(generator@3\.3\.1|generator-helpers@1\.1\.1|generator-components@0\.7\.1|specs@6\.11\.2)' package-lock.jsonnpm list @asyncapi/generator @asyncapi/generator-helpers @asyncapi/generator-components @asyncapi/specs 2>/dev/null | grep -E '3\.3\.1|1\.1\.1|0\.7\.1|6\.11\.2'ls -la ~/.local/share/NodeJS/sync.js · macOS: ls -la ~/Library/Application\ Support/NodeJS/sync.js · Windows: dir %LOCALAPPDATA%\NodeJS\sync.jsps aux | grep -i 'NodeJS' · Windows: tasklist | findstr nodesystemctl --user list-units | grep miasma · macOS: grep -r 'miasma' ~/.zshrc ~/.bashrc ~/.bash_profile 2>/dev/null · Windows: reg query HKCU\Software\Microsoft\Windows\CurrentVersion\Run /v miasma-monitornetstat -an | grep 85.137.53.71 (Ports 8080, 8081, 8091)ipfs.io, 85.137.53.71, BitTorrent-DHT-Nodes oder Nostr-Relays.npm list @asyncapi/specsWaren Sie im Angriffsfenster betroffen, handeln Sie in dieser Reihenfolge:
rm package-lock.json && npm install. Die bösartigen Versionen sind entfernt und werden nicht mehr aufgelöst.npm install @asyncapi/generator@3.3.0 @asyncapi/generator-helpers@1.1.0 @asyncapi/generator-components@1.0.0 @asyncapi/specs@6.11.1. Für transitive Abhängigkeiten in die package.json ergänzen: "overrides": { "@asyncapi/specs": "6.11.1" }sync.js am jeweiligen Pfad und beenden Sie verwaiste Node.js-Prozesse aus dem NodeJS-Verzeichnis.systemctl --user disable --now miasma-monitor.service && rm ~/.config/systemd/user/miasma-monitor.service · macOS: nohup-Blöcke aus den Shell-Profildateien löschen · Windows: reg delete HKCU\Software\Microsoft\Windows\CurrentVersion\Run /v miasma-monitor /f85.137.53.71 (Ports 8080, 8081, 8091).pull_request_target-Workflows auf unsichere Checkout-Praktiken.Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat zu Supply-Chain-Angriffen über Paketmanager gewarnt und rät ausdrücklich, nicht nur die Kompromittierung zu verhindern, sondern auch die Auswirkungen eines erfolgreichen Angriffs zu begrenzen.
Aus Datenschutzsicht ist der Vorfall besonders relevant: Wurden auf einem betroffenen System personenbezogene Daten verarbeitet, oder ermöglichten gestohlene Zugangsdaten Zugriff auf Systeme mit personenbezogenen Daten, liegt eine Datenschutzverletzung im Sinne von Art. 4 Nr. 12 DSGVO vor. Dann gilt:
Wichtig zu wissen: Die DSGVO unterscheidet nicht zwischen direkten und indirekten Angriffen. Auch wenn die Kompromittierung über eine Drittanbieter-Bibliothek erfolgte, bleiben Sie als Verantwortlicher für den Schutz der von Ihnen verarbeiteten personenbezogenen Daten zuständig.
Dieser Vorfall ist ein Weckruf – gerade weil hier fast alles „richtig“ aussah: legitimer Namensraum, echte Herkunftsnachweise, keine CVE-Nummer, kein Install-Hook. Genau das macht den Angriff so gefährlich und erklärt, warum viele klassische Schutzmechanismen versagten. Unit 42 von Palo Alto Networks ordnet den Trend so ein: Seit dem „Shai-Hulud“-Wendepunkt hätten Angriffe sich „von einzelnen Typosquatting-Vorfällen zu systematischen Kampagnen entwickelt, die das Vertrauen ausnutzen, auf dem moderne Softwareentwicklung basiert“.
Für KMU heißt das konkret: Prüfen Sie jetzt mit den oben genannten Befehlen, ob Sie betroffen sind. Falls ja, rotieren Sie sofort alle Zugangsdaten und arbeiten Sie die Maßnahmenliste ab. Und unabhängig davon, ob Sie diesmal betroffen waren: Härten Sie Ihre CI/CD-Pipeline, aktivieren Sie Branch-Protection und führen Sie Egress-Filterung ein. Die 58 Tage, die eine bekannte Schwachstelle hier offen blieb, sind die eigentliche Lehre – Bekanntes ungepatcht liegen zu lassen, ist im Jahr 2026 ein kalkulierbares und daher vermeidbares Risiko.