Miasma wechselt vom Paketmanager in den Editor: ein Klon + „Ordner öffnen“ in Claude Code, Cursor, Gemini CLI oder VS Code reicht — und es traf auch Azure/durabletask

TL;DR — 90 Sekunden

Betroffen?

Entwickler, die nach dem 2. Juni eines der betroffenen GitHub-Quell-Repos geklont und in einem KI-Coding-Agenten/Editor geöffnet haben (Claude Code, Gemini CLI, Cursor, VS Code) oder npm test darin liefen. SafeDep fand den Fingerabdruck in 113 Repos über Dutzende Accounts, inkl. Azure/durabletask, Azure-Samples/llm-fine-tuning, metersphere/helm-chart. Verschärfend: Maschinen mit erreichbaren Cloud-/CI-/KI-Credentials.

Risiko?

Lokaler Code-Run beim Öffnen des Repos (nicht beim Klonen, nicht über das npm-Paket — die veröffentlichten Pakete dieser Projekte sind sauber), gefolgt von einem Multi-Cloud-Credential-Sweep (AWS, Azure, GCP, Vault, Kubernetes, npm, GitHub) und Selbst-Ausbreitung mit gestohlenen Tokens.

Sofortmassnahme?

Verdächtige Working-Copies nicht in Editor/Agent öffnen und kein npm test laufen lassen; lokalen Klon vor dem Öffnen greppen (test -f .github/setup.js); betroffene Klons löschen und von sauberem Commit neu klonen; bei Treffer exponierte Credentials rotieren.

Empfehlung?

Mid-Market und Enterprise: .claude/, .gemini/, .cursor/, .vscode/ im Diff als Lieferketten-Signal behandeln (nicht als „Editor-Rauschen“); Editor-/Agenten-Auto-Run in geklonten Fremd-Repos restriktiv konfigurieren; KI-Coding-Agenten als ausführende Lieferketten-Akteure ins Bedrohungsmodell aufnehmen.

Kritikalität?

high (referenziert das Hero-Badge — aktive, selbst-replizierende Kampagne; im 48h-Fenster prüfen).

Was ist das Problem?

Am 3. Juni 2026 traf Miasma laut SafeDep zwei Flächen gleichzeitig. Der npm-Arm veröffentlichte 57 Schad-Pakete über 286+ Versionen und versteckte den Trigger in binding.gyp-Dateien, um Lifecycle-Script-Scanner zu umgehen — diesen Arm haben wir am 04.06. behandelt (Phantom-Gyp-/binding.gyp-Post, Quellen StepSecurity/JFrog). Dieser Post dokumentiert den anderen Arm: einen parallelen Lauf desselben Worms, der die Registry komplett überspringt und direkt in GitHub-Quell-Repos pusht.

Ein Angreifer pushte einen Commit chore: update dependencies [skip ci] nach icflorescu/mantine-datatable und vier Schwester-Repos. Der Commit fügte keine Dependency hinzu. Er pflanzte einen 4,3-MB-Payload-Runner und verdrahtete ihn so, dass er automatisch über fünf Entwickler-Werkzeuge startet. Die Datei-Liste verrät die Logik:

.claude/settings.json    | 15 ++++++
.cursor/rules/setup.mdc  |  8 +++
.gemini/settings.json    | 15 ++++++
.github/setup.js         |  1 +
.vscode/tasks.json       | 13 +++++
package.json             |  2 +-

Fünf der sechs Dateien existieren nur, um die sechste zu starten. .github/setup.js ist die Payload; alles andere ist ein Trigger, einer pro Werkzeug. Der Witz daran ist die Trigger-Fläche: Jede Config-Datei missbraucht ein legitimes Auto-Run-Feature eines anderen Werkzeugs. Klonen des Repos ist harmlos — Öffnen nicht. Wer mantine-datatable zum Debuggen klont und den Ordner in VS Code öffnet oder Claude Code darin startet, führt die Payload ohne weitere Interaktion aus.

