AsyncAPI-Pakete auf npm mit Schadcode verseucht

Lockfile prüfen.

Zugänge tauschen.

Foto: PixxlTeufel / Pixabay

Am 14. Juli 2026 landeten fünf manipulierte Versionen von vier AsyncAPI-Paketen auf npm. Wer sie in einem Build oder einer Anwendung geladen hat, muss davon ausgehen, dass Zugangsdaten abgeflossen sind.

Das Wichtigste in Kürze

• Betroffen sind fünf Versionen in vier Paketen. Es handelt sich um @asyncapi/generator 3.3.1, generator-helpers 1.1.1, generator-components 0.7.1 sowie @asyncapi/specs 6.11.2 und 6.11.2-alpha.1.
• Der Schadcode startet erst beim Import oder require. Eine blosse Installation löst ihn laut Chainguard nicht aus.
• Das Zeitfenster dauerte 80 Minuten. Die Versionen erschienen am 14. Juli zwischen 07:10 und 08:30 UTC.
• Zugangsdaten sind zu rotieren. Das gilt für npm, GitHub, SSH und Cloud, sobald eine der Versionen geladen wurde.

AsyncAPI: Was passiert ist

Chainguard hat die Analyse am 14. Juli 2026 erstmals veröffentlicht und seither laut Seite nicht aktualisiert. Ein Angreifer stahl über eine Fehlkonfiguration in der GitHub-Actions-Umgebung von AsyncAPI ein privilegiertes Zugriffstoken. Damit publizierte er die fünf Versionen, und zwar mit gültigen Provenance-Signaturen. Die Signatur allein beweist in diesem Fall also keine saubere Herkunft.

Zudem kommen die Pakete zusammen laut SafeDep auf rund 2,9 Millionen Downloads pro Woche. Deshalb war die Reichweite gross, obwohl das Fenster kurz blieb.

Wie der Angriff gelang

Den Einstieg bot ein Workflow mit dem Auslöser pull_request_target. Laut SafeDep reichte der Angreifer 37 Pull Requests ein, 36 davon als Köder. Der Workflow checkte den Code des Pull Requests aus statt den des Basis-Branches und gab so einen organisationsweiten Personal Access Token preis.

Dabei war die Lücke bekannt. Ein Proof of Concept existierte laut SafeDep seit dem 29. April, und ein Korrekturvorschlag war 58 Tage später noch nicht übernommen. Chainguard ordnet den Fall als dritten bemerkenswerten Angriff dieser Art auf grosse npm-Namensräume im Jahr 2026 ein. Wer dieses Muster in den eigenen Workflows prüfen will, findet einen Ansatz im Beitrag über fixierte Abhängigkeiten in GitHub Actions.

Was der Schadcode tut

Dabei sammelt der Code Passwörter aus Browsern, SSH-Schlüssel, npm- und GitHub-Tokens, Cloud-Zugangsdaten und Wallet-Daten. Zudem legt er Persistenz an, unter Linux als systemd-Dienst. Zur Steuerung nutzt er mehrere Kanäle, darunter HTTP, Nostr, Ethereum-Smart-Contracts und Peer-to-Peer-Netze. Wer dahintersteckt, ist offen: SafeDep und Wiz sehen die Verbindung zum Miasma-Framework mit geringer Sicherheit.

Was Entwickler und Admins jetzt tun

Damit der Schaden klein bleibt, gehst du der Reihe nach vor:

• Suche in Lockfiles und Build-Logs nach den fünf Versionen, zum Beispiel mit npm ls @asyncapi/generator.
• Wechsle auf die sicheren Stände: generator 3.3.0, generator-helpers 1.1.0, generator-components 0.7.0, specs 6.11.1.
• Entferne die abgelegten Dateien und die Persistenz auf betroffenen Rechnern.
• Rotiere npm-, GitHub-, SSH- und Cloud-Zugänge.
• Prüfe CI/CD-Läufe aus dem Zeitfenster und sperre ausgehenden Verkehr zu 85.137.53.71 auf den Ports 8080 und 8081.

Fazit

Der Fall zeigt, dass ein einziger Workflow mit pull_request_target eine ganze Paketfamilie kompromittieren kann. Prüfe zuerst deine Lockfiles auf die fünf Versionen und tausche danach die Zugangsdaten. Schaue anschliessend in den eigenen Repositories nach dem gleichen Workflow-Muster.

Quellen: Chainguard, SafeDep. Foto: PixxlTeufel / Pixabay. Stand: 14. Juli 2026.

Recherche und Entwurf KI-gestützt, geprüft und freigegeben von Andreas Brauckmann · So arbeitet die Redaktion