AsyncAPI npm Supply Chain Attack: Kein Token gestohlen

Der AsyncAPI npm supply chain attack zeigt, dass keine der beiden Kontrollen half, denen Teams eigentlich vertrauen sollten — kryptografische Provenance und das Blockieren von Install-Skripten: Ein Angreifer veröffentlichte vier trojanisierte Pakete mit gültigen SLSA-/OIDC-Provenance-Attestierungen, ohne jemals ein npm-Token zu stehlen, und die Payload läuft unabhängig von --ignore-scripts.

Was ist passiert

Am 14. Juli, zwischen 07:10 und 08:30 UTC, verschaffte sich ein Angreifer Push-Zugriff auf den ungeschützten Pre-Production-Branch next des AsyncAPI-Generator-Monorepos und ließ die eigene, legitime GitHub-Actions-Release-Pipeline des Projekts bösartige Versionen von vier Paketen veröffentlichen: @asyncapi/[email protected], @asyncapi/[email protected], @asyncapi/[email protected] und @asyncapi/specs. Der main-Branch des Projekts war streng geschützt und verlangte verpflichtendes Peer-Review; die Release-Branches nicht. Da die Pakete über die echte CI/CD-Pipeline des Projekts veröffentlicht wurden, tragen sie gültige npm-OIDC- und SLSA-Provenance-Attestierungen — genau das Signal, auf das sich Sicherheitsteams verlassen, um die Vertrauenswürdigkeit der Herkunft eines Pakets zu bestätigen. Zu keinem Zeitpunkt wurde ein npm-Publishing-Token gestohlen.

Die kombinierten wöchentlichen Downloads der vier betroffenen Pakete übersteigen 2,9 Millionen, wobei @asyncapi/specs allein für 2,7 Millionen steht. Die eingeschleuste Payload wird beim Import/Require-Zeitpunkt des Moduls ausgeführt, nicht bei der Installation — die gängige Abwehrmaßnahme npm install --ignore-scripts greift daher nicht. Nach dem Laden lädt sie Miasma RAT von IPFS herunter und erbeutet Browserdaten, SSH-Schlüssel, npm- und GitHub-CLI-Tokens, AWS-Zugangsdaten und Kryptowährungs-Wallets. Alle bösartigen Versionen wurden inzwischen zurückgezogen; die aktuellen sauberen Releases sind [email protected], [email protected], [email protected] und [email protected].

Warum das wichtig ist

AsyncAPI-Tools werden verbreitet zur Dokumentation und Codegenerierung für ereignisgesteuerte APIs eingesetzt — auch in Microservices- und IoT-Architekturen, wie sie in DACH-Softwareentwicklungs- und Fertigungsteams üblich sind. Bedeutsam an diesem Angriff ist weniger seine Reichweite als seine Methode: Er hebelt Provenance-Verifizierung und das Blockieren von Install-Skripten gleichzeitig aus — mit nichts Exotischerem als einem ungeschützten Branch, den niemand absicherte, weil dort „nichts in Produktion läuft“ — dabei läuft genau von dort die CI/CD-Pipeline. Unter NIS2 ist das Management von Software-Lieferkettenrisiken eine ausdrückliche Pflicht für regulierte Unternehmen, und dieser Fall zeigt konkret, warum ein „Provenance verifiziert“-Badge allein keine ausreichende Absicherung ist.

Was Sie jetzt tun sollten

1. Sofortmaßnahme: Prüfen, ob eines Ihrer Projekte @asyncapi/generator, generator-helpers, generator-components oder specs in einer zwischen 14. Juli, 07:10–08:30 UTC veröffentlichten Version installiert hat. Falls ja, den betroffenen Build- oder Entwickler-Rechner als kompromittiert behandeln und npm-Tokens, GitHub-CLI-Tokens, SSH-Schlüssel, AWS-Zugangsdaten sowie im Browser gespeicherte Passwörter darauf rotieren.
2. Prüfen: npm ls @asyncapi/generator @asyncapi/generator-helpers @asyncapi/generator-components @asyncapi/specs über alle Repositories und Lockfiles ausführen, um zu bestätigen, dass Sie auf den sauberen Releases (3.3.0 / 1.1.0 / 1.0.0 / 6.11.1) oder neuer sind.
3. Mitigierung: Verlassen Sie sich bei dieser Angriffsklasse nicht auf --ignore-scripts — es hilft nicht gegen Payloads, die beim Import ausgeführt werden. Stattdessen exakte Abhängigkeitsversionen fixieren und npm ci mit Lockfile-Integritätsprüfung verwenden.
4. Monitoring: Ausgehenden Datenverkehr von Build- und CI-Rechnern auf IPFS-Gateway-Verbindungen prüfen (für die meisten Pipelines ungewöhnlich) und npm-/GitHub-Token-Aktivitätsprotokolle auf auffällige Veröffentlichungen oder API-Aufrufe im betroffenen Zeitfenster durchsehen.

DIESEC Einschätzung

Provenance-Attestierungen belegen, woher ein Paket stammt — nicht, dass der Branch, aus dem es gebaut wurde, vertrauenswürdig war. Genau diesen blinden Fleck sehen wir wiederholt in Mittelstands-CI/CD-Umgebungen: Teams sichern den Main-Branch ab und gehen davon aus, dass Release- oder Staging-Branches risikoärmer sind, nur weil sie nicht „Produktion“ sind — während die Pipeline sie in dem Moment, in dem sie daraus veröffentlicht, genau als Produktion behandelt.

Nicht sicher, ob Ihre Build-Pipeline ein vergiftetes AsyncAPI-Paket geladen hat oder ob Ihre eigene Branch-Absicherung dieselbe Pre-Production-Lücke hat? Kontaktieren Sie DIESEC für eine schnelle Abhängigkeits-Expositionsprüfung und CI/CD-Branch-Protection-Review.

Quellen: Microsoft Security Blog | Socket.dev
Veröffentlicht: 2026-07-21 | Kategorie: Tägliche News | ~4 Min. Lesezeit