Nx S1ngularity Attack: The Workflow-to-npm Token Path
The documented August 2025 Nx attack path, exact affected versions, workstation indicators, and issuer-side response—without an invented victim count.
On this page(13)
Table of Contents
Revised October 4, 2026. The earlier article treated download volume and unverified repository counts as measured victims, described affected versions as a continuous range, and included untested cleanup and token-rotation scripts. Those claims and scripts have been removed. This account follows the Nx advisory and its later postmortem; it does not estimate how many people lost data.
What happened in the August 2025 Nx attack?
On August 26, 2025, an attacker published malicious versions of several Nx packages to npm using a stolen npm publishing token. Their postinstall code looked for sensitive local files, attempted to use installed AI command-line tools, and uploaded collected data to a public repository under the affected user’s GitHub account. Nx says the malicious packages were available for about four hours. Installing a listed version during that window warrants investigation; it does not by itself prove which data left a particular machine.
How did a PR title reach the publishing token?
Nx reports that a PR-title validation workflow inserted untrusted title text into a shell script. The workflow ran under pull_request_target and had a read/write GITHUB_TOKEN. The attacker used that access to create a branch with a changed publishing script and trigger publish.yml through workflow_dispatch. That publishing workflow held the npm token, which the modified script sent away. The stolen npm token then enabled malicious package publication outside Nx’s normal release pipeline.
The initial vulnerable workflow had been reverted on the main branch after a warning, but an older target branch still carried it. The Nx advisory documents the earlier warning, the August 24 exploitation, and the August 26 npm releases as separate events. GitHub’s workflow guidance warns against putting untrusted context directly in inline shell code and recommends restricting GITHUB_TOKEN permissions.
Which versions were listed?
The Nx advisory names specific versions, not every version between two endpoints. For nx: 20.9.0, 20.10.0, 20.11.0, 20.12.0, 21.5.0, 21.6.0, 21.7.0, and 21.8.0. For @nx/devkit, @nx/js, @nx/workspace, and @nx/node: 20.9.0 and 21.5.0. For @nx/eslint: 21.5.0. For @nx/key and @nx/enterprise-cloud: 3.2.0. Check the current advisory for package-specific changes before treating a dependency as safe or affected.
Nx also found that Nx Console could install the latest nx package while checking its version. During the exposure window this created an additional installation path. A developer did not need to run an explicit nx install command for that path to matter; whether it affected a given workstation still requires evidence from its installed packages and logs.
What did the malicious install do?
Nx’s advisory says the postinstall script scanned local text files and credentials and used the GitHub CLI to create a repository whose name contained s1ngularity-repository. The payload also attempted to invoke locally installed AI CLI tools while collecting file paths and altered shell startup files with a shutdown command. An AI tool being installed is not evidence that this payload ran or that the tool returned sensitive data.
A public repository, a local /tmp/inventory.txt file, suspicious GitHub account activity, or the unexpected shell-file command are useful indicators. None proves the complete set of exposed secrets. The absence of one indicator does not clear a machine if a malicious package version was installed; inspect package records, activity, and the issuer-side state of credentials that may have been accessible.
How should a team check and respond?
1. Establish installation and exposure
Check package lockfiles, installed package versions, CI logs, workstation install history, and the times of execution against the package-specific Nx advisory. Include editor environments where Nx Console might have resolved latest. Preserve relevant logs and host evidence before removing packages or changing shell files. Do not run a copied “cleanup” script from an incident summary.
2. Look for reported indicators
Review the affected GitHub account’s security log for unexpected repository creation, including names containing s1ngularity-repository. Check whether /tmp/inventory.txt and suspicious .bashrc or .zshrc changes exist. Nx says GitHub may already have hidden or removed a leaked repository, so an empty repository list alone is inconclusive.
3. Contain credentials at their issuers
If the payload could read a working credential, have its owner identify the account, access, dependent workload, and relevant activity before rotating or revoking it at the issuer. Prioritize access that could publish packages, reach cloud resources, or create further credentials. Replace compromised GitHub CLI access as Nx advises. Test dependent services after any change and record uncertainty where local or issuer logs are incomplete.
4. Repair the installation path
Remove affected package versions and caches using the package manager and vendor guidance appropriate to the environment, then install a verified safe version. Check shell startup files for the reported change. Nx moved its publishing to npm Trusted Publishers and added manual approval and provenance checks. Trusted publishing removes the long-lived npm publishing token from that workflow, but it does not make every future package automatically safe.
What can Cremit contribute to this investigation?
Cremit can help find exposed credentials in supported connected sources, verify supported credential types with their issuers, show available AWS access-key or GCP API-key context, and assign response work. It does not identify malicious npm package installation, reconstruct every file a payload read, prove exfiltration, or rotate every issuer credential automatically. Keep package and endpoint evidence with the incident owner, and use credential findings to guide issuer-side checks.
What changed after the incident?
Nx says it removed the malicious releases, revoked npm publishing tokens, required more review for release and outside-contributor workflows, and adopted npm Trusted Publishers. The general lesson is a specific boundary: untrusted PR text reached privileged workflow code, a writable repository token reached a publishing job, and a long-lived npm token enabled publication. Review each boundary in your own release process without assuming a generic secret scanner would have blocked the package.
Related Cremit guides
Secret scanning: what a finding can and cannot establish
OWASP NHI5: reviewing excessive machine permissions
Primary sources
Nx — GHSA-cxm3-wv7p-598c security advisory and timeline
Read next
The machine access behind an exposed API key
An exposed key is a lead. Connect it to its issuer, principal, permissions, workload, and owner before closing the access path.
When the Security Scanner Became the Weapon: A Cyber Kill Chain Analysis of the Trivy Supply Chain Attack
Aqua Security's Trivy was compromised by TeamPCP, cascading into LiteLLM. A 7-phase Cyber Kill Chain and MITRE ATT&CK analysis of how incomplete credential rotation turned a single breach into a five-ecosystem catastrophe.
Deleted file, active credential: investigating a Zombie Key
Source removal does not revoke a credential. Check the issuer, Git history, current owner, and last verification before closing the finding.
Get the next one in your inbox
Monthly NHI security brief from Cremit. One email, high signal.