The Nx s1ngularity attack: a malicious package that tried to use your AI coding tools

The short answer

On 26 August 2025, malicious versions of the nx build tool and several @nx/* plugins were published to npm. They were live for about four hours.² A postinstall script scanned the file system for text files and credentials and posted them, encoded, to a new GitHub repository under the victim’s own account, with s1ngularity-repository in its name.¹ Nx’s postmortem adds that the malware “attempted to use local AI tools (like Claude and Gemini).”²

That last detail is why this incident belongs on an agent-safety blog. An AI coding CLI installed on a developer’s machine is a capable tool for anyone who can run a command there, including malware. Settings that block “no prompts” modes by policy make it a worse one.

What happened

From Nx’s advisory and postmortem:¹²

How the attacker got the npm token

Nx’s advisory explains the chain in its own words:¹

1. A pull request workflow used the pull_request_target trigger, which runs with elevated permissions and a read/write GITHUB_TOKEN for the target repository.
2. The same workflow echoed the pull request title inside a shell step, echo "Validating PR title: ${{ github.event.pull_request.title }}", so a title like $(...) ran as code.
3. The vulnerable workflow had been reverted on master, but Nx believes the pull request targeted an outdated branch that still had it.
4. With the elevated token, the injected code triggered the publish.yml workflow on a malicious commit that sent the npm token to a webhook.

That’s two classic GitHub Actions mistakes together: untrusted text interpolated into a shell, and pull_request_target giving fork pull requests the target repository’s permissions.

What the malware did

Per the advisory:¹

• Collected credentials. Scanned for text files, collected paths and credentials, and posted them encoded to a GitHub repository named with s1ngularity-repository under the user’s account.
• Left an inventory. A file at /tmp/inventory.txt listing files it probably read.
• Changed shell start-up files. Added sudo shutdown -h 0 to .zshrc and .bashrc, so a new terminal would ask for the password and shut down.
• Ran wherever packages install. Not only npm install: the advisory lists transitive dependencies, AI agents, editors and editor extensions as ways a package can be installed without anyone typing the command.

And from the postmortem: it attempted to use local AI tools like Claude and Gemini.² Nx’s post doesn’t say which tools ran, with what instructions, or how often it worked, and we don’t fill that in from other sources.

Why the AI tool detail matters

Most malware has to bring its own logic for finding secrets. An AI coding CLI already knows how to search a file system, read files, run commands and summarise what it found, and it’s already authenticated. If a script can start it in a mode that never asks for confirmation, the script gets a capable assistant for free.

Two things limit that:

1. The CLI refuses unattended “no prompts” modes, because policy has turned them off.
2. The CLI can’t reach much, because it runs in a sandbox and credentials aren’t lying around for it to read.

Settings that make your AI CLI a worse tool for malware

Put these in system or managed settings, not user settings, so a script running as the user can’t simply edit them back. Our posts on Claude Code managed settings and agents reading .env files go further on each side.

None of these stops the postinstall script itself; it runs with your permissions regardless. They stop it from borrowing a more capable tool.

The lessons for your own repositories

The way in was a CI workflow, not an AI tool. If you maintain anything published to a registry, the advisory’s attack vector is the part to check today:¹

• Search your workflows for pull_request_target. For each one, ask whether it needs the target repository’s token. Most don’t; pull_request runs with the fork’s limited permissions.
• Never interpolate pull request fields into run: steps. Titles, branch names and bodies are attacker-controlled text. Pass them through environment variables and quote them.
• Check old branches too. Nx believes the attacker targeted an outdated branch that still had the vulnerable workflow. Fixing master isn’t enough if other branches can be pull request targets.
• Keep publishing credentials out of reach of anything a pull request can trigger. A publish workflow should need a person or a protected environment.

If you ran an affected version

The advisory’s own steps, condensed:¹

1. Check your GitHub security log for repository creation, and your account for a repository named with s1ngularity-repository.
2. Check for /tmp/inventory.txt.
3. Run npm ls nx; reinstall a clean version and clear npm, yarn and pnpm caches, including ~/.npm/_npx.
4. Rotate GitHub tokens (including the gh CLI’s, by revoking its app authorisation), npm tokens and anything in your environment variables.
5. Remove unfamiliar lines from .zshrc and .bashrc.
6. Purge the versions from internal registries.

What we don’t know

• Which AI tools the malware actually ran, and with what result. Nx says it “attempted”; that’s all the primary source states.²
• How many machines were affected. We cite no count.

For a related case where malicious code shipped inside an AI tool itself, see the Amazon Q extension post. To check a repository’s workflows and agent configs before you trust them, run the Deedglass scan Action on pull requests, paste a config into the check page, or run npx deedglass scan (how the grade works); to try tool-call rules in your browser, open the playground.

Written with AI assistance and checked against our claims register.