CI/CD publizierte den AsyncAPI-Botnet-Loader

Vier AsyncAPI-npm-Pakete liefen am 14. Juli 2026 mit gültiger OIDC-Provenance und lieferten trotzdem einen Multi-Stage-Botnet-Loader. Der Einstieg lag in der CI: ein fehlkonfigurierter pull_request_target-Workflow, danach Push auf den Release-Branch über bot-gebundene Credentials. npm Trusted Publishing blieb technisch sauber und deckte den vorgelagerten Vertrauensbruch nicht ab.

Verwandt:Ein npm-Paket, das die privaten Schlüssel stahl  /  Mini Shai-Hulud: npm-Supply-Chain-Wurm und Abwehr

Was genau passiert ist

Am 14. Juli 2026 um 06:58 UTC landete auf dem Branch next im Repo asyncapi/generator ein Commit unter der Platzhalter-Identität „Your Name“ / you@example.com. Zwölf Minuten später publizierte der legitime Workflow release-with-changesets.yml drei Pakete mit gültiger npm-OIDC-Provenance: @asyncapi/generator@3.3.1, @asyncapi/generator-helpers@1.1.1 und @asyncapi/generator-components@0.7.1.

Laut Microsoft Security Blog lag der Initial Access zuvor über PR #2155 gegen den Workflow manual-netlify-preview.yml. Der Workflow nutzte pull_request_target und checkte den untrusted Head-Commit aus. Der GITHUB_TOKEN war breit privilegiert; Checkout-Credentials blieben bis zum Post-Job-Cleanup in der lokalen Git-Config. Anschließend wurde mit dem asyncapi-bot-Account gepusht. Microsoft formuliert vorsichtig, ob exakt dieses Credential gestohlen wurde. Der pwn-request-Einstieg und die anschließende Bot-Push-Kette sind jedoch belegt und erklären den Weg in den Release-Branch.

Etwa 07:51-08:30 UTC traf derselbe Angreifer asyncapi/spec-json-schemas (Branch master). Über Commits mit fix:-Prefix feuerte if-nodejs-release.yml und lieferte @asyncapi/specs@6.11.2-alpha.1 sowie @asyncapi/specs@6.11.2. StepSecurity, Socket, SafeDep und OX Security dokumentierten denselben Dropper-Stamm und dieselbe Second-Stage-Infrastruktur (laut StepSecurity: Miasma-v3-Familie).

Wichtig für die Einordnung: Es gab keinen gestohlenen npm-Publish-Token. Der Publish-Pfad lief über OIDC Trusted Publishing. Der Vertrauensbruch sitzt davor, in der CI und im Push-Recht auf den Branch, der den Release-Workflow triggert.

Warum „gültige Provenance“ hier trügt

npm Trusted Publishing mit OIDC und SLSA-Attestationen beantworten eine enge Frage: Wurde dieses Artefakt vom autorisierten GitHub-Workflow dieses Repos erzeugt? Die Attestation für die Generator-Pakete zeigte exakt repo:asyncapi/generator:ref:refs/heads/next, Workflow-Datei, Commit-SHA und Run-URL.

Was sie nicht beantworten: War der Commit, der den Workflow anstieß, legitim und inhaltlich sauber? Provenance schützt nicht vor kompromittierten Push-Credentials und nicht vor CI-Jobs, die untrusted Code mit privilegierten Tokens ausführen. Wer pull_request_target mit Checkout des PR-Heads kombiniert, Secrets in solchen Jobs belässt und Branch-Protection auf Release-Branches schwach hält, öffnet genau diese Kette.

Für CISOs und AppSec ist das der zentrale Hebel: Registry-Signaturen und Provenance-Flags allein bewerten den AsyncAPI-Fall als „grün“, obwohl die CI den Dropper bereits ausgeliefert hat. Kontrollen müssen den Source-of-Truth und die Workflow-Permissions mitprüfen.

Payload-Mechanik ohne Install-Hook

In keinem der betroffenen package.json saß ein preinstall/postinstall-Script. Der Dropper startete, sobald der vergiftete Modulcode per require() geladen wurde, also im normalen Generator-Lauf oder in CI-Jobs, die AsyncAPI-Templates bauen.

Stufe 1 spawnt einen detachten Node-Prozess. Stufe 2 holt von einem IPFS-Gateway eine sync.js, abgelegt unter OS-spezifischen Pfaden, die wie eine harmlose NodeJS-Runtime wirken (unter Linux etwa ~/.local/share/NodeJS/sync.js). Stufe 3 entschlüsselt ein gebündeltes Miasma-v3-Implantat. In der ausgelieferten Konfiguration liefen Remote-Shell (ShellExec), Persistenz und C2-Beaconing über mehrere Kanäle (HTTP, Nostr, IPFS, BitTorrent-DHT, Ethereum-Dead-Drop).

