TL;DR: The s1ngularity attack on Nx used malicious npm packages to steal developer secrets, then abused installed AI tools to exfiltrate them into public GitHub repositories, showing how supply chain compromise now reaches the developer identity layer, according to Orca Security. Access review processes assume secrets persist long enough to be reviewed; in this case, exfiltration happened before defenders could even see the full blast radius.
At a glance
What this is: This is Orca Security’s analysis of the Nx s1ngularity supply chain attack, which paired malicious npm packages with AI tool abuse to steal developer secrets and publish them to GitHub.
Why it matters: It matters because supply chain compromise now reaches developer identities, secrets, and AI-assisted workflows, which changes how IAM, NHI, and pipeline controls have to be scoped.
By the numbers:
- 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
Context
Supply chain compromise in this case is not limited to a poisoned dependency. The attack reached developer endpoints, harvested credentials and keys, and then used installed AI tools to help move stolen data into public repositories, which makes the developer workstation part of the identity attack surface.
For identity programmes, the important shift is that the compromise path crossed package integrity, developer secrets, and tool abuse in one chain. That means controls built only around production workloads miss the point: the risk sits earlier, where developers, credentials, and automation intersect.
This is atypical only in technique, not in direction. Attackers have been moving steadily toward the software supply chain for years; what changes here is the explicit use of AI tooling as an exfiltration channel.
Key questions
Q: What breaks when a supply chain compromise can read local developer secrets?
A: The trust model breaks because local secrets become attacker-controlled identity material before defenders can respond. If package installs, extensions, or assistant tooling can read tokens and environment variables, the compromise jumps from code execution to account abuse. Security teams need to assume that any readable secret on an affected workstation may already be reusable elsewhere.
Q: Why do developer secrets make supply chain incidents much harder to contain?
A: Because developer secrets often act like non-human identities with broad runtime reach. If the same token can publish code, access cloud services, or trigger automation, one compromise can spread across multiple systems without needing a new exploit. Containment becomes difficult when credential scope is wider than the code path that exposed it.
Q: How do security teams know whether AI tooling is creating extra exfiltration risk?
A: Look for permissive command-line modes, unexpected repository creation, and data movement patterns that do not match normal developer behaviour. If the tool can bypass permissions or relay secrets to external destinations, it should be treated as a governed exfiltration path rather than a harmless productivity aid.
Q: Should organisations treat developer endpoints as production assets?
A: Yes, when those endpoints can access source control, cloud accounts, or pipeline credentials. The compromise path in this incident shows that the workstation can be the first production-adjacent trust zone attackers abuse, so monitoring, secret handling, and containment need to match that role.
Technical breakdown
Malicious npm packages as the initial entry point
The attack began with malicious versions of Nx packages published to npm, then executed a post-install script on developer machines. That script ran as part of normal package installation, which is why supply chain attacks are so effective: the user trusts the package and the package inherits that trust at install time. Once execution started, the script enumerated local environment material and searched for secrets across developer endpoints. The key issue is not just code tampering, but trust transfer through dependency installation, where a benign-looking update becomes an execution vehicle.
Practical implication: treat package install as an execution event, not a passive download, and inspect post-install behaviour in dependency controls.
Credential harvesting from developer environments
The script collected GitHub tokens, SSH keys, npm credentials, and other sensitive assets from developer systems, including Linux and macOS endpoints. That makes the incident a credential-access problem as much as a package problem, because the compromise value came from the secrets resident on the workstation. The attack also touched VS Code extensions and CI/CD pipelines, showing how developer identity material can bridge into build and delivery systems. In other words, the package was only the foothold; the real prize was the reusable trust material sitting next to the code.
Practical implication: classify developer machines, editors, and pipeline runners as secret-bearing systems and monitor them accordingly.
AI tool abuse turned secret theft into public exfiltration
The attackers leveraged installed AI tools with permissive command-line flags such as --dangerously-skip-permissions, --yolo, and --trust-all-tools to push harvested data into public GitHub repositories. That matters because the exfiltration path was no longer a simple file upload or clipboard leak. It was mediated by tools that developers already use to accelerate work, which makes weak default permissions part of the attack surface. Double- and triple-base64 encoding was then used to obscure the data in transit, while public repositories provided durable exposure.
Practical implication: restrict permissive AI tool modes and watch for repository creation or unusual tool-mediated data movement from developer endpoints.
Threat narrative
Attacker objective: The attackers aimed to steal reusable developer secrets and turn them into publicly accessible compromise material that could be reused for further cloud, source-control, or pipeline access.
- Entry occurred when attackers published malicious npm package versions that executed a post-install script on installation.
- Credential access followed as the script harvested GitHub tokens, SSH keys, npm credentials, and other local secrets from developer systems.
- Exfiltration escalated when AI developer tools were abused to move the stolen material into public GitHub repositories.
- Impact was broad exposure of developer secrets, with attackers able to act on the stolen credentials before defenders could respond.
Breaches seen in the wild
- tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).
- Nx s1ngularity attack 2025: Attackers stole Nx's npm token via a GitHub Actions flaw and shipped malware that stole 2,349 secrets and abused developers' AI CLIs.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Supply chain attacks now have to be governed as identity attacks. This incident was not only about poisoned packages. It was about reaching the identity material that lives around development workstations, including tokens, SSH keys, and automation credentials. The practical conclusion is that software supply chain controls and identity governance can no longer be treated as separate programmes.
Developer tool trust has become an exfiltration control problem. The attackers did not need to break encryption or defeat a hardened production perimeter once they reached the workstation. They used AI tools and permissive flags as a data movement layer, which means developer tooling policy now sits inside the trust boundary. Practitioners need to review where tool defaults permit silent permission bypass.
Secret exposure windows are now shorter than many response cycles. Orca Security’s cited research says exposed secrets on GitHub are often discovered by attackers in under 2 minutes. That makes detection after publication too late for many cases. The governance implication is that the blast radius is decided at the moment of install and first execution, not at the moment of later review.
Ephemeral review cannot govern secrets that are exfiltrated before review begins. Access review processes were designed for privileges that persist long enough to be recertified. This attack shows that developer secrets can be harvested, repurposed, and exposed before any certification cycle sees them. The implication is that the control assumption, not just the control coverage, has broken.
Build pipelines inherit workstation compromise faster than most teams model. The article’s emphasis on CI/CD, developer machines, and source control shows the lateral path from local compromise into pipeline and cloud access. That makes developer endpoints a primary NHI governance concern, not a secondary IT hygiene issue. Teams should treat developer-held secrets as production-grade trust material.
From our research library:
- The blast radius of the Salesloft-Drift OAuth supply chain attack was 10 times greater than earlier incidents in which attackers breached Salesforce directly.
- Read next: Guide to the Secret Sprawl Challenge
What this signals
Identity governance has moved upstream into the developer workflow. Secrets, tokens, and repository trust now sit inside the supply chain path, which means IAM and NHI teams have to think about package install, editor plugins, and AI tool defaults as part of the same control surface.
AI-assisted development changes the shape of blast radius: when a tool can be coerced into moving harvested material, the control question is no longer only who has access, but which local tools can relay that access outside the intended boundary.
The practical takeaway for programme owners is to tighten the boundary around developer endpoints, because once secrets leave the machine there is often no meaningful recovery window left.
For practitioners
- Audit developer-held secret paths Map where GitHub tokens, SSH keys, npm credentials, and wallet material reside on developer endpoints, then classify those systems as secret-bearing assets.
- Restrict permissive AI tool modes Block or alert on flags that bypass tool permissions, especially on machines that can access source code, repositories, or credentials.
- Harden package-install monitoring Detect post-install scripts, unexpected repository creation, and unusual outbound movement from dependency installation events.
- Rotate exposed credentials immediately Assume any token, key, or npm credential on an affected workstation may have been copied and is no longer trustworthy.
- Review developer workstation blast radius Treat endpoints used for coding, editing, and pipeline interaction as part of the production trust boundary and monitor them with that assumption.
Key takeaways
- The attack shows that supply chain compromise can become identity compromise when developer secrets are present on the endpoint.
- The exposed-secrets window is extremely short, which makes post-exposure review insufficient as a primary control.
- Teams should treat developer machines, package installation, and AI tool defaults as governed parts of the trust boundary.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The attack harvested and exposed developer secrets from infected endpoints. |
| NHI-10 — Human Use of NHI | Developers' use of machine credentials and tools was central to the compromise path. | |
| Recommendation — Scan developer environments for exposed secrets and revoke any leaked credentials immediately. Separate human workflows from machine credentials and restrict secret handling on developer endpoints. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Stolen tokens and credentials enabled unauthorized reuse of trusted access. |
| Recommendation — Treat stolen tokens as authentication failures and rotate any credentials that can still authenticate. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The attack chain combined secret harvesting with public data theft. |
| Recommendation — Map the incident to credential-access and exfiltration techniques to improve detection coverage. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The incident depended on leaked authenticators remaining valid after theft. |
| Recommendation — Apply authenticator lifecycle controls so stolen developer credentials can be revoked quickly. | ||
Key terms
- Developer Secret: A developer secret is a credential used to access code, services, or infrastructure, such as an API key, SSH key, token, or certificate. In practice, it becomes an identity artifact when it can authorize action, not just authenticate a person. Its risk lies in spread, reuse, and weak revocation.
- Supply Chain Exfiltration: The movement of stolen data through a trusted software or development path rather than a classic malware upload channel. In this pattern, the attacker abuses the build, package, or developer tool chain to carry secrets out of the environment while blending into normal workflow traffic.
- Permissive AI Tool Mode: An operating state in which an AI development tool is allowed to bypass or weaken permission checks, often through command-line flags or trust settings. This matters because the tool can become a conduit for data movement or secret disclosure when its safeguards are disabled or ignored.
- Post-install script abuse: Post-install script abuse happens when malicious code runs automatically during package installation and performs actions before a developer can inspect the package. It is dangerous because the install step itself becomes the execution path, letting attackers harvest data or alter the system immediately.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 11, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org