GitHub Breach via Nx Console: How a Poisoned VS Code Extension Stole 3,800 Internal Repos
By ScruteX Team Published
For 18 minutes on May 18, 2026, a poisoned version of the Nx Console VS Code extension sat live on the Visual Studio Marketplace with a verified publisher badge. By the time it was pulled, the attacker had reached a GitHub employee's laptop and started copying 3,800 internal repositories. This is the cleanest case study to date of why developer endpoints are now the highest-value entry point in software supply chain attacks.
Quick answer: The 2026 GitHub breach was caused by a malicious version 18.95.0 of the Nx Console VS Code extension. Attackers stole a maintainer's GitHub token, used it to publish a release containing 2,777 bytes of obfuscated JavaScript that read .env files, cloud credentials, and browser session tokens. The extension auto-updated to roughly 2.2 million developer machines, including one belonging to a privileged GitHub employee. From that machine, the threat actor TeamPCP (tracked as UNC6780) exfiltrated about 3,800 GitHub-internal repositories and listed them for sale at $50,000, later raised to $95,000 alongside the Lapsus$ extortion crew. GitHub's CISO Alexis Wales confirmed customer organisations and user repositories were not affected.
What Happened: The Nx Console VS Code Extension Compromise
Nx Console is a popular VS Code extension for the Nx monorepo build system. It carries verified publisher status on the Visual Studio Marketplace and around 2.2 million active installs. On May 18, 2026, between 12:30 and 12:48 UTC, version 18.95.0 of the extension was published with a malicious payload. The same release sat on the Open VSX marketplace for 36 minutes before community responders pulled it.
The extension behaved normally on the surface. A 2,777-byte snippet of obfuscated JavaScript inside a minified file did the work. From the moment a developer opened any workspace in VS Code, the code began reading local .env files, harvesting cloud provider keys, exfiltrating CI/CD pipeline secrets, copying password manager exports, and grabbing tokens for AI coding assistants. On macOS, it dropped a Python backdoor at
/Users/%/.local/share/kitty/cat.py for persistence. One of the developers who auto-updated to 18.95.0 worked at GitHub. The credentials and session tokens harvested from that single endpoint gave the attacker access to roughly 3,800 GitHub-internal repositories. GitHub detected the unauthorised access on May 19, 2026, isolated the affected device, removed the extension, and rotated high-impact credentials. The public disclosure followed on May 20, 2026 via GitHub's Security Blog and official communications.
Who Is TeamPCP (UNC6780) and What Did They Steal?
TeamPCP is a cybercrime group that has been active across 2026, tracked under the threat intelligence designation UNC6780. The group specialises in compromising the developer-facing software supply chain. Their pattern is consistent: steal a contributor or maintainer token from one project, push a poisoned release in another, and let auto-update mechanisms do the distribution.
In the GitHub incident, TeamPCP listed roughly 3,800 internal GitHub repositories for sale on dark web forums. The opening price was $50,000. A follow-up listing raised it to $95,000 and named the Lapsus$ extortion crew as a partner. The group has publicly framed the activity as a data sale rather than an extortion of GitHub directly.
The stolen archive is limited to GitHub-internal source code repositories. GitHub's CISO Alexis Wales has stated there is no evidence of impact to customer organisations, enterprises, or user repositories. Some internal repositories contain customer-related content such as excerpts of support interactions, and GitHub has committed to notifying affected customers via established channels if the investigation finds anything new.
How the Attack Worked: Anatomy of a Developer Supply Chain Breach
The breach chain involved five steps, each one mundane on its own.
Step 1: Stolen maintainer token. A contributor's GitHub token was compromised during an earlier supply chain incident in the broader developer ecosystem. The token still carried publishing privileges and had not been rotated.
Step 2: Orphan commit and malicious release. The attacker used the stolen token to push an orphan commit to the project, build a release with a malicious payload, and publish version 18.95.0 to both the Visual Studio Marketplace and Open VSX. Marketplace review systems did not flag the release. Verified publisher status carried it through.
Step 3: Credential harvesting payload. A 2,777-byte obfuscated JavaScript snippet was injected into a minified file inside the extension. It read local secrets the moment any workspace opened in VS Code: .env files, browser-stored sessions, cloud provider keys, CI/CD tokens, password manager exports, and AI coding assistant credentials.
Step 4: Auto-update distribution. Developers with auto-update enabled pulled the malicious version within minutes of publication. The community caught and removed the extension after 18 minutes on Visual Studio Marketplace and 36 minutes on Open VSX. The window was already enough to reach millions of machines, including the GitHub employee's laptop.
Step 5: Pivot to internal repos. With the harvested GitHub session token from that one privileged machine, the attacker reached and copied approximately 3,800 GitHub-internal repositories. No persistence beyond the developer endpoint was required. The credentials themselves were the prize.
Why VS Code Extensions Bypass EDR and Endpoint Security
Most enterprise security spending sits on the perimeter, the endpoint, and the cloud. Developer workstations get covered by the same EDR agents as every other laptop. That coverage is not enough, and the reason is worth understanding.
EDR is built around compiled binaries. It watches process trees, file system writes, network connections, and known malware signatures. A 2,777-byte JavaScript snippet inside an interpreted runtime, doing things every developer does dozens of times a day (reading .env files, calling out to package registries, opening sockets to localhost), does not match any signature. There is nothing for binary-focused detection to catch.
VS Code extensions, npm packages, PyPI distributions, and JetBrains plugins all sit on a layer of the supply chain that traditional endpoint tooling was not designed to inspect. They are plain-text, interpreted artifacts that execute inside trusted applications. They have automatic update mechanisms. They are not signed in any way the operating system enforces. The result is a category of attack that is invisible to most existing controls.
Traditional vs Developer-Tooling Supply Chain Attacks
| Dimension | Traditional Supply Chain Attack | Developer-Tooling Supply Chain Attack |
|---|---|---|
| Entry point | A library deep in the dependency tree | An extension or CLI on the developer's machine |
| Time to weaponise | Days to weeks after publication | Minutes |
| Visibility to EDR | Low (interpreted code) | Effectively none |
| Detection mechanism | SBOM scanning, dependency review | Marketplace monitoring, package age policy |
| Privilege gained | Application-level | Full developer workstation context, tokens, SSO sessions |
| Typical blast radius | Apps that consume the library | Every repository, cloud account, and pipeline the developer can reach |
The Nx Console incident sits firmly in the right column. The 2,777-byte payload was invisible to binary scanners. The 18-minute live window was shorter than most SBOM refresh cycles. The privilege gained was every internal repository the GitHub employee could read.
The 2026 Pattern: Token Theft, Verified Publishers, Auto-Updates
Across 2026, the same threat actor has compromised security tools used by developers, popular CLI utilities, and IDE plugins. Each attack relied on the same four conditions:
- Verified publisher status as a trust shortcut. Developers and IT teams treat verified badges as a proxy for safety. Marketplaces verify identity, not the behaviour of any individual release. A verified account can publish anything.
- Auto-update as a distribution channel. Every workstation with auto-updates enabled becomes an instant distribution point for the attacker. Detection within minutes is no longer fast enough.
- Plain-text payloads inside trusted runtimes. Interpreted code in JavaScript, Python, or shell, executing inside applications the OS has already authorised, slips past binary-focused defence.
- Credentials over malware. The goal is to read what is already on the disk. Tokens, .env files, browser-stored sessions, password manager exports. No persistent backdoor is needed when the credentials themselves are the prize.
This is the operating model defenders should plan against. Single-incident response will not contain it.
What Security Teams Should Do This Week
If your team has not yet had a serious conversation about developer tooling supply chain risk, this is the incident to anchor it. Below is what to do, in order.
1. Inventory every IDE extension your developers use. Most security teams cannot answer the question "what VS Code extensions are running on our engineering laptops." If you do not know, you cannot scope risk. A simple endpoint script enumerating installed extensions is enough to start. JetBrains plugins and developer CLI tools count too.
2. Apply a minimum-age policy to extensions and packages. Any extension, npm package, or PyPI release published within the last 24 to 72 hours should be blocked from installation on engineering workstations. The Nx Console attack was caught in 18 minutes. A 48-hour delay would have prevented the breach entirely.
3. Move publishing tokens off long-lived secrets. The root cause was a stolen maintainer token. Internal projects that publish anywhere (a registry, an extension marketplace, a public package index) should use short-lived, OIDC-issued tokens scoped to a single workflow, not personal access tokens with broad write privileges.
4. Treat developer endpoints as privileged endpoints. A developer laptop holds source code access, cloud credentials, and CI/CD tokens. It is functionally a domain controller for engineering. Apply the same controls you apply to admin workstations: separate hardware, monitored network egress, application allow-listing where feasible.
5. Rotate the credentials a malicious extension would have read. Assume the extensions your developers ran last month had something nasty in them. Force a rotation of cloud keys, CI/CD service accounts, password manager session tokens, and AI coding assistant credentials. Audit for sessions still live beyond the rotation cut-off.
6. Add marketplace monitoring to your threat intel feed. Whichever exposure management or digital risk protection service your team uses, ask for coverage of the VS Code Marketplace, Open VSX, npm, PyPI, and JetBrains. If it does not cover those today, that is the gap.
How This Maps to Compliance Frameworks
The compliance frameworks have started to catch up, but most still describe supply chain risk in terms suited to libraries and components rather than developer workstations.
NIS2 (EU): Article 21 requires entities to manage cybersecurity risks across the supply chain, including direct suppliers and the security of network and information systems. Member-state implementations are increasingly being read to include developer tooling and software publishing pipelines.
DORA (EU financial services): Articles 28 to 30 explicitly cover ICT third-party service providers. The interpretation that marketplaces hosting extensions used to write critical financial applications fall within scope is gaining ground among supervisors.
NIST CSF 2.0: The Supply Chain Risk Management category (GV.SC) and the Asset Management category (ID.AM) together expect organisations to know what software runs in their environment, including developer tools, and to manage the risks those tools introduce.
ISO 27001:2022: Annex A control 5.21 (information security in the ICT supply chain) and 8.30 (outsourced development) point at the dependencies and tooling used to build software, not just the software itself.
SEC cybersecurity disclosure rule (2023): A confirmed exfiltration of internal source code, customer-related data, or trade secrets through a developer endpoint is a candidate for Item 1.05 disclosure on a four-business-day clock. Speed of detection determines whether you can meet that clock.
The consistent takeaway: auditors who used to ask about SBOMs are now asking about the controls on the machines where developers actually write code. If the answer is "EDR plus device management," expect follow-up questions.
Common Mistakes Security Teams Make
The same misjudgements show up in every postmortem of this category of incident.
Assuming a verified publisher badge is a security control. It is not. It verifies identity, not the safety of any individual release. A verified publisher who loses a token publishes verified malware. Treat the badge as a starting point, not an endpoint.
Relying on EDR to catch what runs inside an IDE. EDR is built to detect malicious processes and known signatures. A few kilobytes of interpreted code calling system APIs the application is already allowed to call is invisible to it. If your gap analysis claims EDR covers developer tooling risk, redo the analysis.
Letting developers self-install anything from any marketplace. Self-service is the productivity baseline, but unconstrained self-install of marketplace extensions is the equivalent of letting any user install any kernel driver. Constrain by allow-list, minimum age, or both.
Treating supply chain monitoring as a one-time SBOM exercise. SBOMs answer "what is in our software at build time." They do not answer "what extension just got auto-updated on the CTO's laptop." Live developer-side monitoring is the missing layer.
Key Takeaways
- The breach surface was trust, not infrastructure. A 2,777-byte JavaScript payload inside a verified extension was enough to extract 3,800 GitHub-internal repositories. The marketplace, the badge, and the auto-update mechanism did the rest.
- 18 minutes is the new detection benchmark. Community response pulled the extension in 18 minutes on Visual Studio Marketplace and 36 minutes on Open VSX. That was already too slow for one of the highest-profile targets in the industry.
- EDR does not cover this surface. Interpreted code running inside IDE processes does not register on binary-focused endpoint tooling. Developer machines need different controls.
- Minimum-age policies are the highest-impact fix. Blocking installations of any extension or package younger than 24 to 72 hours would have prevented the breach. The control is cheap and broadly available.
- Developer workstations are privileged endpoints. They hold source code, cloud credentials, and CI/CD tokens. Treat them with the same discipline as administrative machines, not standard user laptops.
Scrutex monitors developer tooling supply chain exposure, leaked credentials, and external attack surface in one platform. Continuous coverage of npm, PyPI, VS Code Marketplace, Open VSX, and dark web sources where stolen developer tokens get traded. Start free: platform.scrutex.ai/sign-up
Frequently Asked Questions
What is the Nx Console extension and how did it lead to the GitHub breach?
Nx Console is a VS Code extension for the Nx monorepo build system, with around 2.2 million installs and verified publisher status on the Visual Studio Marketplace. On May 18, 2026, attackers used a stolen maintainer token to publish a poisoned version 18.95.0 that read credentials and session tokens from any developer who installed or auto-updated it. One of those developers worked at GitHub, and the attacker used the harvested credentials to exfiltrate roughly 3,800 GitHub-internal repositories.
Who is TeamPCP and what do they want?
TeamPCP is a cybercrime group active across 2026, tracked under the threat intelligence designation UNC6780. The group specialises in compromising developer tooling supply chains by stealing maintainer tokens and publishing poisoned versions of widely-used packages and extensions. In the GitHub incident they listed the stolen data for sale at $50,000, later raising the price to $95,000 alongside the Lapsus$ extortion crew.
How long was the malicious Nx Console extension live on the marketplace?
The poisoned version 18.95.0 was live on the Visual Studio Marketplace for 18 minutes, between 12:30 and 12:48 UTC on May 18, 2026. The same version was live on the Open VSX marketplace for 36 minutes. That window was long enough for auto-update mechanisms on millions of developer machines to pull the malicious release.
Are customer organisations on the GitHub platform affected?
GitHub's CISO Alexis Wales said on May 20, 2026 that the activity involved exfiltration of GitHub-internal repositories only, with no evidence of impact to customer organisations, enterprises, or user repositories. Some GitHub-internal repositories contain customer-related content such as excerpts of support interactions. The investigation is ongoing and GitHub has said it will notify affected customers via established channels if that changes.
What should security teams do about VS Code extension risk right now?
Three actions take priority. First, inventory which extensions developers are running across engineering machines. Second, apply a minimum-age policy that blocks any extension or package published within the last 24 to 72 hours. Third, treat developer workstations as privileged endpoints with the same monitoring, network controls, and credential rotation discipline applied to administrative machines.
How does this relate to EASM and CTEM?
Developer tooling exposure is now part of the external attack surface. EASM extends beyond DNS and IP discovery into the publishing identities, registries, and marketplaces that developers depend on. Within a CTEM programme, developer tooling sits in the Discovery and Validation stages: discover which extensions and packages your developers run, validate that the controls around them would catch a poisoned version before auto-update completes.
Was the Nx Console payload signed or verified by Microsoft?
The extension carried Microsoft's verified publisher badge on the Visual Studio Marketplace, but verification confirms publisher identity, not the safety of any individual release. The malicious version 18.95.0 was published from the legitimate publisher account using a stolen token. The marketplace review systems did not flag it before community responders did.