Statische Analysen von Aikido und Socket zeigen zusätzlich Module im Bundle, die in dieser Auslieferung per Toggle deaktiviert waren: recon: false (Credential-Harvesting startet nicht), metamorphic: false (Mutation, Evasion und AI-Tool-Poisoning aus) sowie propagate für npm/pypi/ruby/cargo durchgängig false (keine laterale Package-Propagation). Das Kaufhaus lag im Artefakt. Die Laufzeit dieser Welle war eine Remote-Shell mit Persistenz und C2. Host-Forensik bleibt Pflicht, weil Shell-Zugriff und Persistenz aktiv waren.

Was Security-Teams jetzt prüfen

Zuerst den Fakten-Check im eigenen Bestand: Lockfiles und CI-Caches aus dem UTC-Fenster des 14. Juli. Wer @asyncapi/specs nur transitiv über den Parser zieht, sieht die Version oft nicht im direkten Dependency-Tree. Overrides und SBOM-Scans sind hier Pflicht.

Zweitens Host-Forensik: Drop-Pfade unter dem irreführenden „NodeJS“-Namen, detachte Node-Prozesse, ausgehende Verbindungen zu IPFS-Gateways und ungewöhnlichen HTTP-C2-Zielen. Drittens Credential-Rotation auf betroffenen Runnern und Laptops. ShellExec kann Umgebungs-Secrets und lokale Tokens erreichen, auch wenn das gebündelte Harvesting-Modul in dieser Config aus war. Priorität: GitHub PATs, npm-Tokens und Cloud-Keys aus Build-Umgebungen.

Strukturell lohnen ein Cooldown für frisch publizierte npm-Versionen und Runtime-Egress-Kontrollen in GitHub Actions. Provenance bleibt sinnvoll als eine Lage-Ebene neben CI-Hardening, Branch-Protection, Dependency-Cooldown und Verhaltens-Telemetrie im Build.

Einordnung für DACH-Betriebe

AsyncAPI steckt in API-Generatoren, Doku-Pipelines und DevOps-Toolchains. Wer Event-driven Architecture und OpenAPI/AsyncAPI-Automatisierung fährt, hat die Pakete oft indirekt. NIS2 und der Cyber Resilience Act schärfen die Erwartung an Supply-Chain-Risikomanagement. Die Aussage „wir prüfen Provenance“ trägt als alleinige Kontrollaussage nicht, wenn Workflow-Permissions und Branch-Governance offen bleiben.

Der Fall unterstreicht Governance am Source-of-Truth: dem Git-Branch und den CI-Workflows, die die Pipeline füttern. Registry-Attestationen ergänzen diese Schicht. Sie ersetzen sie nicht als alleinigen Vertrauensbeweis.

Häufige Fragen

Jede Frage ist verschlossen. Ein Tippen entriegelt die Antwort.

Reichte die npm-Provenance nicht als Vertrauensbeweis?

Sie beweist den autorisierten Workflow und den Build-Kontext. Die Legitimität des auslösenden Commits und die Integrität vorgelagerter CI-Credentials deckt sie nicht ab. Bei Branch-Compromise kann die Attestation technisch korrekt und für die Risikofrage irreführend sein.

Hätte ein Blocker für Install-Scripts geschützt?

Nein. Der Dropper hing am Modul-Load (require). npm-Lifecycle-Scripts blieben außen vor. Schutz braucht Verhaltens- und Egress-Kontrollen im Build.

Sind frische Installs heute noch gefährlich?

Die bösen Versionen wurden aus der Registry entfernt. Riskant bleiben Lockfiles und Caches aus dem Exposure-Fenster sowie Hosts, die den Payload schon ausgeführt haben.

Welche Credentials zuerst rotieren?

Auf betroffenen Dev-/CI-Systemen: GitHub- und npm-Tokens, SSH-Keys und Cloud-Credentials, die in der Umgebung oder in Runner-Secrets lagen. Begründung ist Shell-Zugriff plus Persistenz. Das Harvesting-Modul war in dieser Auslieferung aus in dieser Config.

Was ist die prioritäre Governance-Maßnahme?

pull_request_target und verwandte privileged Workflows auditieren (kein untrusted Checkout mit Secrets, least-privilege Tokens), Release-Branches absichern (Reviews, Signed Commits, Direct-Push sperren) und CI-Egress begrenzen. Provenance ergänzt das als Nachweis des Build-Pfads.

Lesetipps der Redaktion

LesetippCursor startet git.exe aus dem Repo-RootLesetippLegacyHive-PoC trifft frische Windows-PatchesLesetippZwei Joomla-Uploads landen im CISA-KEV

Mehr aus dem MBF Media Netzwerk

cloudmagazinWenn KI-Agenten reisen: Data-Residency als Operating-ProblemMyBusinessFutureMehr Insolvenzen, kleinere Fälle: Was zähltDigital ChiefsToken-OPEX: Inference steuert, nicht das Seat-Budget

Bildquelle: KI-generiert (Juli 2026)