On June 1, JFrog Security Research published analysis of Shai-Hulud — Miasma, a supply-chain worm that hijacked dozens of packages under @redhat-cloud-services on npm. Microsoft, Sonatype, and StepSecurity followed with expanded IOC lists and a second execution path: silent binding.gyp command expansion that bypasses install-script monitoring. Those reports explain how the worm works. This dispatch maps what is still sitting in the open — and answers a question defenders keep asking wrong: do you need to decrypt the exfil to know who got hit?
No. You do not.
What Miasma Leaves Behind
When primary exfiltration paths fail — or as a parallel channel — the payload creates public GitHub repositories using stolen victim tokens. Each repo is stamped with a campaign marker in the description:
Stolen data lands under `results/` as timestamped JSON files:Each file is a hybrid encryption envelope:
| Field | Role |
|---|---|
envelope | Base64 AES-256-GCM ciphertext (gzip-compressed JSON payload) |
key | Base64 RSA-4096-OAEP–wrapped AES session key |
We pulled live samples from multiple dead drops. The key field decodes to 512 bytes — consistent with RSA-4096 wrapping. The envelope decodes to multi-kilobyte AES-GCM blobs. This matches prior Shai-Hulud analysis from JFrog, StepSecurity, Datadog, and Ox Security: the attacker embeds a public key; only their private key unwraps the session key.
You can read the dead drops. You cannot read the secrets inside them. Defenders should still treat every identity that created one of these repos as fully compromised.
The Live Network
We searched GitHub for repositories whose description matches the Miasma marker with creation dates after June 1, 2026.
83 repositories. Still public. Still populated.
| Metric | Value |
|---|---|
| Total dead-drop repos | 83 |
| Active window | 2026-06-02 → 2026-06-04 (UTC) |
| Repos on Jun 2 | 46 |
| Repos on Jun 3 | 33 |
| Repos on Jun 4 | 4 |
| Unique GitHub accounts used as staging | 3 |
The dead drops are not hosted on attacker infrastructure. They are created on the victim's GitHub identity — the same token the worm stole is used to push encrypted blobs to api.github.com.
| GitHub account | Dead-drop repos | Notes |
|---|---|---|
windy629 | 81 | User account; 487 public repos total; account created 2023-02-12 |
0tabek16 | 1 | User account; repo updated 2026-06-04 UTC |
HerGomUli | 1 | User account; 2 result files in repo |
This is not 83 unrelated victims. It is three compromised GitHub identities, with one account used as a high-volume staging point — consistent with a developer machine or CI runner that executed the worm repeatedly, creating a new Dune-themed repo per exfiltration batch.
windy629 Is a Victim, Not the Operator
The volume on windy629 raises a fair question: is this someone studying the campaign and copying dead drops on purpose? We do not think so.
The account has years of unrelated development history — YOLOv8 object detection, medical NER with BERT, coding-agent research repos — dating to 2023. Then, on May 19, 2026, it sprouted 392 additional repositories with the reversed Shai-Hulud marker (niagA oG eW ereH :duluH-iahS). On June 2–4, 81 more appeared with the Miasma description. Commit messages on every sampled dead drop are identical boilerplate: Initial commit, then Add files. within seconds. READMEs are auto-generated one-liners. No analysis writeups. No forks of vendor research repos.
A researcher replicating the pattern manually might create a handful of sandbox repos with dummy JSON. They would not leave 473 public repositories containing live RSA-wrapped ciphertext keyed to the attacker. They would not get hit by both the May Shai-Hulud wave and the June Miasma wave on the same account.
Assessment: windy629 is almost certainly a compromised developer account, not Miasma operator infrastructure. Treat associated GitHub tokens, npm credentials, Actions secrets, and cloud keys as burned. Notify the account owner if you have an out-of-band path — do not assume malice from the handle alone.
StepSecurity's parallel enumeration surfaced a separate high-volume account, liuende501, with 236 dead drops in the broader binding.gyp wave. Same campaign family, different victims. Our mapping covers the Miasma-branded subset only.
Naming the Repos
Repository names follow {adjective}-{noun}-{number} — the same generative pattern documented in prior Shai-Hulud waves:
| Top adjectives | Count | Top nouns | Count |
|---|---|---|---|
| spartan | 9 | onslaught | 10 |
| savage | 8 | styx | 8 |
| merciless | 8 | thunderbolt | 7 |
| nemean | 7 | manticore | 7 |
| dire | 7 | chimera | 7 |
| ruthless | 6 | havoc | 6 |
Examples: windy629/brutal-onslaught-27954, windy629/savage-manticore-71041, 0tabek16/erebean-chimera-30356, HerGomUli/ruthless-aegis-83111.
Hunt query:
## Exfil Volume Without Decryption
We sampled `results/` directories across the live set. Every sampled repo contained at least one JSON envelope. Sizes vary — small batches around **4–6 KB** on disk, larger multi-file drops exceeding **160 KB** in a single repo (`windy629/savage-manticore-71041` held two result files totaling ~166 KB).
Commit messages on inspected repos were generic. That does **not** mean the dead-man switch (`gh-token-monitor`) is absent on the host. JFrog's guidance still applies: **isolate before revoking tokens.**
## Relationship to the npm Wave
Miasma is not a separate threat actor. It is a **campaign marker** on the Shai-Hulud payload family, delivered through hijacked `@redhat-cloud-services/*` packages and additional packages in vendor IOC tables (Sonatype tracked **281** malicious versions in the binding.gyp wave alone).
Delivery highlights from vendor analysis:
- **`preinstall`: `node index.js`** on type-only packages
- **`binding.gyp` silent execution** when no explicit install script is present
- Bun bootstrap → obfuscated stealer → credential harvest → npm republish / GitHub abuse
- Persistence: `kitty-monitor`, `gh-token-monitor`, AI-tool hooks, workflow injection
What Intercept Cell adds: **post-incident cartography**. The npm packages may be pulled. The dead drops remain searchable. The victims remain identifiable from GitHub metadata.
## Who to Treat as a Victim
If any of the following match your environment, assume compromise until proven otherwise:
1. **GitHub account owns a repo** with description `Miasma: The Spreading Blight`
2. **Developer or CI** installed a flagged `@redhat-cloud-services` version (see JFrog IOC table)
3. **Unexpected Bun dependency** or new `preinstall` script appeared in a dependency tree after June 1
4. **New public repos** with Dune-themed `{adj}-{noun}-{digits}` names appeared on a developer account
For the three accounts in this mapping: treat associated npm tokens, GitHub PATs, Actions secrets, cloud keys, and SSH material as burned. Rebuild runners from clean images. Remove persistence **before** token revocation.
## Defensive Hunting
**GitHub:** search `"Miasma: The Spreading Blight" in:description`. Look for `results/results-*.json`, generic commit messages, and repo-creation bursts on single accounts.
**npm / CI:** audit lockfiles for `@redhat-cloud-services/*` versions in JFrog's XRAY list; prefer `npm ci --ignore-scripts` where lifecycle scripts are not required; inspect for unexpected `bun` dependency additions on patch bumps.
**Network:** exfiltration targets **`api.github.com`** — allowlisted everywhere, rarely blocked. Dead-drop exfil is designed to blend with normal developer activity.
## What This Means
Vendor reports on Miasma focus on package names, install hooks, and CI pipeline compromise. That is the right response for prevention. But the worm also publishes **searchable evidence of victimization** — public repos on stolen tokens, encrypted but attributable through ownership metadata.
You cannot decrypt the envelopes without the attacker's RSA private key. You do not need to. The repo owner is the compromise indicator. Three accounts in this wave. Eighty-three dead drops still live when we looked. The npm packages may be yanked; the GitHub search index does not forget as quickly.
Hunt the description string. Map the bursts. Notify the account owners. Rotate everything that touched a flagged install.
## IOC Summary
| Type | Indicator | Context |
| --- | --- | --- |
| Campaign marker | `Miasma: The Spreading Blight` | GitHub repo description |
| File path | `results/results-*.json` | Encrypted exfil dead drop |
| Naming pattern | `{adjective}-{noun}-{number}` | Dune-themed repo names |
| GitHub account | `windy629` | 81 dead-drop repos (compromised staging account) |
| GitHub account | `0tabek16` | 1 dead-drop repo |
| GitHub account | `HerGomUli` | 1 dead-drop repo |
| GitHub account | `liuende501` | ~236 dead drops (StepSecurity; binding.gyp wave — related campaign) |
| npm scope | `@redhat-cloud-services/*` | Hijacked namespace — see JFrog for version list |
| Persistence | `kitty-monitor.service`, `gh-token-monitor` | Shai-Hulud family persistence |
| Threat marker | `IfYouInvalidateThisTokenItWillNukeTheComputerOfTheOwner` | Commit message variant in Shai-Hulud family |
| Prior marker | `niagA oG eW ereH :duluH-iahS` | Reversed Shai-Hulud description on pre-Miasma dead drops |