VSCode Extension Supply Chain Breach: 3,800 Repos Compromised
A poisoned version of the Nx Console extension — installed by more than two million developers — exfiltrated roughly 3,800 GitHub-internal repositories in under eighteen minutes. The attack staged its payload inside an orphan commit, forged Sigstore provenance using stolen OIDC tokens, and exfiltrated credentials through triple-channel command-and-control. The VSCode extension marketplace had no permission boundary to stop any of it.
On May 20, 2026, GitHub published a blog post confirming that an employee device had been compromised through a poisoned VS Code extension. The post described the incident as contained and noted that customer repositories were not affected. Within hours, BleepingComputer identified the extension as Nx Console (nrwl.angular-console v18.95.0) and reported the approximate count of breached internal repositories.
The Attack Chain, Stage by Stage
The threat actor — tracked by Google Threat Intelligence as UNC6780 and self-identifying as TeamPCP on the Breached forum — executed a multi-stage supply chain worm that turned a popular developer tool into a credential harvester and self-propagating infection vector.
Stage 1: Orphan Commit Payload Hosting
The attacker used a stolen contributor token to push an orphan commit — SHA 558b09d7 — into the nrwl/nx monorepo on GitHub. Orphan commits exist outside the main branch history and are invisible to most code review workflows. The commit contained a 498-kilobyte obfuscated JavaScript payload that would later be fetched by the poisoned extension.
Orphan commits are Git's equivalent of a rootkit's hidden process — they exist in the repository object store but never appear in any branch history that maintainers or CI pipelines inspect.
Stage 2: Extension Poisoning
With a stolen VSCE publishing token (VSCE_PAT), the attacker published version 18.95.0 of Nx Console to the VS Code Marketplace. The malicious version injected 2,777 bytes at offset 7,703,700 in the extension's main.js bundle. The injection called npx -y github:nrwl/nx#558b09d7 during the extension's activate() function — silently fetching and executing the payload from the orphan commit.
The extension was live on the marketplace for eleven to eighteen minutes before the Nx team detected the anomaly and pulled it. In that window, a GitHub employee installed it, granting the payload access to authenticated GitHub sessions on a corporate device.
Stage 3: Credential Harvesting and Exfiltration
The 498KB payload — executed via the Bun runtime to evade Node.js-focused security tools — scanned 134 filesystem paths and cloud API endpoints. The target list included GitHub PATs, AWS access keys, SSH private keys, HashiCorp Vault tokens, Kubernetes service accounts, AI configuration files, and cryptocurrency wallets.
Exfiltration used three parallel channels to ensure delivery even if one channel was blocked:
| Channel | Method | Resilience |
|---|---|---|
| HTTPS encrypted | Direct POST to attacker-controlled endpoint | Standard TLS tunneling |
| GitHub API C2 | Draft issues on repo thebeautifulmarchoftime | Looks like normal developer activity |
| DNS tunneling | Encoded data in DNS queries to attacker domain | Survives HTTP proxy restrictions |
Triple-channel exfiltration is a signal that the operator expects enterprise environments with aggressive egress filtering. Any single-channel defense would have failed.
Stage 4: Persistence and Self-Propagation
The payload established persistence across multiple surfaces: .vscode/tasks.json task definitions, .claude/settings.json configuration hooks, Python .pth file hooks, and systemd user services. Each vector ensured re-execution even if the original extension was removed.
More critically, the payload used stolen GitHub OIDC tokens to forge Sigstore provenance for new malicious packages. Packages signed with valid Sigstore provenance pass supply chain verification tools that rely on the Sigstore trust root — turning the security infrastructure itself into an attack amplifier.
Forged Sigstore provenance does not mean Sigstore is broken. It means the trust anchor — the OIDC identity — was stolen, and the signing infrastructure faithfully attested to a compromised identity. The signature is valid; the identity behind it was not.
What the Breach Exposed
The 3,800 repositories were GitHub-internal: infrastructure configuration, deployment scripts, staging credentials, API schemas, and support interaction excerpts. GitHub stated that no customer repositories were affected. The company isolated the compromised endpoint, rotated critical secrets overnight on a priority tiering system, and published its acknowledgment within days of discovery.
The scope of exfiltration is notable not for the count of repositories but for what those repositories contained. Internal infrastructure repositories tend to hold cloud deployment templates, environment variable mappings, and service authentication configurations — precisely the material that enables lateral movement into production systems.
The Marketplace Has No Permission Wall
The VS Code Marketplace hosts approximately 60,000 extensions with a cumulative 3.3 billion installs. Microsoft has verified roughly 1,800 of those extensions — about three percent of the catalog. An academic study analyzing 52,880 extensions found that 5.6 percent exhibited suspicious behavior patterns.
VS Code extensions run with full access to the developer's filesystem, network, and environment variables. There is no sandbox, no permission prompt, and no runtime boundary between an extension and the host machine. This is not a design oversight — it is the architecture. Extensions need deep system access to provide the developer experience they promise.
| Metric | Value | Implication |
|---|---|---|
| Total extensions | ~60,000 | Large attack surface for review teams |
| Verified extensions | ~1,800 (3%) | Nearly all installs are on trust, not verification |
| Suspicious behavior rate | 5.6% | Roughly 3,000 extensions flagging as anomalous |
| Malicious removed in 2025 | 110 | Detection is reactive, not preventive |
| Average extensions per dev | 40 | Each dev runs dozens of trust decisions |
The marketplace trust model assumes that publisher identity equals package safety. When a publisher's credentials are stolen, the trust model has no fallback. The marketplace has no mechanism to revoke trust at the identity layer without also revoking every install of every version ever published under that identity.
TeamPCP: A Repeat Operator
This is not TeamPCP's first supply chain compromise in 2026. The group has targeted at least five other open-source packages this year, using similar techniques: stolen publisher credentials, subtle code injection, and rapid exfiltration windows. Previous targets include Trivy, Checkmarx KICS, LiteLLM, and TanStack libraries tied to Mistral AI integrations.
The group has also partnered with Lapsus$ for extortion operations, according to BleepingComputer's reporting. The operating model blends stealthy credential theft with overt extortion — suggesting that some attacks are intelligence-gathering operations and others are revenue operations, with the same supply chain intrusion techniques serving both.
The pattern echoes earlier supply chain incidents, but with escalating sophistication:
| Incident | Year | Vector | Blast Radius |
|---|---|---|---|
| event-stream | 2018 | Maintainer handoff to malicious actor | Millions of installs, targeted cryptocurrency wallets |
| ua-parser-js | 2021 | Maintainer account compromise | 40M+ weekly downloads, crypto miner injection |
| AsyncAPI | 2025 | Stored XSS in generator templates | Developer workstations via preview server |
| Nx Console (TeamPCP) | 2026 | Stolen publisher token, orphan commit payload, OIDC provenance forgery | 3,800 internal repos, self-propagating |
Detection: IOCs and Critical Precautions
StepSecurity, led by Ashish Kurmi, published the first detailed technical analysis on May 18, 2026. Their findings include specific indicators of compromise that organizations should check immediately.
Key IOCs include the orphan commit SHA 558b09d7 in the nrwl/nx repository, the extension version nrwl.angular-console v18.95.0, and the payload hash 79ac49eedf774dd4b0cfa308722bc463cfe5885c in any package-lock.json. The C2 repository thebeautifulmarchoftime and the destructive token-revocation trigger string IfYouRevokeThisTokenItWillWipeTheComputerOfTheOwner embedded in commit history are also critical indicators.
Organizations discovering a compromised machine must isolate it before revoking any tokens. The payload includes a destructive daemon that triggers on token revocation — wiping the host filesystem as a retaliation mechanism. Standard incident response playbooks that prioritize immediate credential rotation will trigger the wipe.
Prevention: What Changes After This Incident
The VS Code Marketplace's permission model — or lack of one — is the structural vulnerability that made this attack possible. Extensions have unrestricted access to the developer environment, and the marketplace reviews only a small fraction of what it hosts. Fixing either side requires tradeoffs that Microsoft and the developer ecosystem have so far declined to make.
Extension Sandboxing
VS Code's architecture does not sandbox extension code. An extension that provides linting, debugging, or file operations needs filesystem and network access by design. Restricting that access would break a substantial portion of the existing extension ecosystem. The tradeoff is real: permission prompts on every extension install would improve security but degrade the developer experience that makes VS Code dominant.
Publisher Verification at Scale
Microsoft verifies publishers through a manual process that covers roughly three percent of extensions. Automated verification — static analysis, behavioral profiling, and anomaly detection on extension updates — could expand coverage, but each technique has false-positive costs that affect legitimate publishers. The 5.6 percent suspicious-behavior rate from academic analysis suggests the gap between current and adequate review is wide.
Provenance Integrity
Sigstore and SLSA provide provenance guarantees that a package was built from specific source by a specific identity — but they cannot verify that the identity itself was not compromised. The Nx Console attack demonstrated that stolen OIDC tokens produce valid Sigstore attestations for malicious code. Strengthening provenance means strengthening the identity layer, not just the signing layer.
Exceptions and Limits
Not every developer is equally exposed. Organizations that restrict extension installation to an allowlist, that run VS Code in isolated virtual machines, or that use browser-based development environments (GitHub Codespaces, Gitpod) have natural boundaries that limit extension-driven breaches. The attack primarily threatens organizations where developers install extensions freely on machines with access to sensitive repositories.
Manual code review of extension updates is impractical at the scale most teams operate — 40 extensions per developer, each updating multiple times per year. But automated diff review tools that flag unexpected activate() modifications, new require('child_process') imports, or outbound network calls in extension changelogs could catch the class of attack used here without requiring full manual review.
Honest Assessment
| Factor | Status | Outlook |
|---|---|---|
| Extension sandboxing | Not implemented in VS Code | Breaking change for ecosystem; unlikely in near term |
| Publisher verification coverage | 3% of marketplace | Automated tooling could expand to 30-50% within a year |
| Sigstore OIDC identity strength | Depends on GitHub token hygiene | Short-lived tokens reduce but do not eliminate risk |
| TeamPCP operational tempo | Six+ attacks in 2026 | No sign of slowing; escalation to provenance forgery is new |
| Developer awareness | Low — extensions treated as infrastructure | Incident-driven awareness spikes fade within weeks |
| Enterprise extension allowlists | Minority adoption | Growing, but friction with developer autonomy |
Actionable Takeaways
- Isolate before revoking. If a machine ran Nx Console v18.95.0, take it offline before touching any GitHub tokens. The destructive daemon triggers on revocation. Image the disk for forensic review first.
- Audit extension allowlists now. Any organization without an explicit extension allowlist is operating on unconditional trust. Implement one. Start with the most-installed extensions and work outward.
- Monitor for IOCs. Search codebases and package-lock files for hash
79ac49eedf774dd4b0cfa308722bc463cfe5885c, check Git history for commit messages containingIfYouRevokeThisToken, and scan for references tothebeautifulmarchoftimerepositories. - Shorten OIDC token lifetimes. The provenance forgery relied on long-lived OIDC tokens. Configure GitHub Actions to use the minimum token lifetime that supports your workflows.
- Review extension diffs on update. Automate change detection for
activate()modifications, newchild_processornetimports, and any outbound fetch calls in extension updates before allowing installation. - Treat development environments as trusted computing bases. A compromised developer machine is not just a data leak — it is a foothold into the entire software supply chain, as earlier coverage of AI supply chain attack vectors detailed. The same principle now applies to the developer toolchain itself.