The 'Miasma' worm source code briefly leaked on GitHub, raising fears of copycat supply-chain attacks

The source code for Miasma, an aggressive credential-stealing framework that has been chewing through open-source package ecosystems, briefly appeared on GitHub before being taken down. Researchers at SafeDep reported the leak yesterday, noting the code surfaced across numerous compromised developer accounts, each hosting a repository pointedly named "Miasma-Open-Source-Release."

That naming choice matters. An accidental leak looks like a forgotten private repo or a misconfigured CI artifact. A coordinated push of identically named repos across many hijacked accounts looks like a deliberate publication, the same playbook used when the earlier Shai-Hulud worm code went public. Miasma reads as a direct descendant of Shai-Hulud, reusing much of its architecture, techniques, and in places its actual code.

What the malware actually does

Miasma is a worm in the original sense of the word. It infects a developer's machine, harvests the build environment along with cloud credentials, then turns those stolen secrets against legitimate repositories and packages. It publishes trojanized versions of trusted packages, which infect the next set of developers who pull them, and the cycle repeats. A single compromised laptop can metastasize into a broad supply-chain incident without any human at the keyboard pushing it forward.

The framework has already been tied to real damage. It has been linked to attacks against Red Hat npm packages and, more recently, to 73 Microsoft repositories on GitHub that were pushed malware before GitHub disabled them.

What makes the leaked code worth studying is how little infrastructure it needs. The toolkit operates with no command-and-control server of its own. It uses GitHub itself as the control and exfiltration channel, which means the traffic blends into normal developer activity and there is no attacker-owned domain or IP for defenders to block.

The credential harvesting is broad. According to SafeDep's analysis, Miasma pulls secrets from cloud providers, CI/CD systems, password managers, Kubernetes, and dedicated secret stores. It then abuses what it finds to compromise npm, PyPI, and RubyGems packages, GitHub repositories, Actions workflows, and JFrog Artifactory instances. For lateral movement it leans on SSH and AWS Systems Manager (SSM).

There is a detail here that should concern anyone using an AI coding assistant. Miasma poisons the configurations of tools including Claude, Gemini, Cursor, Copilot, Kiro, and Cline. Configuration files and instruction sets for these assistants are an emerging attack surface, because a tampered config can quietly steer code generation or run attacker-chosen commands inside a developer's trusted workflow.

The dead-man switch

The nastiest feature in the leaked code is a dead-man switch tied to the stolen GitHub token used for exfiltration. A monitoring component checks the token's validity every minute. If a victim or an administrator revokes the token, the switch fires a destructive command, rm -rf ~/; rm -rf ~/Documents, recursively wiping the user's home and Documents directories.

The monitor installs itself as a systemd user service on Linux or a LaunchAgent on macOS and stays active for up to 72 hours. The practical effect is a trap on incident response. The obvious first move when you spot a compromised token is to revoke it, and here that instinct triggers data destruction. Responders dealing with a suspected Miasma infection should isolate the host and capture forensic images before pulling credentials, rather than revoking tokens on a live machine.

Built to dodge detection

Miasma ships with a five-stage build pipeline that generates a unique payload for every build. SafeDep describes a chain that combines per-file AES-256-GCM encryption of embedded assets, randomized string obfuscation, source-level transformations, JavaScript obfuscation, and a self-extracting loader that wraps the final payload in three layers of encryption.

Random keys and a randomized outer encoding layer mean no two samples look alike. That is a deliberate strike against signature-based detection and static analysis, the techniques many scanning tools still rely on. Defenders who depend on hash matching or simple pattern rules will struggle to catch fresh builds, which pushes the burden toward behavioral detection and runtime monitoring.

Why a leak makes things worse

The uncomfortable lesson from Shai-Hulud is that publishing offensive code accelerates the threat rather than defanging it. After Shai-Hulud leaked, the community got more advanced variants, Miasma among them, and attack rates climbed. There is no reason to expect a different outcome this time. Once the code is in circulation, lower-skilled actors can adopt it, and more capable ones can fork it, retool the obfuscation, and ship their own strains.

For developers and security teams, the defensive advice is unglamorous but effective. Pin your project dependencies to specific versions rather than floating to the latest. Introduce a deliberate delay, ideally several days, before adopting newly released package updates, since most malicious versions get caught and pulled within that window. Validate new builds in isolated test environments where stolen credentials and lateral movement have nowhere useful to go. Audit the configuration files for any AI coding assistants in your toolchain, treating them as sensitive secrets rather than disposable settings.

None of these measures stop a determined worm on their own, but together they slow propagation enough that detection and revocation have time to work. With supply-chain attacks hitting open-source ecosystems at a pace that keeps setting new records, buying that time is most of the battle.