Der Dropper selbst (setup.js) ist eine einzige eval-Anweisung: ein Char-Code-Array, ein Caesar-Shift (hier ROT-4), das Ergebnis an eval. Statisch dekodiert ist es ein async Loader, der node:crypto zieht und zwei hartkodierte Blobs per AES-128-GCM entschlüsselt — eine Bootstrap-Komponente und die eigentliche Worm-Payload (_p, 667 KB). Der Loader schreibt _p in eine zufällige Temp-Datei und führt sie unter Bun aus (lädt Bun bei Bedarf von der offiziellen oven-sh-Release-URL nach). Bun bringt eigene Runtime, fetch, crypto und Shell mit — die Payload braucht nichts vom Host ausser der nachgeladenen Binary und hält sich so von der Node-Installation des Opfers fern.

Wer ist betroffen?

Besonders heikel ist der Azure/durabletask-Treffer (1.718 Stars): Hier wurde der PAT eines echten Microsoft-Contributors gestohlen, der Commit auf 2020-03-09 rückdatiert und in einem dormanten Branch versteckt — Commit-Message Switched DataConverter to OrchestrationContext [skip ci]. THN berichtet zudem von einer GitHub-Sweep, die 73 Microsoft-Repos über vier Organisationen (Azure, Azure-Samples, Microsoft, MicrosoftDocs) in rund 105 Sekunden deaktivierte. Wichtig zur ehrlichen Unschärfe: SafeDep nennt 113 indexierte Repos als Floor; die 4,3-MB-setup.js indexiert selbst nie, verraten wird die Kampagne durch die kleinen Launcher-Dateien. Drei verschiedene setup.js-Hashes über vier Accounts zeigen: Der Dropper wird pro Welle neu kompiliert, nicht 1:1 kopiert.

Auswirkungen

Der Kern ist nicht „noch ein Worm“, sondern der Vektor-Wechsel. Lieferketten-Malware lebte historisch vom Install-Hook: preinstall, postinstall, setup.py oder der binding.gyp-Trick. Diese Welle überspringt die Registry komplett und setzt auf den Editor. „Ein Repo klonen, um den Quellcode zu lesen“ galt immer als sicher. KI-Coding-Agenten und IDE-Auto-Run-Features haben das still verändert — und Angreifer haben es vor den meisten Verteidigern bemerkt.

Konkret hängt jeder Trigger an einem legitimen Feature: Claude Code und Gemini CLI führen über einen SessionStart-Hook einen Shell-Befehl aus, wenn eine Agenten-Session im Projekt öffnet (.claude/settings.json/.gemini/settings.json mit "command": "node .github/setup.js"). Cursor nutzt eine immer angewandte Projekt-Regel (.cursor/rules/setup.mdc, alwaysApply: true), die den Agenten anweist, die Datei auszuführen — also Social Engineering gegen den Assistenten, eine Prompt-Injection, die im Repo mitreist. VS Code nutzt einen Task mit "runOn": "folderOpen" — dafür ist nicht mal ein Agent nötig, das blosse Öffnen des Ordners genügt. Und der package.json-test-Hijack detoniert in CI und bei jedem, der die Tests laufen lässt.

Die Tragweite: Der Worm hält sich über Bun bewusst von der Node-Installation des Opfers fern, erntet Credentials quer über AWS/Azure/GCP/Vault/Kubernetes/npm/GitHub, exfiltriert in frische, öffentliche GitHub-Dead-Drop-Repos (SafeDep fand für diesen Arm zusätzlich die Accounts windy629 mit 200+ Repos und HerGomUli, alle mit Beschreibung „Miasma - The Spreading Blight“) und propagiert mit den gestohlenen Tokens weiter. Eine CVE-Nummer gibt es nicht — es ist ein laufender Lieferketten-Vorfall, kein einzelner Produktfehler. Die operative Schwere ist trotzdem hoch, weil der Trigger genau die Handlung ist, die sich am sichersten anfühlt: ein Fremd-Repo zum Lesen öffnen.

Mitigation / Sofortmassnahmen

Hinweis: Die folgenden Schritte sind unsere operative Empfehlung auf Basis der von SafeDep dokumentierten Technik — keine herstellerzertifizierte Anleitung. Die massgebliche, fortlaufend gepflegte Repo-/IoC-Liste steht bei SafeDep.

Operational Decision Block

