Miasma Worm: Most Infected GitHub Repos Are Still Live

Eight days after the Miasma worm forged a 4.3 MB credential stealer into public GitHub repositories and three days after the maintainer it locked out got his account back, most of the infected repos are still serving the payload. SafeDep re-scanned the victim list published on June 5 and ran a fresh GitHub code-search sweep on June 11. Across both, 123 repositories spanning 56 accounts still carry the live dropper on 665 branches. Anyone who clones one of them and opens it in VS Code, Cursor, Claude Code, or Gemini runs the credential harvester with no further interaction.

The repos that got cleaned almost all had a security team behind them. Microsoft’s Azure/durabletask and Azure-Samples/llm-fine-tuning are clean. So are all five of icflorescu’s repos, all of jagreehal, and jahirfiquitiva/Frames. What stays live is the long tail of individual developers, students, and small teams who do not have a security org watching their repos. A Nigerian bank’s corporate site, a DeFi exchange’s trading protocol, a university course’s student submissions, and dozens of personal projects are still serving malware right now.

What we measured

The detection is the one icflorescu published after the worm hit him: do not trust the commit author, check for the payload file across every branch. The dropper lives at .github/setup.js, a single line of roughly 4.3 MB. No legitimate repository ships that file.

The scan never checks out a working tree and never executes anything. A blobless --no-checkout clone plus a per-branch object existence test is enough.

1
# Defensive scan. Nothing is checked out, nothing runs.
2
git clone --no-checkout --filter=blob:none https://github.com/<owner>/<repo>.git probe
3
cd probe
4
git fetch origin '+refs/heads/*:refs/remotes/origin/*'
5
for b in $(git for-each-ref --format='%(refname:short)' refs/remotes/origin | sed 's#origin/##'); do
6
  git cat-file -e "origin/$b:.github/setup.js" 2>/dev/null && echo "INFECTED: $b"
7
done

Two datasets fed the run. The first is the 123 repositories SafeDep published on June 5 as carrying the node .github/setup.js hook at disclosure time. The second is a fresh GitHub code search for that same invocation string, run on June 11, which surfaced 58 candidate repositories. 41 of those 58 were not on the original published list. Every result was then git-scanned across all branches to confirm the payload is present and to record which branch each poisoned commit sits on.

Both numbers undercount. GitHub code search only indexes default branches and skips files larger than roughly 384 KB, so the 4.3 MB setup.js itself never indexes. The small launcher configs are the only reason any of this is searchable, and the worm’s habit of hiding on side branches puts most of the payload beyond code search entirely.

Seventy percent of the published list is still infected

Of the 123 repositories published on June 5, the state on June 11 breaks down as follows.

Six days after a public list named these repositories, and after the campaign made international news for hitting 73 Microsoft repositories, seven in ten were still serving the live payload. The 21 that cleaned up are almost entirely the names with a security team behind them: Azure/durabletask, Azure-Samples/llm-fine-tuning, the icflorescu and jagreehal and jahirfiquitiva repos. The 16 that vanished were taken down by GitHub or their owners. Everything else is untouched.

Who is still serving the payload

The full list of repositories confirmed still-infected on June 11, with the number of poisoned branches and the payload size per repo:

The victims cluster by account, because the worm walks every repository a stolen token can reach. rhemlock7 has 9 repos still infected, nasher721 has 9, jedsada-gh has 8, beatrizamante has 5. One harvested credential poisons an entire personal account.

A sample of who is affected, by category rather than by GitHub stars:

• A bank. Summit-Bank-Limited/corporate-website carries the payload on 12 branches, with commits forged under the address [email protected].
• A DeFi exchange. PositionExchange/position-protocol and three sibling repos are live, the protocol repo poisoned across 27 branches, commits forged as [email protected].
• A university course. Four dcc-cc3002/citric-liquid-* repos are student submissions for a software design course at the University of Chile, each poisoned across 8 to 9 branches with commits forged under students’ @ug.uchile.cl addresses.
• A capstone team. KSU-Quantum-Capstone/CS4850-DL1 at Kennesaw State.
• An infrastructure project. metersphere/helm-chart, the Helm chart for the MeterSphere testing platform, with commits forged under its real @fit2cloud.com maintainers.

Payload sizes range from 4.36 MB to 5.35 MB across roughly 38 distinct sizes. The dropper is recompiled per victim, with rotated AES keys and Caesar shift, so the file hash changes while the architecture stays constant. Only the small launcher configs stay the same, and the scan matches on those.

The commits are forged under the maintainer’s own name

The reason these infections survive on the side branches is that they are built not to be noticed. SafeDep’s original analysis described the github-actions <[email protected]> author on icflorescu’s main branches. That was the loud half. Across the 808 payload-introducing commits catalogued in this scan, all but three are forged under the real maintainer’s own name and email, not the bot’s. Every single one carries [skip ci] to suppress notifications, and the commit dates are backdated across a span from 2013 to 2026 so each poisoned commit blends into that branch’s own history.

