The Miasma worm supply chain attack is the most dangerous software security incident of June 2026. In less than five days, this self-replicating worm tore through Red Hat npm packages, spread across 57 open-source repositories, and then hit its most high-profile target — 73 Microsoft GitHub repositories spanning Azure, Azure-Samples, Microsoft, and MicrosoftDocs.
If your development team installs npm packages, uses AI coding tools like Claude Code or Cursor, or runs Azure-connected CI/CD pipelines, your credentials may already be at risk. This guide covers exactly what happened, how the Miasma worm supply chain attack works, and the precise steps every IT team must take right now.
What Is the Miasma Worm Supply Chain Attack?
The Miasma worm supply chain attack is a self-replicating credential-stealing campaign that began on June 1, 2026. Security researchers at Wiz, Snyk, Aikido, and Socket identified it simultaneously within hours of the first infected packages appearing on the npm registry.
Miasma is a variant of the Mini Shai-Hulud worm, a credential-stealing malware codebase that threat actor group TeamPCP publicly released in mid-May 2026. Because the underlying code was open-sourced, copycat actors can replicate and adapt the techniques with minimal effort — making this attack category a long-term threat, not a one-time incident.
The Miasma worm supply chain attack targets and steals:
- GitHub personal access tokens and npm authentication tokens
- AWS, GCP, and Azure cloud credentials and service account keys
- CI/CD pipeline secrets and environment variables
- Active browser session cookies capable of bypassing multi-factor authentication
- Developer machine credential stores and environment files
Once the worm harvests these credentials, it uses them to propagate itself autonomously to every accessible repository — creating a self-sustaining infection loop that spreads faster than human defenders can respond.
How the Miasma Worm Supply Chain Attack Evolved: 3 Waves in 5 Days
Wave 1 — June 1, 2026: Red Hat npm Namespace Compromised
The Miasma worm supply chain attack launched when 32 malicious packages were published under the @redhat-cloud-services npm namespace, reaching an estimated 80,000 weekly downloads. The initial payload used standard postinstall hooks to execute credential harvesting silently on any machine that ran npm install.
The attacker gained access using a Red Hat employee’s GitHub credentials and active session cookie — credentials that had been stolen by infostealer malware and sitting in dark web criminal marketplaces since April 13, 2026. Seven weeks passed between the initial compromise and the attack. Standard perimeter security never detected a thing.
Wave 2 — June 3, 2026: The Phantom Gyp Technique Bypasses All Defenses
The Miasma worm supply chain attack evolved within 48 hours. Attackers compromised 57 additional npm packages across 286+ malicious versions using a new method called Phantom Gyp — hiding the payload trigger inside a binding.gyp file rather than standard install lifecycle hooks.
This technique was deliberately engineered to bypass every security scanner watching for preinstall and postinstall script abuse. The entire second wave unfolded in under two hours. Simultaneously, the worm skipped the npm registry entirely and began pushing malicious commits directly to GitHub source repositories, disguised as routine dependency updates with commit messages like chore: update dependencies [skip ci].
Wave 3 — June 5, 2026: 73 Microsoft GitHub Repositories Disabled
The third wave of the Miasma worm supply chain attack hit its most visible target. A malicious commit was pushed to Microsoft’s Azure/durabletask GitHub repository using the same compromised contributor account from the Wave 1 incident — confirming the credentials were never fully rotated after the initial breach.
The commit planted configuration files specifically designed to execute the moment a developer opened the repository in an AI coding tool — including Claude Code, Gemini CLI, Cursor, or VS Code. No npm install was required. Simply opening an infected repository in your IDE was enough to trigger full credential exfiltration.
GitHub’s automated abuse detection responded by disabling all 73 affected repositories across four Microsoft GitHub organizations in a sweep lasting just 105 seconds. However, the disruption to global CI/CD pipelines — especially those depending on Azure/functions-action — was immediate.
Why the Miasma Worm Supply Chain Attack Defeated Conventional Defenses
The Miasma worm supply chain attack represents a fundamental shift in how supply chain compromises work. It did not exploit a single software vulnerability. Every CVE list on the planet has zero entries for this campaign.
It operated entirely within legitimate channels. From the npm registry’s perspective, every malicious package publish was indistinguishable from a normal version update by a verified contributor. No anomaly to detect, no alert to fire.
It turned AI coding tools into exfiltration agents. By planting payloads inside AI agent configuration files, the attackers converted Claude Code, Cursor, Gemini CLI, and VS Code from productivity tools into involuntary credential harvesters. This is a first — and it will be copied.
It exploited credentials stolen months earlier. The Red Hat employee whose credentials started this entire campaign was compromised on April 13 — 49 days before the attack launched. Dark web monitoring firm CybelAngel confirmed those credentials appeared in infostealer logs twice before being weaponized. Rotating credentials only after a known breach is too late.
It mutated faster than defenses could adapt. The Phantom Gyp technique in Wave 2 was a direct response to Wave 1 detection methods. The campaign pivoted its delivery mechanism every 48 to 72 hours. By the time defenders built signatures for one variant, the next was already live.
Who Is at Risk From the Miasma Worm Supply Chain Attack?
Your organization faces elevated exposure if any of these conditions apply:
- Development teams that install npm packages without lockfile pinning and hash verification
- CI/CD pipelines pulling dependencies directly from npm without a private registry proxy
- Developers using Claude Code, Gemini CLI, Cursor, or VS Code who opened public GitHub repositories between June 1–9, 2026
- Teams with contributor accounts whose credentials have not been rotated since April 2026
- Organizations whose pipelines depend on
Azure/functions-actionor any of the 73 affected Microsoft repositories - Python development teams using bioinformatics packages including
dynamo-release,spateo-release, orcoolbox— targeted in the June 7 Hades variant wave on PyPI
Immediate Response Steps for IT and Security Teams
These steps must be executed in order of priority. Do not delay.
Step 1 — Rotate All Developer Credentials Immediately
Every developer must rotate GitHub personal access tokens, npm tokens, and cloud credentials — AWS IAM keys, GCP service accounts, Azure service principals — right now. Treat any credential that has touched a developer machine since January 2026 as potentially compromised. Infostealer logs on dark web markets may contain credentials you do not know were stolen.
Step 2 — Audit All npm Dependencies for Miasma-Infected Packages
Run an audit across all projects for packages published under @redhat-cloud-services between June 1–5, 2026. Cross-reference your package-lock.json and yarn.lock files against the full list of 57 compromised npm packages and 37 PyPI packages published by JFrog, Snyk, Socket, and Aikido. Any match requires immediate credential rotation for every machine that ran install.
Step 3 — Pin All Dependencies and Enforce Lockfiles in CI/CD
Implement strict lockfile pinning across all projects. Eliminate floating version ranges (^, ~) in production dependencies. Every package must resolve to a verified, specific hash. Your CI pipeline should fail and block deployment if the lockfile has been modified without an explicit reviewed commit.
Step 4 — Restrict AI Coding Tool Access to Allowlisted Repositories Only
Until your environment is fully audited, restrict Claude Code, Cursor, Gemini CLI, and VS Code GitHub integrations to explicitly allowlisted repositories. Do not open unfamiliar repositories or recently updated public repos in any AI coding tool without manually reviewing the full commit history first — specifically looking for binding.gyp files and configuration changes in .vscode, .cursor, or similar IDE config directories.
Step 5 — Deploy a Private npm and PyPI Registry Proxy
Route all npm installs through a private registry proxy such as Artifactory, Verdaccio, or AWS CodeArtifact. This intercepts every install, allows pre-scan of binding.gyp files and lifecycle scripts, and blocks suspicious new package versions before they reach any developer machine or CI runner.
Step 6 — Monitor for Exfiltration Signals in Build Environments
Inspect CI/CD pipeline logs for unexpected outbound connections from build runners — specifically to GitHub repository URLs with commit messages matching chore: update dependencies [skip ci]. Also watch for processes spawning Bun runtime downloads from github.com/oven-sh/bun/releases during npm install, which is a confirmed Miasma payload indicator.
How Network Security Hardware Reduces Your Blast Radius
The Miasma worm supply chain attack is a software and credential threat — but your network security infrastructure is your last line of containment when an endpoint is already compromised.
Next-generation firewalls with deep packet inspection and SSL inspection can detect and block unauthorized outbound data exfiltration from CI/CD servers even after a developer machine has been infected. If a build runner suddenly establishes connections to unknown GitHub dead-drop repositories, a properly configured NGFW with application-layer awareness will catch and terminate that traffic before credentials leave your environment.
Explore enterprise-grade next-generation firewalls with SSL deep inspection from Fortinet, SonicWall, and WatchGuard — designed precisely for detecting lateral movement and unauthorized data exfiltration in enterprise networks.
Network segmentation between development infrastructure and production credential stores is the single most effective architectural control against worm-based credential theft at scale. CI/CD orchestrators, backup servers, and cloud credential management systems must sit in isolated network segments with strict egress filtering and no direct internet access.
Build that segmented development infrastructure with enterprise managed network switches and HPE Aruba access layer solutions — the foundation of a zero-trust network architecture that contains breaches before they escalate.
The Bigger Picture: Backup Infrastructure Is Being Targeted Simultaneously
The Miasma worm supply chain attack arrived in the same week as the disclosure of CVE-2026-44963, a critical CVSS 9.4 vulnerability in Veeam Backup & Replication that allows any authenticated domain user to execute remote code directly on backup servers. These two incidents together are not coincidence — they represent a coordinated escalation in targeting the infrastructure organizations depend on for both development and recovery.
When your software supply chain and your backup infrastructure are compromised in the same window, ransomware deployment becomes trivial and recovery becomes nearly impossible. Security teams must begin treating these as a unified threat category requiring coordinated architectural defense — not separate point solutions.
Current Status: What Happened to Microsoft’s Affected Repositories?
Microsoft confirmed that it temporarily removed the affected repositories while investigation continued. By June 9, 2026, Microsoft began progressively restoring repositories that cleared forensic review, while others remained offline pending further analysis.
Development teams depending on Azure/functions-action or other affected repositories for CI/CD pipelines should maintain local mirrors of critical dependencies and avoid direct pulls from public Microsoft GitHub repositories until Microsoft issues full clearance through official security advisories.
Key Takeaways: What the Miasma Worm Supply Chain Attack Means for Enterprise Security
The Miasma worm supply chain attack is a turning point in how organizations must think about software security. Five critical lessons emerge from this incident:
Infostealer infections from months ago are active threats today. The Red Hat credentials that started this entire campaign were stolen 49 days before they were weaponized. Dark web monitoring and proactive credential rotation on a regular schedule — not just after known breaches — is now a baseline security requirement.
AI coding tools have become a new attack surface. The deliberate targeting of Claude Code, Cursor, Gemini CLI, and VS Code configuration files represents a fundamentally new attack vector. IDE and AI agent security must now be treated with the same rigor as endpoint security.
Zero CVEs does not mean zero risk. The entire Miasma campaign has no associated CVE entries. It exploited trust and legitimate credentials, not software vulnerabilities. CVE-based scanning and patch management are necessary but not sufficient defenses.
Supply chain attacks now self-replicate. Previous supply chain compromises required manual attacker intervention for each propagation step. Miasma propagates autonomously using harvested credentials. Human response speed cannot match automated worm propagation — architectural controls and automated detection are mandatory.
Network segmentation is non-negotiable. Once credentials are compromised, network segmentation and egress filtering are the only controls that prevent full organizational compromise. This is the lesson every Miasma victim that avoided total breach will confirm.
Frequently Asked Questions About the Miasma Worm Supply Chain Attack
What is the Miasma worm supply chain attack? The Miasma worm supply chain attack is a self-replicating malware campaign active since June 1, 2026 that compromises npm packages, PyPI packages, and GitHub repositories to steal developer and cloud credentials, then uses those credentials to propagate itself to additional repositories autonomously.
Am I affected if I use npm packages in my projects? If your project uses any packages under the @redhat-cloud-services npm namespace installed between June 1–9, 2026, or any of the 57 additional compromised npm packages identified by Snyk and JFrog, your machine and credentials should be treated as potentially compromised. Rotate all credentials and audit your lockfiles immediately.
Does opening a GitHub repository in VS Code trigger the Miasma worm? Only if the specific repository has been compromised with Miasma configuration file injections. The affected repositories include the 73 Microsoft Azure GitHub repositories disabled on June 5, 2026, and repositories identified by SafeDep including icflorescu/mantine-datatable. Do not open unfamiliar or recently updated public repositories in AI coding tools without first reviewing the commit history.
How does a firewall help against supply chain attacks? A next-generation firewall with deep packet inspection cannot prevent the initial credential theft on a developer endpoint, but it can detect and block the outbound exfiltration of stolen credentials from your network and prevent lateral movement from a compromised development machine to production systems. Network segmentation enforced at the switch and firewall level is the most effective containment control available.
Is Microsoft’s GitHub back online after the Miasma worm attack? Microsoft began restoring affected repositories progressively after June 9, 2026. Check Microsoft’s official GitHub security advisory page for current repository status before resuming CI/CD pipelines that depend on affected repositories.