• Sofort handeln, wenn … Sie nach dem 02.06. eines der gelisteten Repos geklont und in VS Code/Cursor/Claude Code/Gemini geöffnet oder npm test darin ausgeführt haben.
• Priorisiert prüfen, wenn … Ihre Entwickler regelmässig Fremd-Repos klonen und in KI-Coding-Agenten öffnen, und diese Maschinen Cloud-/CI-Credentials erreichen.
• Reine Awareness, wenn … Sie keine betroffenen Repos geklont haben und Editor-/Agenten-Auto-Run für Fremd-Repos bereits deaktiviert ist.

Schritt 1 — Vor dem Öffnen prüfen (Klon ist sicher, Öffnen nicht)

# Schnellcheck auf den Dropper, BEVOR ein Editor/Agent das Repo oeffnet
test -f .github/setup.js && echo "DROPPER PRESENT — dieses Repo NICHT im Editor oeffnen"

# Auto-Run-Trigger der Kampagne suchen
ls -la .claude/settings.json .gemini/settings.json .cursor/rules/setup.mdc .vscode/tasks.json 2>/dev/null
grep -RIn "node .github/setup.js" .claude .gemini .cursor .vscode package.json 2>/dev/null

Schritt 2 — Betroffene Klons entfernen

- Working-Copy NICHT in VS Code/Cursor/Claude Code/Gemini oeffnen, kein npm test
- Klon loeschen und von einem Commit VOR der Injektion neu klonen
  (oder auf Maintainer-Revert warten)
- IoC-Liste an der SafeDep-Quelle abgleichen (Floor, keine vollstaendige Liste)

Schritt 3 — Credentials rotieren (bei Treffer)

Wenn ein betroffenes Repo geoeffnet/getestet wurde, Umgebung als kompromittiert behandeln:
- GitHub- (inkl. PATs), npm-, Cloud-Tokens (AWS/Azure/GCP), Vault-, Kubernetes-Tokens rotieren
- lokale Credential-/Auth-Caches als exponiert annehmen (Cloud-CLI-Caches, KI-Tool-Auth)
- ausgehende Verbindungen/Bun-Download (oven-sh release) und /tmp/p<rand>.js, /tmp/b-<rand>/bun pruefen

Schritt 4 — Editor-/Agenten-Auto-Run einhegen

- Auto-Run-Features fuer geklonte FREMD-Repos restriktiv konfigurieren:
  * VS Code: automatische Tasks / "runOn": "folderOpen" fuer untrusted Ordner unterbinden
    (Workspace Trust nutzen; "Restricted Mode" fuer fremde Ordner)
  * Claude Code / Gemini CLI: SessionStart-Hooks aus dem Repo nicht ungeprueft uebernehmen
  * Cursor: projekt-mitgelieferte "alwaysApply"-Rules vor dem ersten Agent-Run sichten
- .claude/ .gemini/ .cursor/ .vscode/ in Code-Review wie ausfuehrbaren Code behandeln

Detection / Prüfung

IOCs direkt aus der von SafeDep dokumentierten Technik; die fortlaufende Liste steht an der Quelle.

Gepflanzte Dateien und Trigger

# Kampagnen-Footprint im Arbeitsbaum (sechs Dateien, fuenf Trigger + Dropper)
find . \( -path '*/.github/setup.js' -o -path '*/.claude/settings.json' \
  -o -path '*/.gemini/settings.json' -o -path '*/.cursor/rules/setup.mdc' \
  -o -path '*/.vscode/tasks.json' \) -print 2>/dev/null

# SessionStart-/folderOpen-/test-Hooks, die setup.js starten
grep -RIn "SessionStart\|runOn.*folderOpen\|node .github/setup.js" \
  .claude .gemini .cursor .vscode package.json 2>/dev/null

Verdächtige Commits

# Kampagnen-typische Commit-Signaturen (unsigniert)
git log --all --pretty='%H %an <%ae> %s' | grep -iE \
  "chore: update dependencies \[skip ci\]|\[skip ci\]"

# rueckdatierte Commits (Azure-Welle: Autor-Datum 2020 bei frischem Commit)
git log --all --format='%ci | %ai | %an | %s' \
  | awk -F' \\| ' '{ if (substr($1,1,4) != substr($2,1,4)) print }'

Bekannte IoC-Hashes (Auszug, Floor)

