Look, Halil, let me walk through all three with the architectural specifics you need.
1. The bypass_2fa self-propagation mechanism
The worm hunts for npm tokens where bypass_2fa === true—and that's the critical privilege escalation. According to Step Security's analysis of the TanStack compromise, once it finds these tokens, it enumerates every package that developer has publish rights to via /-/org/{org}/package endpoints or maintainer metadata, then generates malicious patch version bumps for each one.
Here's the thing: it doesn't just add itself to existing packages. The worm uses these tokens to push new malicious versions, and because bypass_2fa is already enabled, there's no second-factor friction on publication. When a developer runs npm install on any of these compromised packages, the install script executes, extracts their cloud credentials (AWS/GCP/Azure from ~/.aws/credentials, ~/.config/gcloud, ~/.azure), harvests their npm tokens (the cycle continues), finds their packages they can publish to, and propagates again.
The blast radius is a directed graph of maintainer relationships. If you're a maintainer on 15 packages and get infected, every one of those packages gets a malicious version within minutes. Your downstream dependents inherit the malware on their next install. The worm propagates to both existing packages AND new malicious packages within authorized scopes—so the compromise surface is the union of all package maintainer's portfolios, not just the initial victim.
2. Dead-man switch remediation sequence — the exact order
This is critical: the gh-token-monitor persistence is a systemd user service on Linux (~/.config/systemd/user/gh-token-monitor.service) and LaunchAgent on macOS (~/Library/LaunchAgents/com.user.gh-token-monitor.plist). The handler script is stored encrypted at ~/.config/gh-token-monitor/handler with the token reference at ~/.config/gh-token-monitor/token.
The safe remediation sequence, per the GitHub TanStack compromise checker and GitLab's analysis, is:
- Disable the service first —
systemctl --user disable gh-token-monitor (Linux) or launchctl unload ~/Library/LaunchAgents/com.user.gh-token-monitor.plist (macOS)
- Remove persistence files — delete
~/.config/systemd/user/gh-token-monitor.service, ~/.config/gh-token-monitor/, and the LaunchAgent plist
- Kill any running monitors —
pkill gh-token-monitor or manual process inspection
- ONLY THEN — revoke the GitHub token
Do it in any other order and the handler executes rm -rf ~/ ~/Documents or equivalent. There's no recovery from that sequence error on a production workstation.
3. The 95-version scope vs. 31 — what it tells us about the CI/CD window
That expansion from 31 to 95 versions represents cascading lateral developer-to-developer infection, not a single-point compromise. Each version is a distinct publish event to a distinct compromised package, and those packages span multiple CI/CD pipelines with distinct OIDC configurations.
The worm in CI/CD environments exchanges GitHub OIDC tokens for per-package npm publish tokens entirely bypassing traditional authentication. Per the Miasma research from Wiz and GitLab, the malware sat in pipelines likely for weeks before activation, harvesting tokens and cataloging which packages each OIDC identity could publish to.
The 95-version spread tells me the initial GitHub Actions compromise happened significantly earlier than the burst publication window—the delta variant was selective about timing to maximize propagation. Each new version represents either a new developer machine compromised, or a new package hijacked via stolen credentials from a previously compromised account.
This wasn't a smash-and-grab. It was a patient, multi-week credential harvest followed by coordinated worm activation when the compromise surface was maximized.