The Miasma Worm's Persistence Trick: How a GitHub Token Outlived a Full Machine Rebuild

Ionut-Cristian Florescu's Miasma worm saga reached its conclusion on June 8, 2026 — four days after his GitHub account was suspended during an active incident he had reported himself. Part 1 documented the live attack. Part 2, written once he was back in control, delivers something more valuable: a confirmed attack chain, a second layer of stealth commits the initial scan missed entirely, and a detection playbook grounded in what actually worked.

The forensics are worth reading carefully. Several of the lessons here will surprise developers who assumed a fresh machine install was a sufficient response to a credential compromise.

The Confirmed Chain of Events

GitHub's support team dug into the logs and confirmed the entry point Florescu had only been able to theorize about in Part 1. The commits were made using his GitHub CLI (gh) OAuth token — created on 2026-01-17 — originating from IP 52.240.186.x, a Microsoft Azure range, and operating entirely through the GitHub API, not the git protocol.

Three things fall out of that confirmation:

• 2FA was never in play. The token grants API access directly. Interactive login with a second factor never gated these writes.
• The forged commits make technical sense. The GitHub API lets the caller set the author field freely. Nothing is server-signed. That's why the commits surfaced as github-actions (or as Florescu himself on side branches) and as verified: false.
• A machine rebuild doesn't revoke old tokens. The gh token was created in January. Florescu rebuilt both machines from scratch in mid-May. A fresh OS install wipes local credentials; it does nothing to tokens already registered on GitHub's side. The January token stayed valid, and the worm reused it on June 3.

Where the token was originally harvested remains inferred rather than proven. The strongest candidate, raised by security researcher Daniel Ruf, is a compromised dependency in the TanStack supply-chain wave. Florescu runs a project on TanStack Start, the timing fits, and the same campaign reportedly reused a Microsoft contributor's credential that traced back to a compromise roughly a month earlier. He is explicit that he cannot pin it to a specific npm install.

The Stealth Layer That Part 1 Missed

Part 1 described five repositories, each hit once on main with a commit forged to look like the github-actions bot. That was only half the picture.

On returning to his account, Florescu found that every repository had also been hit on a second branch, with a substantially sneakier disguise: commits forged under his own name, carrying plausible messages, and backdated to look like old routine work:

Notice the pattern: the further back in the repo's history, the older the fake date. The commit messages were also tailored per project — "Update deps", "Bump version", "Update V6 contributors" — designed to blend into that specific project's rhythm.

If Florescu had trusted the obvious github-actions wave on main and stopped scanning, those side-branch commits would still be sitting in his repos today, some of them apparently dated years ago.

The practical implication: you cannot detect this attack by filtering on author. A backdated commit forged under the maintainer's own identity passes every "is this the bot?" check. The reliable signal is the payload file itself.

The Detection Script

The only trustworthy test across all branches is whether .github/setup.js exists. Florescu's recommended approach:

git fetch origin
git for-each-ref --format='%(refname:short)' refs/remotes/origin | \
  while read b; do
    git cat-file -e "$b:.github/setup.js" 2>/dev/null && echo "INFECTED: $b"
  done

Run this against every repo, on every branch. Not just main. Not just repos you think were targeted.

Blast Radius: Wider Than You Think

The same payload, timestamped within the same 49-second window on June 3, also landed in a repository under a separate organization account Florescu controls — again on both main and a side branch, again with the two-disguise pattern.

The operational conclusion he draws: if one of your accounts was hit, assume the worm enumerated every repository reachable by the harvested token and planted in all of them. Scan everything. Don't scope your cleanup to the account you first noticed.

What to Do Right Now

If you're a maintainer who installs npm dependencies, runs CI, or uses gh locally, here's the response checklist Florescu's incident implies:

1. Audit your active tokens. Go to github.com/settings/tokens and revoke anything you don't recognise or haven't rotated recently. A token you created eight months ago is not invalidated by anything short of explicit revocation.
2. Scan for .github/setup.js on every branch using the script above — not just default branches.
3. Don't trust commit author or date fields as forensic evidence. API-created commits let the caller set both freely. Treat them as attacker-controlled data.
4. Check organization accounts. The worm followed token permissions, not account boundaries.
5. Review your dependency tree for the TanStack supply-chain wave if you run any TanStack projects. The link to a specific package remains unproven, but the campaign is documented and the timing is consistent.

The resolution came after roughly four days of lockout on a sixteen-year-old account, and Florescu is candid that it followed the story going viral on Hacker News and security researchers like Adnan Khan publicly calling it out. The incident highlights that a token sitting in GitHub's database is a permanent credential until explicitly revoked — and that a clean reinstall of your machines is no substitute for auditing what you've already issued.