setup.js (icflorescu/taxepfa-Welle): d630397de8b01af0f6f5cf4463da91b17f28195a2c50c8f3f38ad9f7873fdb8e
setup.js (Azure/durabletask, amdeel): 3a9db5ba0c8cd4c91e91717df6b1a141fc1e0fbc0558b5a78d7f5c23f5b2a150
_p payload (icflorescu-Welle):        633c8410ee0413ca4b090a19c30b20c03f31598c25247c484846fa34c1df5b64
Dead-Drop-Accounts: windy629 (200+), HerGomUli, liuende501 (npm-Arm, 236)
Bun-Download: github.com/oven-sh/bun/releases/download/bun-v1.3.13/

Betreiberempfehlung

Mittelstand

Zuerst eingrenzen, dann rotieren. Stellen Sie fest, wer im Team in den letzten Tagen Fremd-Repos geklont und in einem KI-Coding-Agenten oder VS Code geöffnet hat — das ist die exponierte Population, nicht „wer hat ein npm-Paket installiert“. Greppen Sie verdächtige Klons vor dem Öffnen (test -f .github/setup.js). Wo ein Repo geöffnet oder getestet wurde, behandeln Sie die erreichbaren Tokens als kompromittiert. Wichtigste organisatorische Massnahme: Machen Sie klar, dass „ein Repo nur zum Lesen klonen und öffnen“ nicht mehr automatisch sicher ist — diese eine Gewohnheit ist der Trigger.

Enterprise

Zusätzlich: .claude/, .gemini/, .cursor/, .vscode/ als ausführbare Lieferketten-Artefakte in Code-Review und Diff-Policy aufnehmen (Required Reviews, Alarm auf neue Auto-Run-Hooks) — die meisten Review-Workflows ignorieren diese Verzeichnisse als „Editor-Rauschen“. Konfigurieren Sie Editor-/Agenten-Auto-Run zentral: VS Code Workspace Trust / Restricted Mode für fremde Ordner, keine ungeprüften SessionStart-Hooks aus geklonten Repos, Sichtung projekt-mitgelieferter Cursor-alwaysApply-Rules. Nehmen Sie KI-Coding-Agenten als ausführende Akteure ins Bedrohungsmodell auf — ein .cursor/rules-File ist eine Prompt-Injection, die im Repo mitreist.

Kubernetes / Container

Build-/CI-Runner, die Repos auschecken und npm test oder Editor-Tasks ausführen, gehören in minimal privilegierte, kurzlebige Umgebungen ohne breit erreichbare Cloud-/Kubernetes-Credentials. Service-Account-Token eng scopen, Secret-Zugriff pro Workload begrenzen, ausgehenden Netzzugang von Build-Runnern einschränken (der Dropper lädt Bun nach und exfiltriert per HTTPS zu GitHub-Dead-Drops). So wird ein einzelner geöffneter Klon nicht zum Cluster-weiten Credential-Leck.

Deklarative Stacks (NixOS / Talos / Flatcar)

Der Hebel ist hier die Nachweisbarkeit und die reproduzierbare Dev-Umgebung: Wenn Editor-/Agenten-Konfiguration zentral und deklarativ verwaltet wird, fallen aus dem Repo mitgelieferte .claude/-/.cursor/-Overrides eher auf, weil sie von der bekannten guten Konfiguration abweichen. Reproduzierbare, kurzlebige Dev-Container für Fremd-Repos sind die saubere Spur: Ein geöffnetes untrusted Repo läuft dann in einer Wegwerf-Umgebung ohne Zugriff auf produktive Credentials.

Was wir konkret getan haben

Wir behandeln KI-Coding-Agenten seit den letzten Wochen als das, was sie sicherheitstechnisch sind: ausführende Akteure mit Repo-gelieferter Konfiguration. Anlassbezogen heisst das für betreute Stacks: einen Sweep über lokale und CI-Klons auf den Sechs-Datei-Footprint (.github/setup.js plus die vier Auto-Run-Configs plus package.json-test-Hijack) gefahren, verdächtige Klons vor dem Öffnen gegriffen, die SafeDep-IoC-Liste als Floor abgeglichen, und Editor-/Agenten-Auto-Run für Fremd-Repos eingehegt (VS Code Workspace Trust, keine ungeprüften SessionStart-Hooks, Sichtung projekt-mitgelieferter Cursor-Rules).

