Nx Supply Chain Attack Exposes Thousands of Developer Credentials on Github - What you should do to keep your organization secure

TL;DR

If your organization used Nx packages between August 24-27, 2025, immediately rotate all credentials (API keys, cloud access, tokens) from affected developer machines. The malware exfiltrated secrets to public GitHub repos. Even if you don't use Nx, the leaked credentials from other orgs create cascading supply chain risks. Disable postinstall scripts and never store credentials in local config files.

August 2025 marked a watershed moment in supply chain security when malicious actors compromised popular Nx packages on npm, potentially affecting millions of developers worldwide. Here's what your organization needs to know and do right now.

The Attack Timeline: How It Unfolded

On August 27, 2025, the developer community discovered that several widely-used Nx packages had been compromised through a supply chain attack. The malicious code, hidden within legitimate-looking updates, executed automatically during package installation, silently harvesting sensitive data from developer machines.

The attack vector was particularly insidious: threat actors gained unauthorized access to npm publishing credentials, allowing them to push malicious versions of trusted packages, including:

• Nx build system npm package (@nrwl/nx, nx) in the following versions: 20.9.0, 20.10.0, 20.11.0, 20.12.0, 21.5.0, 21.6.0, 21.7.0, 21.8.0
• @nx/devkit in versions: 21.5.0, 20.9.0
• @nx/enterprise-cloud version 3.2.0
• @nx/eslint version 21.5.0
• @nx/js in versions: 21.5.0, 20.9.0
• @nx/key version 3.2.0
• @nx/node in versions 21.5.0, 20.9.0
• @nx/workspace in versions 21.5.0, 20.9.0

The Technical Breakdown: Understanding the Threat

The attack operated through a two stage mechanism:

Stage 1: Initial Compromise

Attackers compromised the Nx build system's npm publishing key, enabling them to push malicious versions of this widely-used package to the npm registry. The compromised versions contained sophisticated post-installation malware that harvested sensitive developer assets including cryptocurrency wallets, GitHub and npm tokens, and SSH keys. In a particularly innovative attack technique, the malware weaponized AI command-line tools (including Claude, Gemini, and Q) to enhance reconnaissance capabilities on infected systems.

Stage 2: Data Exfiltration

Once activated on developer's local machines or CI/CD pipelines, the malware systematically searched for and exfiltrated:

• Environment variables containing API keys and tokens
• Shell configuration files (.bashrc, .zshrc, .profile)
• Cloud provider credentials (AWS, Azure, GCP)
• Version control tokens (GitHub, GitLab, Bitbucket)
• CI/CD pipeline secrets
• Database connection strings
• OAuth tokens and refresh tokens

The stolen data was then published to public GitHub repositories named s1ngularity-repository, s1ngularity-repository-0, or s1ngularity-repository-1. This made thousands of API keys, tokens, and passwords openly available, amplifying the risk of misuse across the wider software ecosystem.

The Blast Radius: Assessing Your Exposure

This attack's impact extends far beyond individual developers. Consider this sobering reality: if even one developer in your organization installed these compromised packages, your entire infrastructure could be at risk.

Risk 1: Direct Exposure for Nx Users

Your sensitive information (API tokens, database credentials, cloud access keys) may now be publicly exposed. Attackers could already be accessing your infrastructure, exfiltrating customer data, or preparing for ransomware deployment.

Critical Remediation Steps:

• Immediately rotate ALL credentials that were present on any developer machine between August 24-27, 2025
• Audit access logs for unusual activity during this period
• Update Nx packages to verified clean versions
• Clear npm cache: npm cache clean --force
• Enable multi-factor authentication on all critical systems

Risk 2: Universal Threat Regardless of Nx Usage

The massive cache of stolen credentials creates a domino effect. Compromised keys from other organizations could grant attackers access to packages and services your company depends on. This exponentially increases the risk of cascading supply chain attacks in the coming weeks.

Advanced Protection Measures:

• Implement strict allowlisting for package postinstall scripts. If using pnpm, add this to your .npmrc (by default on pnpm >= 10):

1enable-pre-post-scripts=false

Then explicitly allowlist trusted packages:

1{
2  "pnpm": {
3    "allowedDeprecatedVersions": {},
4    "onlyBuiltDependencies": ["package-name"]
5  }
6}

• Never store credentials in local configuration files. Instead, leverage password manager CLIs for dynamic credential injection. You can also use keychain ssh agent to store and use safety your ssh keys.
• For example, with 1Password, In your .zshrc or .bashrc

1export GITHUB_TOKEN=$(op read op://personal/github-account/token)
2export AWS_ACCESS_KEY=$(op read op://aws/production/access-key)

Practical Security Checklist

Within 24 Hours

• Scan for compromised Nx packages
• Rotate exposed credentials
• Review authentication logs

Within 72 Hours

• Enable package vulnerability scanning in CI/CD
• Configure automated alerts for advisories
• Verify package integrity using npm audit signatures

Longer-term

• Adopt dependency pinning, lock file verification and ****strict allowlisting for package postinstall scripts
• Leverage secrets management (e.g., Vault, 1Password CLI) cli in your local files
• Strengthen developer environments with least privilege and monitoring

Building Resilience

This incident highlights the growing importance of supply chain security. Traditional defences are not enough when attacks target trusted tools. Strengthening development environments, enforcing dependency policies, and improving credential management will reduce future risk. Isolating development work in sandboxed environments can provide an additional layer of protection by containing potential compromises and preventing attackers from accessing production systems or sensitive credentials.

For organizations pursuing compliance certifications, supply chain security is a critical component. Both SOC 2 and ISO 27001 require organizations to implement vendor risk management and secure development practices.

Conclusion

This Nx supply chain attack serves as a stark reminder that our interconnected development ecosystem remains vulnerable to sophisticated threats. Traditional security perimeters are insufficient when attackers successfully compromise the very tools we trust most.

Moving forward, organizations must strengthen their development environments through comprehensive dependency policies, robust credential management practices, and proactive threat monitoring. Isolating development work in sandboxed environments can provide critical containment, preventing compromised packages from accessing production systems or sensitive credentials.

Given that this pattern mirrors recent incidents, including the eslint-config-prettier compromise just two months earlier, and that leaked npm credentials may enable further package compromises, organizations should prepare for this threat landscape to intensify rather than diminish.

The path to resilience requires treating supply chain security not as an afterthought, but as a foundational element of modern software development. Implementing robust incident response procedures and maintaining compliance with security frameworks helps organizations respond effectively when breaches occur.