1
# PositionExchange/position-protocol, develop branch
2
# https://github.com/PositionExchange/position-protocol/commit/ce456191d71c3399c114b3d539666477df1322bc
3
author:   Justin <[email protected]>
4
date:     2022-11-14T15:51:31Z           # backdated ~3.5 years
5
verified: false                          # unsigned
6
message:  Update README.md [skip ci] [skip ci] [skip ci] [skip ci] skip-checks:true

angular-indonesia/starter-angular-loopback-bulma carries its payload in commit 57ae9502, forged under Julian GM Alimin <[email protected]> and backdated to 2017. The org’s GitHub Pages site angular-indonesia.github.io is poisoned the same way, under maintainer Irfan Maulana <[email protected]>. The MeterSphere commits preserve the original Chinese-language messages of the engineers they impersonate. The forgery is tuned to each repo and each branch.

If you audit your own repos, do not detect this by commit author. A backdated commit forged under your own name passes every “is this the bot?” check. Detect by the payload file.

Cleaning main is not enough

The clearest illustration is metersphere/helm-chart. Its default branch v3.x was cleaned on June 8 by a commit titled Remove Miasma config injection indicators. The maintainers knew and fixed it. Yet on June 11 the 4.6 MB payload is still live on three other branches, fix/pvc, pr@main@build_redis, and refactor/kafka.

This is how most of them stay infected. A maintainer sees the commit on main, reverts or resets it, and considers the job done. The worm planted the same payload on every branch it could reach, each under a plausible backdated commit, and those branches never get scanned. Of the 86 still-infected repos from the published list, many have a cleaned-looking default branch and a live payload one branch over.

Root cause: a credential that outlived everything

The entry vector is now confirmed, from GitHub’s own logs, in icflorescu’s follow-up. The commits were made with his GitHub CLI OAuth token, created on January 17 and used five months later from a Microsoft Azure IP range through the GitHub API. The credential was a token, not his password or his 2FA, which is why neither stopped it.

One structural detail explains why a single theft could walk so many accounts. GitHub stacks many access tokens under one OAuth app authorization, one per machine and per re-login. Revoking an individual token, re-authenticating, even GitHub’s own automatic eviction of old tokens, none of it revokes the grant. Only revoking the whole authorization kills every token under it. icflorescu rotated tokens and rebuilt both his laptops from scratch in May, and the January token still worked in June because the authorization underneath was never revoked. The token was most likely harvested earlier through the TanStack supply-chain wave, a compromised dependency pulled during some routine npm install and reused weeks later.

That is the Shai-Hulud loop. A poisoned dependency harvests a write-scoped credential, the worm uses it to push the payload into every repository the credential can reach, and the payload harvests more credentials when a developer opens any of those repos in an AI editor.

The technique refines an older one. The s1ngularity attack on the Nx build system in August 2025 compromised 2,180 GitHub accounts and exposed 7,200 repositories, exfiltrating stolen data to public repos named s1ngularity-repository. That malware used the developer’s own installed Claude, Q, and Gemini CLIs to enumerate and harvest secrets. Where s1ngularity used AI agents to harvest credentials, Miasma plants the config files that make those same agents run the stealer in the first place.

How to check your own repos

The published npm packages for these projects are clean. No malicious version of mantine-datatable, the AntV packages, or the others was ever shipped to a registry in this arm. The danger is entirely local and it survives npm uninstall. If you have cloned any repository that was active during a Shai-Hulud or Miasma wave:

• Do not open the working copy in VS Code, Cursor, Claude Code, or Gemini, and do not run npm test. A no-checkout clone keeps the payload off your disk.
• Scan every branch for .github/setup.js using the command at the top of this post. Detect by the payload file, never by the commit author.
• If you find it, reset the affected branches to the parent of the poisoned commit rather than git revert, which leaves the dropper retrievable at the old SHA. Then ask GitHub to garbage-collect the orphaned objects.
• Revoke the OAuth app authorization for any CLI you suspect, not just its tokens. Revoking a token leaves the grant alive.
• Treat .claude/, .gemini/, .cursor/, and .vscode/ files as executable code in every diff and every repo you clone. They auto-run commands on folder-open and session-start, and most review workflows ignore them.

The worm’s bet is that cloning source code feels safe. AI coding agents and IDE auto-run features changed that, and on the evidence of 123 repos still live eight days in, most of the ecosystem has not caught up.

Related reading: Miasma worm targets AI coding agents via GitHub repos (the original source-repo analysis), Mini Shai-Hulud “Miasma” hits @redhat-cloud-services (the staged Bun loader, reversed), and the nx build system compromise (the s1ngularity precedent).