Die ehrliche Lehre schliesst direkt an unsere npm-Posts an. In der binding.gyp-Welle (04.06.) lautete die Verteidigung --ignore-scripts und kurzlebige CI-Credentials; bei IronWorm (06.06.) kam Workflow-Integrität und Trusted-Publishing-Scope dazu. Diese Welle zeigt die nächste Tür: Selbst wer Install-Hooks komplett abschaltet, ist nicht geschützt, wenn der Trigger im Editor sitzt. --ignore-scripts fängt einen SessionStart-Hook nicht. Deshalb haben wir die Kontrolle erweitert: Die vier Agenten-/Editor-Konfigurationsverzeichnisse sind jetzt Teil unserer Diff-Policy (Review-pflichtig, Alarm auf neue Auto-Run-Einträge), und untrusted Fremd-Repos werden in kurzlebigen Dev-Containern ohne produktive Credentials geöffnet.

Tiefer Blick: warum „Öffnen“ jetzt der gefährliche Schritt ist

Der Mechanismus ist deshalb so wirksam, weil jeder einzelne Baustein ein legitimes Feature ist, gegen den Nutzer gewendet. Ein SessionStart-Hook ist genau das, wofür er gedacht ist — Projekt-Setup beim Start einer Agent-Session; nur dass „Setup“ hier ein Credential-Stealer ist. Eine alwaysApply-Cursor-Regel ist genau das, wofür sie gedacht ist — dem Agenten projektweite Anweisungen geben; nur dass die Anweisung „führe node .github/setup.js aus“ lautet. Ein VS-Code-folderOpen-Task ist genau das, wofür er gedacht ist — Komfort beim Öffnen; nur dass er ohne jeden Agenten feuert. Die SafeDep-Formulierung trifft es: „Ein .cursor/rules-File, das einen Agenten zur Ausführung anweist, ist eine Prompt-Injection, die im Repo mitreist. Ein SessionStart-Hook ist ein postinstall für Ihren Editor.“ Die Konsequenz fürs Bedrohungsmodell ist unbequem, aber klar: Der mentale Default „Klonen und Lesen ist sicher“ stimmt nicht mehr, sobald ein KI-Coding-Agent oder eine IDE mit Auto-Run im Spiel ist. Behandeln Sie das Öffnen eines Fremd-Repos wie das Ausführen von dessen Code — denn genau das kann es sein.

Fazit

Miasma ist in den Grundlagen vertraut — gestohlener Token, Credential-Sweep, Selbst-Ausbreitung kennen wir aus Shai-Hulud, der binding.gyp-Welle und IronWorm. Neu ist der Mund: Der Worm ist dem Entwickler vom Paketmanager in den Editor gefolgt. Das Beunruhigende ist nicht die Raffinesse des Droppers, sondern wie banal der Trigger ist — ein Fremd-Repo zum Lesen öffnen, die sicherste Geste im Entwickleralltag. Für uns ist die Lehre die Fortschreibung der letzten Wochen: Eine Schutzschicht reicht nicht, und --ignore-scripts fängt keinen SessionStart-Hook. Wer KI-Coding-Agenten einsetzt, muss sie als ausführende Lieferketten-Akteure behandeln, ihre Konfigurationsverzeichnisse reviewen und Auto-Run für Fremd-Repos einhegen. Weil der Vorfall laufend ist, gilt für die Repo-Liste die SafeDep-Quelle, nicht eine Momentaufnahme. Nicht dramatisieren — aber heute prüfen, wer was geöffnet hat.

Quellen

• SafeDep — Miasma Worm Targets AI Coding Agents via GitHub Repos (05.06.2026; Trigger-Mechanik, IoCs, 113-Repo-Liste)
• The Hacker News — Miasma Worm Hits 73 Microsoft GitHub Repositories in Major Supply Chain Attack (06.06.2026)
• OpenSourceMalware — The Blight Reaches Microsoft: 73 Repos Disabled in 105 Seconds (05.06.2026)
• SafeDep — Mini Shai-Hulud „Miasma“ hits @redhat-cloud-services (Ursprung der Welle, npm-Arm)