Veröffentlicht am 14.07.2026
Am Morgen des 14. Juli 2026 genügten wenige Stunden, um Millionen von Systemen weltweit einem aktiven Fernzugriffs-Trojaner auszusetzen. Zwischen 07:10 und 11:18 Uhr UTC – also etwas mehr als vier Stunden – lieferten vier weit verbreitete npm-Pakete aus dem @asyncapi-Umfeld einen mehrstufigen Botnet-Loader der Malware-Familie „Miasma" aus. Betroffen war unter anderem das Paket @asyncapi/specs, das allein rund 2,7 Millionen Downloads pro Woche verzeichnet. Kombiniert kommen die vier kompromittierten Pakete auf etwa 2,9 Millionen wöchentliche Downloads.
Das Besonders Perfide daran: Der Schadcode war nicht in einem Installationsskript versteckt, sondern direkt in ganz normalen Quelldateien der Pakete. Er wurde nicht bei der Installation ausgeführt, sondern beim ersten Laden des Moduls im Programm. Standard-Schutzmaßnahmen wie das Deaktivieren von Installationsskripten greifen hier nicht.
AsyncAPI ist ein offener Standard zur Beschreibung sogenannter Event-Driven APIs – also Schnittstellen, über die Software-Systeme in Echtzeit Nachrichten austauschen. Die zugehörigen npm-Pakete (npm ist der zentrale Paketmanager für die Programmiersprache JavaScript/Node.js) werden vor allem in der Backend-Entwicklung, in der API-Dokumentation und in automatisierten Build-Prozessen eingesetzt.
Am 14. Juli 2026 gelang es einem Angreifer, gleich vier Pakete zu kompromittieren:
@asyncapi/generator@3.3.1 (ca. 126.000 wöchentliche Downloads)@asyncapi/generator-helpers@1.1.1 (ca. 45.000)@asyncapi/generator-components@0.7.1 (ca. 46.000)@asyncapi/specs@6.11.2 und @asyncapi/specs@6.11.2-alpha.1 (ca. 2,7 Mio.)Der Angriff erfolgte nicht über einen gestohlenen npm-Zugangstoken im klassischen Sinne oder einen bösartigen Maintainer, sondern über die Kompromittierung der CI/CD-Pipeline – also der automatisierten Bau- und Veröffentlichungsprozesse der Projekte. Rohan Prabhu von StepSecurity fasst es so zusammen:
„Beide Angriffe sind CI/CD-Pipeline-Kompromittierungen, keine gestohlenen npm-Token oder bösartigen Maintainer. Der Angreifer schob Commits unter einer Platzhalter-Git-Identität und ließ den echten Release-Workflow jedes Repositories die Veröffentlichung über npms GitHub-OIDC-Integration erledigen. Die resultierenden Pakete tragen legitime SLSA-Provenance-Attestierungen – die aber nur beweisen, dass der autorisierte Workflow sie erzeugt hat, nicht dass die auslösenden Commits legitim waren."
Der Angriff nutzte eine bekannte GitHub-Actions-Schwachstelle, den sogenannten „pwn request". Vereinfacht gesagt: Ein Automatisierungs-Workflow im GitHub-Projekt lief mit Zugriff auf geheime Zugangsdaten (Secrets), führte aber gleichzeitig Code aus, den ein beliebiger Außenstehender über einen Pull Request (einen Änderungsvorschlag) eingeschleust hatte.
Um 05:08 Uhr UTC eröffnete der Angreifer 37 Pull Requests gegen das AsyncAPI-Generator-Projekt. Fast alle enthielten harmlos wirkende Änderungen (eine gefälschte Spendenseite) – reines Ablenkungsmanöver. Ein einziger Pull Request (#2155) enthielt verschleiertes JavaScript, das die geheimen Zugangsdaten stahl. Wiz Research beschreibt es so:
„Am 14. Juli 2026 eröffnete ein Angreifer 37 Pull Requests im AsyncAPI-Generator-Repository. Fast alle versuchten, eine gefälschte Spenden-Seite hinzuzufügen. Getarnt im Rauschen nutzte ein einziger PR einen fehlkonfigurierten GitHub-Actions-Workflow aus, um einen hochprivilegierten Personal Access Token zu stehlen."
Besonders bitter: Die Schwachstelle war seit Monaten bekannt. Bereits am 29. April 2026 hatte ein Mitwirkender einen Machbarkeitsnachweis eingereicht, am 17. Mai folgte ein Fix-Vorschlag. Dieser blieb jedoch ungemergt – also nicht eingespielt. Als der Angreifer 58 Tage später zuschlug, war die Lücke noch offen.
Mit den gestohlenen Zugangsdaten schob der Angreifer bösartige Commits direkt auf geschützte Branches und löste damit die legitimen Veröffentlichungs-Workflows aus. Der Schadcode selbst war mit rund 880 führenden Leerzeichen in legitimen Quelldateien (etwa validator.js, utils.js) versteckt – in normalen Editoren praktisch unsichtbar. Er arbeitet in drei Stufen:
sync.js) über IPFS nach – ein dezentrales Peer-to-Peer-Dateisystem – und tarnt sie als Node.js-Laufzeitdatei.Das Socket Threat Research Team, das die Pakete binnen 30 Minuten nach Veröffentlichung identifizierte, betont die Ungewöhnlichkeit:
„Dies ist kein Install-Hook-Angriff. Der bösartige Code braucht kein preinstall-, postinstall- oder sonstiges Lifecycle-Skript. Er läuft, wenn das infizierte Modul von Node.js geladen wird, und startet dann einen abgekoppelten Hintergrundprozess, der eine viel größere Nutzlast von IPFS herunterlädt und ausführt."
Der IPFS-Bezug ist kein Zufall: Über diesen Kanal kann der Angreifer die eigentliche Schadsoftware jederzeit austauschen, ohne ein neues npm-Paket veröffentlichen zu müssen.
Das Framework richtet Persistenz ein, überlebt also einen Neustart: auf Linux über einen systemd-Dienst (miasma-monitor.service), auf Windows über einen Autostart-Registry-Eintrag, auf macOS über Einträge in Shell-Startdateien. Es verbindet sich mit einem Command-and-Control-Server (C2) unter 85.137.53.71:8080 und erlaubt dem Angreifer, Befehle auszuführen, Dateien hoch- und herunterzuladen sowie neue Nutzlasten nachzuladen.
Laut JFrog sind weitere Fähigkeiten zwar im Code enthalten, in dieser Version aber deaktiviert:
„Die Nutzlast identifiziert sich selbst als Miasma v3. Ihre aktive Konfiguration aktiviert Persistenz, C2-Kommunikation, beliebige Shell-Ausführung und Fern-Nutzlast-Austausch. Obwohl der Code auch Module für Credential-Diebstahl, Paketverbreitung, KI-Tool-Vergiftung und metamorphe Mutation enthält, sind diese Fähigkeiten in dieser Bereitstellung deaktiviert."
Wichtig: Deaktiviert heißt nicht ungefährlich. Das Credential-Harvesting – das Abgreifen von Browser-Passwörtern, SSH-Schlüsseln, npm- und GitHub-Tokens, AWS-Zugangsdaten und Krypto-Wallets – kann durch den Angreifer per C2-Befehl jederzeit nachträglich aktiviert werden.
Für die meisten deutschen KMU mit einer klassischen Website (etwa auf WordPress-Basis) ist das direkte Risiko gering – vorausgesetzt, sie setzen keine AsyncAPI-Entwicklungstools ein. Kritisch wird es jedoch für:
Entscheidend ist das Zeitfenster: Nur Installationen im Zeitraum 14. Juli 2026, 07:10 bis 11:18 Uhr UTC sind betroffen. Neue Installationen sind sicher, da alle fünf bösartigen Versionen inzwischen entfernt wurden. StepSecurity bestätigt:
„Aktueller Stand (Stand 11:18 UTC, 14. Juli 2026): Alle fünf bösartigen Versionen wurden vom npm-Registry entfernt. Der latest-Tag jedes Pakets verweist wieder auf eine saubere Version. Neuinstallationen sind sicher. Bestehende Installationen und Lock-Dateien aus dem Expositionsfenster sind es nicht."
package-lock.json, yarn.lock oder pnpm-lock.yaml auf die bösartigen Versionen. Befehl (npm): grep -E '"@asyncapi/(generator|generator-helpers|generator-components|specs)"' package-lock.jsonnpm ls @asyncapi/specs @asyncapi/generator @asyncapi/generator-helpers @asyncapi/generator-componentssync.js:
~/.local/share/NodeJS/sync.js~/Library/Application Support/NodeJS/sync.js%LOCALAPPDATA%\NodeJS\sync.jssystemctl --user list-units | grep miasmareg query HKCU\Software\Microsoft\Windows\CurrentVersion\Run /v miasma-monitor~/.zshrc, ~/.bashrc und ~/.bash_profile auf den Marker ### Node Auto-Update Script ###.ls -la ~/.config/.miasma/ und ls -la ~/.cache/mesa_shader_cache/QmQobZSp1wRPrpSEQ56qnyq7ecZh5Bg5k1fnjt4SUwwHb9 oder Qmet4fhsAaWMBUxNDfREHwgiyDeSWy4YSYs9wiKUW5jGyf.docker history <image>npm install @asyncapi/generator@3.3.0 @asyncapi/generator-helpers@1.1.0 @asyncapi/generator-components@0.7.0 @asyncapi/specs@6.11.1 --save-exactnpm cache clean --forcesync.js löschen, systemd-Dienst miasma-monitor.service deaktivieren und löschen (Linux), Run-Key miasma-monitor entfernen (Windows), den ### Node Auto-Update Script ###-Block aus Shell-Startdateien entfernen (macOS).pull_request_target mit Checkout von PR-Code; Secret-Zugriff strikt vom nicht-vertrauenswürdigen Code trennen; Branch-Protection und Reviews für Release-Branches erzwingen.npm audit in die CI/CD-Pipeline integrieren.Wurde ein System kompromittiert, auf dem personenbezogene Daten verarbeitet werden – oder das Zugang zu solchen Systemen hat (Produktionsdatenbanken, CRM, E-Mail-Server) –, liegt eine Verletzung des Schutzes personenbezogener Daten im Sinne von Art. 4 Nr. 12 DSGVO vor. Da Miasma einen aktiven Fernzugriff mit Shell-Ausführung und potenziell aktivierbarem Credential-Diebstahl bietet, ist von einem Risiko für die Rechte und Freiheiten Betroffener auszugehen.
Daraus ergeben sich konkrete Pflichten:
Bußgelder nach Art. 83 DSGVO können bis zu 20 Mio. Euro oder 4 % des weltweiten Jahresumsatzes betragen. Wichtig für KMU: Auch wenn AsyncAPI primär in Entwicklungsumgebungen eingesetzt wird, öffnen kompromittierte Entwicklerrechner oder Pipelines oft die Tür zu Produktionssystemen mit personenbezogenen Daten. Genau darauf zielt Miasma mit dem Abgreifen von SSH-Schlüsseln und Cloud-Zugangsdaten ab.
Es handelt sich bereits um den zweiten Angriff auf dieselben AsyncAPI-Pakete. Der erste erfolgte im November 2025 im Rahmen der Kampagne „Shai-Hulud: The Second Coming", bei der über 600 npm-Pakete und mehr als 25.000 GitHub-Repositories betroffen waren. JFrog stellt jedoch klar, dass es sich um eine neue Kampagne handelt:
„Dieses erneute Auftreten bedeutet nicht, dass die ursprünglichen bösartigen Releases aktiv geblieben sind. Der aktuelle Vorfall verwendet neue Versionen, eine andere Auslieferungskette, andere Infrastruktur und eine substanziell veränderte Nutzlast. Die Kampagne sollte daher als RAT-First-Deployment des breiteren Miasma-Frameworks charakterisiert werden, nicht als aktiv selbstverbreitender npm-Wurm."
Zur Größenordnung: Laut Phoenix Security wurden bis 2026 bereits 59 Supply-Chain-Kampagnen mit 657 bösartigen Paketen über npm, PyPI, VS Code und KI-Tooling identifiziert. Im März 2026 traf es das Paket Axios mit über 100 Millionen wöchentlichen Downloads. Angriffe auf die Software-Lieferkette sind damit zur Dauerbedrohung geworden.
Der AsyncAPI-Vorfall zeigt drei unbequeme Wahrheiten: Erstens reichen technische Vertrauensmechanismen wie SLSA-Provenance-Attestierungen nicht aus, wenn der zugrunde liegende Commit bereits kompromittiert ist. Zweitens genügt eine ungeschlossene, seit Monaten bekannte Konfigurationslücke in einem CI/CD-Workflow, um Millionen von Downloads zu vergiften. Drittens umgeht dieser Angriff bewusst Standard-Schutzmaßnahmen, da er beim Laden des Moduls und nicht bei der Installation zuschlägt.
Die gute Nachricht: Das Zeitfenster war kurz (rund vier Stunden), Sicherheitsforscher reagierten schnell, und alle bösartigen Versionen wurden entfernt. Wenn Sie in diesem Zeitraum keine der betroffenen Versionen installiert und geladen haben, sind Sie nicht betroffen. Wenn doch, handeln Sie jetzt: prüfen, downgraden, Persistenz entfernen, Zugangsdaten rotieren – und die DSGVO-Meldepflicht ernst nehmen. Wer regelmäßig Node.js-Projekte betreibt oder für Kunden entwickelt, sollte diesen Vorfall zum Anlass nehmen, Dependency-Scanning und die Härtung der eigenen Build-Pipelines fest zu verankern.