TL;DR: A poisoned Nx Console extension, live for just 18 minutes, helped TeamPCP harvest developer credentials and clone roughly 3,800 GitHub repositories, according to ArmorCode's analysis. The breach shows that the real control gap is the ungoverned developer workstation and its credential footprint, not committed code or pipeline security alone.
At a glance
What this is: This analysis traces how a poisoned VS Code extension became a developer supply chain breach that let attackers harvest credentials and clone about 3,800 internal repositories.
Why it matters: It matters because AppSec and IAM teams have to govern developer endpoints, extension updates, and credential sprawl, not just committed code and running pipelines.
By the numbers:
- The malicious Nx Console extension stayed live for 18 minutes before removal.
- GitHub confirmed approximately 3,800 internal repositories were exfiltrated.
Context
The breach shows that software supply chain risk now begins before code is committed. A trusted developer workstation can hold GitHub tokens, SSH keys, cloud credentials, and AI tool configurations, so a poisoned extension can convert local trust into organisation-wide access.
For IAM and security teams, the key failure is not only malicious code distribution but the absence of governance over the developer endpoint as an identity-bearing control plane. When extension auto-update, flat repository access, and unmanaged secrets converge, existing application security tooling only sees the problem after the credentials have already been used.
Key questions
Q: What fails when a poisoned IDE extension can read developer credentials?
A: The failure is trust inheritance. When an extension is allowed to execute in a normal developer context, it can search local files, environment variables, vaults, and AI tooling configs without raising privilege alarms. That turns a software update event into a credential collection event, which is why endpoint-level governance matters as much as code review.
Q: Why do compromised developer credentials create such a large blast radius?
A: Because developer accounts often carry access to source repositories, CI/CD tokens, cloud keys, and internal services at the same time. If repository permissions are broad or flat, one stolen identity can enumerate and clone far more than the legitimate user should need. The issue is entitlement design, not just theft detection.
Q: What are the signs that a development environment may be under supply chain attack?
A: Common warning signs include unusual connections to uncommon ports, persistent remote desktop sessions, repeated contact with suspicious proxies or VPN exits, and unexpected exfiltration of credentials or system information. Security teams should also watch for software updates that alter trusted tools without a clear administrative reason, because supply chain attacks often hide inside normal-looking operational activity.
Q: What should teams do when exposed credentials are found in a public repository?
A: Treat the repository as an entry point, not the whole incident. Revoke the exposed credential, trace every service and role it could access, and look for adjacent secrets stored in exports, configs, and workstation files. Containment has to follow the privilege graph, not just the leak location.
Technical breakdown
How a trusted extension becomes a delivery channel
A malicious VS Code extension works because extension ecosystems are treated as trusted distribution channels. Once a publisher account or upstream dependency is compromised, auto-update pushes the altered package to every installed endpoint without a separate review gate. In this case, the extension was able to run code during post-install, which means the threat executes in the same context as normal developer activity. That makes the extension itself a high-trust delivery mechanism, not just a plugin with malicious payload. The architectural weakness is that endpoint trust is inherited from the software marketplace, while the security model still assumes packages are safe until runtime detection says otherwise.
Practical implication: treat IDE extensions as governed software supply chain inputs and control auto-update at the endpoint layer.
Why local credential harvesting beats pipeline-centric controls
The attack is effective because the developer workstation already contains the credentials that matter. A single laptop may expose GitHub tokens, SSH keys, cloud credentials, and password vault access, which means compromise of the endpoint collapses multiple control domains at once. Tooling focused on SAST, DAST, SCA, or even CSPM does not see the credential acquisition step because those tools operate on code, build artefacts, or cloud posture, not the local machine state. The post-install script can therefore search files, environment variables, and vault integrations while appearing like ordinary developer tooling, especially when it avoids privilege escalation and uses normal user permissions.
Practical implication: extend monitoring and secret-scanning controls to developer endpoints, not just repositories and pipelines.
Why flat repository access turns one stolen key into mass exfiltration
Once the attacker has a valid GitHub token or SSH key, the permission model determines the blast radius. Flat read access across repositories means one compromised credential can enumerate and clone large parts of the internal code estate without tripping obvious authorization failures. This is an identity and access design issue, not just an incident response issue. The problem is compounded when repository entitlements are broad, long-lived, and detached from team or project need. In that model, access inheritance works in the attacker’s favour because the stolen identity is already entitled to far more than its legitimate user should need.
Practical implication: reduce repository blast radius with team-scoped access and credential-specific entitlement reviews.
Threat narrative
Attacker objective: The objective was to harvest developer credentials and use them to exfiltrate internal source code and expand access across the software supply chain.
- Entry occurred when attackers poisoned the Nx Console extension and distributed it through the Visual Studio Marketplace.
- Credential harvesting happened on affected developer machines as the post-install script collected vault data, GitHub tokens, SSH keys, AWS credentials, and AI configuration material.
- Escalation followed when those stolen credentials were used to clone GitHub’s internal repositories at scale.
- Impact was the exfiltration of approximately 3,800 internal repositories and a wider demonstration that developer endpoints can be used as a supply chain pivot point.
Breaches seen in the wild
- Checkmarx KICS supply chain attack 2026: Credentials stolen via Trivy let attackers poison Checkmarx KICS Docker images, VS Code extensions and Actions to steal developer secrets.
- GitHub internal repositories breach 2026: A stolen GitHub CLI token let attackers publish a poisoned Nx Console extension that harvested secrets and exfiltrated 3,800 GitHub repos.
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
Developer workstations have become the real identity perimeter. The breach shows that the most sensitive access is often held locally on endpoints, not only in central IAM systems. When a workstation contains tokens, keys, and vault access, it functions as a distributed control plane whose compromise invalidates assumptions made by pipeline-only security. Practitioners should treat the developer endpoint as part of identity governance, not as a separate hygiene problem.
The most dangerous gap is not code execution, but credential inheritance from trusted tooling. This attack worked because a marketplace extension could inherit enough trust to run in the developer context and search for secrets without needing elevated privileges. That is a governance failure around software provenance, extension lifecycle, and credential scope. Security teams need to recognise that trusted tools can become privileged execution paths before any traditional malware signal appears.
Flat repository access creates an unnecessary blast-radius multiplier. When every developer can read everything, stolen credentials become a mass-exfiltration event instead of a contained incident. This is the same underlying weakness that makes identity sprawl so difficult to govern: access is broad, persistent, and poorly tied to actual need. The practical conclusion is simple, access scope must be engineered for compromise resilience, not convenience.
Before-code governance is now part of application security governance. Traditional AppSec programmes are still optimised for committed code, running pipelines, and cloud posture after deployment. The breach shows that the highest-risk decisions often happen earlier, inside local tools, extensions, and credential stores that never enter the central review path. Organisations that do not include the developer workstation in their security boundary will keep discovering this class of incident too late.
From our research library:
- Internal repositories are 6x more likely to contain secrets than public ones (32.2% vs 5.6%), contradicting the assumption that private repos are safe, according to the State of Secrets Sprawl 2026.
- Read next: CI/CD Pipeline Identity Security Guide
What this signals
Developer endpoint governance is now part of identity governance. The breach shows that teams cannot separate workstation control from access control when the machine itself holds reusable credentials. Organisations need a governance model that treats extension installs, local vaults, and repo entitlements as one risk surface, not three disconnected ones.
Secret sprawl becomes more dangerous when it lands on developer machines. Internal repositories are 6x more likely to contain secrets than public ones (32.2% vs 5.6%), contradicting the assumption that private repos are safe, according to the State of Secrets Sprawl 2026. That matters here because the attacker only needed one compromised workstation to reach material credentials and then move into internal code access.
Before-code controls will become a board-level AppSec issue. Security programmes that stop at committed code will keep missing the point of entry for this attack class. The control conversation has to shift toward endpoint telemetry, extension governance, and repository entitlements that assume a developer machine can be the initial breach point.
For practitioners
- Tighten extension update governance Disable or centrally control VS Code extension auto-updates through endpoint management so developers cannot install a malicious version the moment it is published.
- Inventory developer-side secrets and keys Build an endpoint view of GitHub tokens, SSH keys, vault access, and cloud credentials that exist on developer machines, then revoke anything that should not be present.
- Reduce repository blast radius Replace flat read access with team- and project-scoped repository permissions so one stolen token cannot expose the entire internal code estate.
- Monitor package and extension ecosystems together Correlate package risk signals with IDE extension activity because the attack surface now spans both dependency installs and developer tooling.
- Add endpoint telemetry to AppSec response Use workstation visibility to answer which developers had a suspicious extension installed, which keys were active, and which repos those keys could reach.
Key takeaways
- A poisoned extension can turn a trusted developer workstation into a credential harvesting platform before any code is committed.
- The GitHub incident exposed a control gap in endpoint governance, secret sprawl, and flat repository access rather than a novel exploit chain.
- Limiting extension auto-updates, scoping repository access, and revoking exposed keys are the controls that shrink the blast radius of this attack pattern.
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 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The breach harvested secrets from developer machines and vaults, making leakage the core failure mode. |
| NHI-05 — Overprivileged NHI | Broad repository and credential scope let one stolen identity reach far more code than necessary. | |
| NHI-07 — Long-Lived Secrets | The attack depended on reusable tokens and keys present on developer machines long enough to be stolen. | |
| Recommendation — Scan developer endpoints and extension ecosystems for exposed secrets, then revoke anything harvested from the workstation. Reduce NHI and repository privilege scope so a single stolen credential cannot access the full code estate. Shorten the lifetime of developer-access secrets and remove persistent credentials from endpoints. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The attack chain centered on credential harvesting followed by data theft from internal repositories. |
| Recommendation — Map workstation-based credential theft and repository cloning to TA0006 and TA0010 in detection and hunting. | ||
| CIS Controls v8 | CIS-5 — Account Management | Repository access and credential scope are account governance problems as much as malware problems. |
| Recommendation — Apply account management control to scope repository access and remove standing access that exceeds need. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The incident exposed weaknesses in how tokens, SSH keys, and other authenticators were stored and used. |
| Recommendation — Use authenticator management to rotate, revoke, and constrain developer credentials exposed on endpoints. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The flat repository model shows a direct failure in permissions and entitlement governance. |
| Recommendation — Review entitlements so repository access is explicitly limited to team and project need. | ||
Key terms
- Developer Endpoint: A developer endpoint is a laptop or workstation used to write code, run tools, and access build or cloud systems. In identity governance terms, it is also a place where live credentials can be stored, copied, or exposed, which makes the device part of the control surface rather than just a user asset.
- Before-Code Environment: The local development space where code, extensions, package tools, configs, and secrets exist before anything is committed or deployed. This environment often escapes traditional AppSec visibility, which means the earliest compromise can happen before code scanning or pipeline controls ever see it.
- Credential Footprint: The collection of tokens, keys, passwords, and vault access that a device or identity can reach. A large credential footprint increases the value of one compromise because attackers can pivot from a single endpoint into repositories, cloud services, and internal systems.
- Extension Trust Chain: The set of assumptions that allows software extensions to execute code on a user device after publication. When that trust chain is compromised, auto-update and post-install behaviour can be abused to deliver malicious actions through a normally trusted software channel.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle control. It helps practitioners connect identity governance to the broader security programme their teams actually run.
Published by the NHIMG editorial team on August 19, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org