If your engineering team has been breathing a little easier thinking that open-source supply chain attacks are only targeting software libraries and dependencies via simple typosquatting attempts on package registries, you’re in for a harsh reality check.
Over the last week, yet another self-replicating malware campaign, this time known as Miasma, has torn through the open-source software ecosystem. What started as an exploit in Red Hat’s npm packages has since escalated to a sprawling supply chain disaster, spreading to 73 Microsoft GitHub repos across the most popular environments like Microsoft Azure and Durable Task.
The fallout of this worm further emphasises how the software security landscape has drastically shifted over the past few months. If you rely on public registries and repos, and your devs are using AI coding tools, you have a high likelihood of being impacted by this specific attack vector.
Miasma is an evolved, highly-aggressive variant of the Mini Shai-Hulud worm open-sourced by the threat group TeamPCP. The attackers have traded their Dune-themed naming convention for Greek mythology this time around with the repo description "Miasma: The Spreading Blight" and "Hades - The End for the Damned". Regardless, their operation has only grown stronger.
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. 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.
Miasma quickly shifted from targeting package registries to attacking source repositories directly. It skipped the npm registry entirely for several targets, planting a hefty payload runner straight into public repos like icflorescu/mantine-datatable. The delivery approach here was as brilliant as it was terrifying - it was designed to weaponise the AI coding tools. The dropper executes automatically when an infected repository is cloned and opened within these popular developer tools:
Claude CodeGemini CLIVS CodeCursorBy now, the contagion has fully spread into Microsoft's GitHub orgs. According to our friends at OpenSourceMalware, a staggering 73 repos were compromised and subsequently disabled by GitHub staff, including core tools like Azure/azure-functions-host and the entire ecosystem surrounding durabletask (spanning .NET, Go, Java, JavaScript, MSSQL, and Python implementations).
Security researchers noted that the durabletask PyPI package had been hit by TeamPCP a month prior. The fact that the exact same ecosystem was completely taken down this month indicates a persistent wound, one where the original creds used in May were likely never fully rotated or remediated.
The genius of this Miasma worm lies in how it adhered to legitimate workflows. It does not exploit any software vulnerability in GitHub or npm. Instead, it exploits the underlying trust model of the modern engineering ecosystem. Compromised dev creds led to a legitimate GitHub OIDC token being requested. This was followed by a malicious build being published with valid SLSA provenance, which ultimately led to conventional scanners seeing it as a routine trusted update. By stealing legitimate maintainer credentials, the worm was able to act exactly as an authenticated publisher would have.
Furthermore, Miasma generates a uniquely encrypted payload for each individual infection. This means traditional hash-based IOCs are functionally useless for broad detection, as the file signature changes with every single package version. Andrew McNamara of Red Hat explained in a dedicated blog post where SLSA's boundaries fall short.
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. 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 leverage access away from the codebase and directly into live cloud environments.
If your company operates within the Azure or Red Hat ecosystems, you must start treating these sorts of incidents as active incidents that could be impacting your environment directly. First of all, assume secrets exposure and rotate. Because Miasma specifically hunts for developer credentials, assume everything on a compromised machine or CI/CD pipeline has been leaked. You’ll need to revoke and rotate the following types of credentials:
You’ll also need to audit the developer environments. Check local workstations and build environments for unauthorised activity in GitHub, check for any unknown newly-created repositories under your organisation, and any unexpected background processes executing via VS Code or the above-mentioned AI coding CLIs.
Finally, relying purely on the latest version of these public packages is a massive liability for your team. Move towards explicit dependency allowlisting and generate strict SBOMs to verify exactly what is entering your build streams. This is the best way to know if you are impacted, or if anything new has been introduced into the dependency tree.
The Miasma campaign proves that having signed keys and authenticated maintainer accounts are no longer an absolute guarantee of safety. When upstream registries and repos are compromised, public code becomes one of the easiest, and most direct, ways of getting pwned. To survive these sustained supply chain attacks like Miasma and Shai-Hulud, businesses should consider implementing an artifact management layer for open-source dependencies.
With Cloudsmith, developers and security teams can define strict admission control policies that block packages failing specific security checks, regardless of whether they have a valid maintainer signature. Either by blocking a malicious package based on OSV.dev threat reports, or by defining a simple cooldown policy for newly-published dependencies, organisations can automatically catch, isolate, and inspect incoming upstream dependencies before they ever reach a developer's machine or any kind of production build pipeline.
