The Nx s1ngularity npm supply-chain attack: what happened and how to stay protected

Note: the Nx "s1ngularity" attack happened in August 2025. npm removed the malicious versions and Nx shipped clean releases at the time. This is a retrospective explainer — if you installed an affected version during the incident window and never cleaned up, the remediation steps below still apply.

Short answer: In August 2025 the Nx "s1ngularity" attack shipped trojanized versions of the nx build tool and several @nx/* plugins to npm after attackers stole the project's npm publish token through a poisoned GitHub Actions workflow. A postinstall script (telemetry.js) harvested GitHub tokens, npm tokens, SSH keys, .env files, and crypto wallets — and, in a first, hijacked locally installed AI coding CLIs (Claude Code, Gemini CLI, Amazon q) to scan the disk for more secrets. If you installed an affected version at the time, treat every credential that lived on that machine as compromised: rotate anything you never rotated, and delete any s1ngularity-repository repos that appeared in your GitHub account.

Here's what happened, which versions were affected, how to check whether you were exposed, how to clean up, and how a registry firewall stops this class of attack before npm install ever runs the payload.

What happened in the Nx s1ngularity attack?

Attackers didn't guess a password. A pull request introduced a malicious change to Nx's CI workflow that exfiltrated the npm publishing token to an attacker-controlled endpoint. With a valid token in hand, they published poisoned releases of nx and its plugins to the npm registry over a roughly five-hour window on 26 August 2025 before npm pulled the versions and revoked access.

Each malicious package added a "postinstall": "node telemetry.js" hook. Because postinstall runs automatically during npm install on non-Windows systems, anyone installing an affected version during that window executed the payload before their build even finished — no extra step, no warning.

What made this incident a milestone: the malware was one of the first documented cases of weaponizing AI coding agents. It looked for locally installed AI CLIs and invoked them with their safety rails removed — Claude Code with --dangerously-skip-permissions, Gemini CLI with --yolo, and Amazon q with --trust-all-tools — then prompted them to recursively hunt the filesystem for wallets and keys and dump the paths to /tmp/inventory.txt.

Which Nx packages and versions were affected?

These versions were pulled from npm back in August 2025. If any of them ever resolved into your node_modules or lockfile during the incident, treat that host as having been compromised:

The Nx Console VS Code extension was also flagged as affected. npm removed the malicious versions and Nx published clean releases at the time, so a fresh npm install nx@latest has pulled a safe build for a long time now — but that does not undo credential theft that happened back then.

How do I check whether I was exposed?

If you ran Nx in August 2025 and never audited it, it's still worth checking:

1. Check what you installed during the window. Grep old lockfiles and CI logs from around late August 2025 for the versions above: grep -nE "nx@(20\.(9|10|11|12)|21\.(5|6|7|8))\.0" package-lock.json. CI logs from that period are the highest-risk surface.
2. Look for the exfiltration repo. Search your GitHub account (and your org) for public repositories named s1ngularity-repository — often with a numeric suffix — containing a results.b64 file. Their existence is proof of compromise.
3. Check for the local IOCs. Look for /tmp/inventory.txt (and .bak), and inspect ~/.bashrc and ~/.zshrc for an appended sudo shutdown -h 0 line the malware planted.
4. Review AI CLI history. If you had Claude Code, Gemini CLI, or Amazon q installed, check shell history for invocations with --dangerously-skip-permissions, --yolo, or --trust-all-tools that you didn't run.

To see whether any known-bad version is sitting in a project today — s1ngularity or otherwise — run a free registry-aware scan: run the InstallSafe scan against your dependency tree.

What were the indicators of compromise (IOCs)?

• Install hook: postinstall running telemetry.js in an nx or @nx/* package.
• Exfiltration: public GitHub repo s1ngularity-repository-* under the victim's account, holding results.b64 (triple-base64-encoded stolen data).
• Recon artifact: /tmp/inventory.txt listing sensitive file paths.
• Destructive tampering: sudo shutdown -h 0 appended to ~/.bashrc and ~/.zshrc.
• Stolen data: GitHub tokens (gh auth token), npm tokens (~/.npmrc), SSH keys, environment variables and .env files, and wallet artifacts (MetaMask, Electrum, Ledger, Phantom, Solflare).

How would I remediate it?

If your check above turned up anything — or you simply never audited a machine that ran Nx during the window:

1. Rotate every credential that lived on the affected host. GitHub PATs and OAuth tokens, npm tokens, SSH keys, cloud keys, and any API keys that lived in .env. If you never rotated after August 2025, assume they leaked.
2. Delete the leak repos. Remove any s1ngularity-repository-* repositories from your account and org, and revoke sessions.
3. Clean the machine. Delete node_modules, clear the npm cache, remove any planted sudo shutdown -h 0 lines from your shell rc files, and delete /tmp/inventory.txt.
4. Reinstall clean. npm install nx@latest and pin to a known-good version; verify your lockfile no longer references the affected versions.
5. Rotate AI CLI credentials too. If the agents were weaponized, treat any tokens they could reach as exposed.

How does a registry firewall stop this class of attack?

Every mitigation above is after the fact — you're rotating secrets the malware already read. The structural fix is to stop a poisoned tarball from ever reaching npm install. A registry firewall sits between your machines (and your CI, and your AI agents) and the public npm registry, and refuses to serve versions flagged as malicious.

InstallSafe is a drop-in registry you point npm at:

npm config set registry https://r.installsafe.io

Because it enforces at the install boundary, the protection is identical whether a developer, a CI runner, or an AI coding agent triggers the install — which matters a lot for an attack that specifically abused AI CLIs. It serves byte-for-byte tarballs and blocks versions flagged in OSV.dev advisory data, so once versions like the s1ngularity ones are flagged, the firewall stops serving them to your whole fleet at once. Fair caveat: that's an advisory-driven block, not zero-hour detection — behavioral scanners like Socket, Snyk, and Aikido can catch some malware before a CVE lands, so treat the firewall as the fleet-wide enforcement layer, not the only one.

But honestly? All of it — the stolen tokens, the hijacked AI CLIs, the 3 a.m. credential rotation — could have been prevented automatically if your laptops, CI, and agents were pointed at InstallSafe. One line of config, and a flagged tarball just never gets served. Run the free scan to see what's already in your tree, or check pricing for team-wide enforcement.

FAQ

Is Nx safe now?

Yes. npm removed the malicious versions and Nx published clean releases back in August 2025; npm install nx@latest pulls a safe build. Reinstalling does not reverse any credential theft that happened during the incident — if you ran an affected version then and never cleaned up, still rotate everything.

I only ran Nx in CI during the window, not locally. Was I affected?

CI was one of the highest-risk surfaces. The postinstall hook ran in CI too, and CI environments are packed with npm tokens, cloud keys, and workflow secrets. Treat any CI run that installed an affected version in August 2025 as compromised and rotate its credentials if you never did.

What does "weaponizing AI coding agents" actually mean?

The malware detected locally installed AI CLIs (Claude Code, Gemini CLI, Amazon q) and launched them with their safety flags disabled, prompting them to recursively scan the filesystem for wallets and secrets. It was one of the first documented cases of malware using AI assistant CLIs for reconnaissance and exfiltration.

How do I know if my GitHub secrets were leaked?

Search your account and org for public repos named s1ngularity-repository (often with a numeric suffix) containing results.b64. If one exists, your data was exfiltrated — delete it and rotate every credential.

Can a registry firewall stop attacks like this?

Once malicious versions are flagged in advisory data, a registry firewall stops serving them to every machine, CI runner, and AI agent pointed at it — no per-host action needed. It is an advisory-driven block, not zero-hour detection, so it's strongest as a fleet-wide enforcement layer alongside behavioral scanners.

This is a defensive retrospective for developers auditing their own exposure to the August 2025 Nx s1ngularity incident. Verify specifics against the official Nx postmortem, OSV.dev, and the GitHub advisories.