Miasma: The Self-Replicating Worm That Stormed the Software Supply Chain From the Inside
Last week, a worm called Miasma silently compromised 73 GitHub repositories owned by Microsoft and Red Hat's npm packages — two of the most trusted names in software. Microsoft responded hard: access to the affected repositories was completely disabled, with a "violation of GitHub's terms of service" message. On the Red Hat side, seven critical packages under @redhat-cloud-services — vulnerabilities-client, rbac-client, remediations-client, and others — were swapped for backdoored versions.
And Miasma is not even new. TeamPCP (also tracked as Replicating Marauder, TGR-CRI-1135, UNC6780) publicly released the source code for the Shai-Hulud variant in mid-May 2026. What is roaming the ecosystem right now is a derivative built on that open-source code, that has learned to bypass code-signing mechanisms, and that has added AI coding agents (Claude Code, Gemini CLI, Cursor, VS Code) to its target list.
In this post I will explain why Miasma is a threat beyond classical "penetration testing" thinking, why it has shaken the trust model of the npm and GitHub ecosystems to the core, and what you can do as a developer to protect yourself.
What Exactly Does Miasma Do?
Miasma's killing edge is that it does not exploit a classic vulnerability. As FalconFeeds.io put it: "The worm's genius and the reason conventional defences largely failed is that it operates entirely within legitimate channels. It does not exploit a vulnerability in npm or GitHub." It exploits the trust model: the assumption that "a signed, verified package is safe."
Step by step:
-
The maintainer account is compromised. In the Red Hat case, an employee's GitHub credentials surfaced in Whiteintel's infostealer logs on April 13, 2026 and May 15, 2026. Those credentials became Miasma's patient zero. Through the account, malicious "orphan commits" were pushed to two RedHatInsights repositories, bypassing code review.
-
A preinstall hook is planted. The affected npm packages contain an obfuscated script that runs at install time. The script fires in the background on every machine that runs
npm install. -
Credential collection. The collected inventory is chilling:
- GitHub Actions secrets
- npm tokens
- Cloud credentials (AWS, GCP, Azure)
- Kubernetes service accounts
- HashiCorp Vault material
- SSH keys
.git-credentialsfiles- GCP and Azure identities (added in this new variant, the focus is shifting from secrets to identities)
-
Encrypted exfiltration. The collected data is exfiltrated encrypted to api.anthropic.com:443/v1/api (the irony: the attacker's favourite exfil channel is an AI API). GitHub serves as the fallback exfil point — commits are pushed with the message
IfYouInvalidateThisTokenItWillNukeTheComputerOfTheOwner:<token>. That message is also a bargaining chip: revoke the token, and they threaten to "nuke the owner's computer." -
Propagation. Miasma uses the stolen npm tokens to publish malicious new versions of every other package the victim can reach. If a token you once had that could write to a GitHub repo was stolen, that token is used to inject workflows into other repos. All 73 Microsoft repositories were hit for exactly this reason — the durabletask ecosystem was infected in early May, and the same footprint took down the .NET, Go, Java, JS, MSSQL implementations in early June.
-
Persistence. Even if you uninstall the package, Miasma keeps living. For that, it:
- Injects itself into Anthropic Claude Code's
SessionStarthook - Adds itself to VS Code projects'
.vscode/tasks.jsonwith"runOn": "folderOpen" - Commits malicious steps into GitHub Actions workflows
- Targets AI coding agent configuration files (Claude Code, Gemini CLI, Cursor)
- Injects itself into Anthropic Claude Code's
That last point is critical: developers are now reinfected not only via npm install but every time they open an AI coding assistant.
Why Is the Blast Radius So Wide?
The size of the attack comes from several layers:
- Microsoft itself was hit. 73 repos — across Azure, Azure-Samples, Microsoft, and MicrosoftDocs organizations. GitHub staff disabled access, so if you try to visit one of the infected repos (say
Azure/azure-functions-host), you get the "violation of terms of service" message. - PyPI was reinfected. The
durabletaskPyPI package was hit by TeamPCP at the start of May. Now every sibling repo in the Microsoft side of the durabletask ecosystem (durabletask-dotnet, durabletask-go, durabletask-js, and so on) is also affected. Paul McCarty (6mile) called it "the same wound reopening." - No npm publish is even necessary.
icflorescu/mantine-datatableand four related repos were infected without ever touching the npm registry. The attacker committed a 4.3 MB payload runner directly to GitHub and wired it to fire automatically through five different developer tools: Claude Code, Gemini CLI, Cursor, VS Code, and the npm test script. It detonates the moment a developer clones the repo and opens it in an AI coding agent. - The attacker signs the repos with "Hades" and "Miasma" tags. At the moment, there are 82 public repos with the description "Miasma: The Spreading Blight" and 13 repos with "Hades - The End for the Damned" on GitHub. These are public stashes for the stolen credentials.
Why Does Miasma Break Traditional Defences?
Most security teams will say "we pin versions, we hash-check, we scan in CI/CD." Miasma breaks through all of those layers:
- Every infection gets a unique payload. Older variants copied the same malicious file, which signature-based AV could catch. The new Miasma generates a separately encrypted payload for every victim. Hash lists do not work. File names do not work.
- The "signed package = safe package" fallacy. The npm + GitHub Packages + Sigstore trio verifies "this package was signed with the developer's key." If the attacker steals the key, every package they sign looks legitimate. FalconFeeds.io: "From the registry's perspective, every malicious publish event is indistinguishable from a routine update."
- EDRs are blind. Before the payload runs, it checks for the presence of CrowdStrike, SentinelOne, Carbon Black, and StepSecurity Harden-Runner. If endpoint protection is there, it silently exits (no-op behaviour).
- It does not run on Russian-language systems. Inherited from the GlassWorm campaign, this check shows the attacker's operational maturity: a large share of the researchers and reverse engineers sit in Russian-speaking regions, so this filter likely exists to avoid false alarms.
- It targets CI/CD. It tries to start a container that bind-mounts the host's
/etc/sudoers.dand grants the CI runner passwordless sudo. If your CI machine is compromised, the next build step roots the host. - No footprint in the places you think. As Socket put it explicitly: "uninstalling the npm package or deleting node_modules should not be considered sufficient cleanup."
.claude/settings.json,.vscode/tasks.json,.github/workflows/codeql.yml,.github/setup.js— all of these are files you need to audit.
The Impact on Linux and the Open-Source Ecosystem
Miasma does not directly target the Linux kernel or distributions — but its indirect impact is large:
- Most CI runners are Linux. GitHub Actions, GitLab CI, Jenkins — the default images are Ubuntu/Debian. On Linux, Miasma can hide itself behind its own eBPF rootkit (the IronWorm variant). JFrog: "scrapes every secret it can find on a developer's machine, hides behind an eBPF kernel rootkit, and answers to its operator over Tor."
- PyPI is dominated by Linux-origin packages. Server-side, ML tooling, DevOps utilities — Linux-first packages make up the bulk of Miasma's spread surface.
- AI coding agents are widespread on Linux. Claude Code, Gemini CLI, Cursor, VS Code — they all run on Linux. The "open the repo in an AI assistant" workflow is Miasma's new attack surface for Linux developers.
How Do I Protect Myself?
The urgent checklist for an individual developer or small team:
1. Check for the Infected Packages
Red Hat npm packages (affected as of June 1):
@redhat-cloud-services/vulnerabilities-client
@redhat-cloud-services/tsc-transform-imports
@redhat-cloud-services/topological-inventory-client
@redhat-cloud-services/sources-client
@redhat-cloud-services/rule-components
@redhat-cloud-services/remediations-client
@redhat-cloud-services/rbac-client
If you use any of these, isolate immediately, remove the malicious versions, and rotate every credential.
2. Run a "Common Index Check"
If your package-lock.json or yarn.lock contains @redhat-cloud-services/* or durabletask*, clean the lockfile and move to pinned versions. Run npm audit signatures (npm's own signature-verification command) — it catches most cases.
3. Audit Your AI Coding Agent Configuration
# Claude Code
~/.claude/settings.json
# VS Code workspace
.vscode/tasks.json
# GitHub Actions
.github/workflows/*.yml
.github/setup.js
# Gemini CLI
~/.gemini/ # settings files
# Cursor
~/.cursor/ # settings files
If you see unfamiliar runOn, SessionStart, or folderOpen hooks in any of these, Miasma has almost certainly persisted. Uninstalling the package is not enough — you also need to delete or reset these files.
4. Inspect Your CI/CD Pipeline
Check GitHub Actions for workflows you do not recognise, new uses: ...@main references, or suspicious container images. Audit any step in your CI runners that has sudo privileges — that is where Miasma's privilege escalation happens.
5. Rotate Your Credentials
- Revoke and renew npm tokens
- Reset GitHub PATs and fine-grained tokens
- Rotate cloud provider keys (especially Azure and GCP — Miasma's new cloud identity collectors are laser-focused there)
- Renew Kubernetes service accounts and Vault tokens
- Reissue SSH keys
6. Disable Preinstall Hooks
If you can run in production with npm install --ignore-scripts or npm config set ignore-scripts true, do it. Preinstall/postinstall scripts are not required for most packages. This cuts off the entire preinstall-based attack vector.
7. Flag the "Hades / Miasma" Repos
If a public repo with the description "Miasma: The Spreading Blight" or "Hades - The End for the Damned" has been opened in your organisation's name, these are stashes for the stolen credentials. Keep the repos and their contents as evidence, then report them to GitHub (GitHub auto-cleans these, but can be slow).
A Wider Perspective
Miasma shows where software supply-chain attacks have arrived: "if you do not know what unknown code contains, you do not know who controls the code you are using."
CISA published an alert on the topic last week: "These recent incidents demonstrate how cyber threat actors are abusing tools and processes that support enterprise, cloud, and DevOps environments - specifically CI/CD pipelines, code extensions and workflows." That warning is a long-overdue admission: CI/CD security is now more critical than perimeter security.
The open-source ecosystem is built on a "trust but verify" philosophy. Miasma is hollowing that philosophy out — because the "verify" part has largely been reduced to signature checks. The signature is valid, the package looks legitimate, but the key is stolen. What is the fix?
- Short-lived credentials. npm's proAuth and trusted-publishing initiatives are steps in the right direction, but adoption is painfully slow.
- Multi-party publish approval. A package should not be publishable by a single maintainer, but by at least 2 approvals from an N-person team (multi-sig logic).
- Frozen package hashes. A
package-lock.jsonand SBOM-based approach can fire an alarm when "something you do not know suddenly arrived." - AI coding agent sandboxing. Claude Code, Cursor, Gemini CLI — these tools are processes with file-write authority. Scanning every project the developer opens, looking for hooks smuggled into the agent's workspace, is a new routine we all need.
Miasma is not a vulnerability. It is a social engineering artefact. It exploits the open-source trust model, the developer's workflow, and the default configuration of AI tools. That is why there is no "patch Tuesday, you are safe by Wednesday" solution. Lasting protection comes from re-examining developer habits.
Conclusion
Miasma is the latest and most striking example that the software supply chain is now in a state of permanent war. In an environment where giants like Microsoft and Red Hat can be hit this easily, the "we are small, no one targets us" comfort that individual developers and small teams used to enjoy is gone.
What you need to do today: scan your package-lock.json, audit your AI agent settings, and convert any uses: ...@main references in CI/CD to pinned versions. What you need to do tomorrow: make credential rotation a routine and think twice before adding a new package.
The open-source world is still the safest model for producing software — but keeping it safe is now every developer's individual responsibility.