Miasma Worm Compromises 73 Microsoft GitHub Repositories

The Miasma worm compromised 73 Microsoft GitHub repos, spreading via AI coding tools and stealing cloud credentials from developers and CI/CD systems.

A self-replicating worm called Miasma has compromised 73 Microsoft GitHub repositories and forced GitHub staff to disable them. The affected repos include core Azure infrastructure like azure-functions-host and the entire Durable Task family across .NET, Go, Java, JavaScript, MSSQL, and Python. This is Microsoft’s second known breach in weeks involving the same family of malware, which raises an uncomfortable question: did they fully clean up the first one, or did the attackers simply wait?

Miasma is an evolved variant of Mini Shai-Hulud, a worm whose source code was open-sourced by the cybercrime group TeamPCP. The group’s naming has shifted from Dune references to Greek mythology this time, with repo descriptions like “Miasma: The Spreading Blight” and “Hades: The End for the Damned.” Branding aside, the operation started at Red Hat: attackers compromised a Red Hat employee’s GitHub account and pushed unreviewed orphan commits to internal repos, injecting a minimal workflow that requested GitHub’s OIDC tokens. That workflow then published 32 malicious package versions to the npm registry.

The detail that makes this particularly hard to catch is what those OIDC tokens provided.

“The worm initially struck the @redhat-cloud-services npm namespace by compromising a Red Hat employee’s GitHub account. By pushing unreviewed orphan commits to internal repos, the threat actors injected a minimal workflow that requested GitHub’s OIDC tokens.” reads the report published by Cloudsmith. “This registry poisoning workflow in early June executed an obfuscated payload that published 32 malicious package versions to the npm registry. Crucially, because it used legitimate OIDC tokens, the malicious releases carried valid SLSA provenance attestations. To standard registry scanners, the malicious updates were entirely indistinguishable from legitimate, routine code updates.”

Supply chain security frameworks like SLSA are designed to verify that code was built by who it claims to have been built by. They’re not designed to detect a legitimate maintainer whose credentials have been stolen. That’s a meaningful distinction when the threat model involves compromised humans rather than compromised build systems.

From Red Hat’s npm namespace, Miasma moved to attacking source repositories directly, skipping the package registry entirely for some targets and planting payload runners straight into public repos. The delivery mechanism is what makes this particularly sharp for the current moment in software development.

“The delivery approach here was as brilliant as it was terrifying – it was designed to weaponize the AI coding tools.” continues the report. “The dropper executes automatically when an infected repository is cloned and opened within these popular developer tools:”

Every developer who cloned an infected repo and opened it in one of those tools ran the malware without knowing it. AI coding tools have become a standard part of how engineers work, which makes them an efficient delivery mechanism for anyone who can get into an upstream repo.

The payload itself adapted to evade detection in two ways. First, Miasma generates a uniquely encrypted payload for each individual infection, which means hash-based indicators of compromise are useless: the file signature changes with every package version, so blocklists built from known-bad hashes simply don’t work. Second, the worm went beyond the credential scraping of earlier Mini Shai-Hulud variants.

“While previous iterations of the Mini Shai-Hulud malware have focused purely on local secret scraping, the Miasma worm appears to have advanced data collectors specifically engineered for cloud identities in GCP and Azure.” states the report. “It attempts to harvest every cloud identity the infected developer machine and CI/CD runners have access to, proving a clear intent from the threat actors to leve”

Stealing a developer’s local secrets is bad. Harvesting cloud credentials from every CI/CD runner that touched the infected code is a different order of problem.

The fact that Durable Task was compromised a month earlier and then hit again in this campaign matters. Security researchers at OpenSourceMalware have called the latest incident a “re-compromise,” which implies either the original credentials were never rotated, or the attackers retained a foothold that Microsoft’s remediation didn’t fully reach. Microsoft spokesperson Ben Hope told TechCrunch the company “temporarily removed some repositories as we investigated potential malicious content,” that some have been restored after review, and that a small number of customers who pulled content from affected repositories have been notified. The number of affected customers wasn’t disclosed.

“If durabletask sounds familiar, it should. This is a re-compromise. On May 19, three malicious versions (1.4.1, 1.4.2, 1.4.3) of the durabletask PyPI package — Microsoft’s official Azure Durable Task SDK, pulling roughly 417,000 downloads a month — were pushed straight to PyPI inside a 35-minute window, with no matching tags, releases, or CI runs in the GitHub repo. Wiz, Endor Labs, and StepSecurity all traced it back to stolen GitHub Actions secrets and tied it to TeamPCP. The packages were yanked within hours.” states OpenSourceMalware. “A month later, not only is Azure/durabletask gone — so is every sibling repo in the Durable Task ecosystem, sitting one org over in microsoft: the .NET, Go, Java, JS, MSSQL, Netherite, and protobuf implementations, plus the Durable Functions monitor. When the repo at the root of last month’s compromise is the hub of this month’s takedown, that is not a coincidence — that is the same wound reopening. Whoever held those credentials in May plausibly never fully lost them.”

Cloudsmith advises organizations using Azure or Red Hat environments to treat this campaign as a potential active security incident. Any GitHub tokens, SSH keys, CI/CD signing keys, and cloud credentials that may have been exposed should be rotated immediately. Security teams should also check build systems for suspicious repositories and unexpected processes running through tools such as VS Code or AI coding assistants. The case highlights that even software packages distributed through trusted public registries can be malicious, despite appearing legitimate and carrying valid provenance information.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, newsletter)