This broke Wednesday and the full picture only came out yesterday. If anyone on your team uses VS Code, this needs your attention today.
On May 18, between 12:30 and 12:48 PM UTC, a malicious version of the Nx Console VS Code extension was live in Microsoft's official Visual Studio Marketplace. Eighteen minutes. A human noticed it and reported it. Microsoft pulled it.
By then it was too late.
Over the next three days, GitHub confirmed that attackers had exfiltrated roughly 3,800 of its internal code repositories. Grafana Labs confirmed the same. Mistral AI confirmed it. OpenAI confirmed it. Yesterday, GitHub's CISO named the root cause: a poisoned Nx Console update that auto-pushed to any developer with the extension installed — which is the default.
The threat actor behind all of it is TeamPCP. You may remember them from March, when they backdoored LiteLLM through PyPI. Same group. Different vector. Much larger blast radius.
How an 18-minute window breached four organizations
The attack didn't use a zero-day. It didn't require any technical interaction from the victim. It worked because TeamPCP had already compromised the Nx Console publisher's account through earlier supply chain work — so when they pushed version 18.95.0 to the official marketplace, it came from the real publisher, signed with the real keys, passing every automated check Microsoft runs.
A developer's VS Code auto-updated. In the background, a credential stealer ran silently. It targeted everything on disk:
- GitHub personal access tokens
- NPM publish credentials
- AWS access keys and secrets
- HashiCorp Vault tokens
- SSH private keys
- API keys and secrets from
.envfiles and local keystores
With those credentials, the attacker moved laterally through CI/CD pipelines. At GitHub, that meant roughly 3,800 private repositories exfiltrated. The full scope of what was taken from OpenAI, Grafana, and Mistral is still being assessed.
The cascade TeamPCP built to get here
This wasn't a standalone attack. It was the latest step in a multi-month supply chain operation.
The chain started with TanStack — a widely-used set of JavaScript utilities with millions of weekly downloads. TeamPCP compromised TanStack's npm publishing environment. From there they pushed malicious code into downstream packages that depended on it. One of those packages was in the Nx Console build pipeline. Once inside the Nx Console publisher environment, they could push an official, signed extension update.
That's three separate supply chain compromises just to get to the VS Code Marketplace. Before that, they had already hit Aqua Security's Trivy scanner, Checkmarx's KICS, and LiteLLM. Each compromise gave them new credentials to work with. New publisher accounts. New pipeline access. More trust to exploit.
The common thread: TeamPCP is specifically targeting the toolchain that AI developers use. LiteLLM routes calls to language models. Trivy and KICS are DevSecOps tools. TanStack and Nx Console are standard JavaScript dev tooling. These are the tools in your pipeline right now, on your developers' machines, with your credentials in their keystores.
They're not hacking companies. They're working their way through the open-source ecosystem that everyone depends on, one publisher account at a time.
Why small teams are more exposed than GitHub
GitHub will recover. They have incident response teams, forensics resources, and the communications infrastructure to manage a breach publicly. When a 10-person development shop gets hit through the same vector, the calculus is completely different.
There's no CISO. There's no internal security team watching audit logs. There's no press release. The attacker walks out with your client code, your cloud credentials, and your internal API keys — and you find out the way most small teams find out: something breaks, a bill spikes, or someone notices data showing up somewhere it shouldn't.
Enterprise dev shops have managed device policies, curated extension allowlists, and endpoint detection tools that would catch suspicious credential access. Small teams have developers running whatever they installed last month on machines that also hold personal accounts, client project files, and local SSH keys configured for every server they've ever touched.
The extension auto-update path is the specific soft spot. Developers reasonably treat extensions as trusted software that maintains itself. Most don't think of it as a supply chain. But every extension that auto-updates is deploying new, unreviewed code onto your developer's machine with full access to the file system, environment variables, and local network — every time it updates.
What you need to do right now
Check whether anyone had Nx Console installed on May 18. The malicious version was 18.95.0. Check installed extension versions via the Extensions panel in VS Code. If anyone was running it between 12:30 and 12:48 PM UTC on May 18 with auto-update enabled, treat that machine as compromised.
Rotate credentials from any potentially affected machine. Don't audit first — rotate first. GitHub personal access tokens, NPM tokens, AWS access keys, HashiCorp Vault tokens, SSH keys. Revoke and reissue all of them. If credentials were stored on that machine at all, they should be considered stolen.
Review your CI/CD pipeline logs from May 18–21. The attacker's move after getting initial credentials is lateral movement through your pipeline. Look for unexpected secret access, unexpected repository clones, or workflow runs you didn't initiate. GitHub Actions audit logs are available under your organization's Security tab.
Update Nx Console to v18.100.0 or later. The Nx team shipped a clean version quickly. Version 18.95.0 is the malicious build. Anything before or after is safe.
Disable VS Code extension auto-updates. In VS Code settings, set extensions.autoUpdate to false. Extension updates should be a deliberate action, not a silent background event. Right now, the update path is the attack path. This setting change takes 30 seconds.
Move credentials off developer machines. API keys, cloud credentials, and deploy secrets should live in a secrets manager — 1Password, Bitwarden, AWS Secrets Manager, whatever you're already using. Not in .env files, not in ~/.aws/credentials, not in local keystores. If a credential can be stolen by malware running on a developer machine, it will eventually be.
The pattern worth understanding
Back in March, we wrote about the LiteLLM compromise and said supply chain attacks against AI tooling were going to keep happening. This is what that looks like when it scales.
The official Visual Studio Marketplace is not a safety guarantee. Microsoft's automated scanning doesn't catch a malicious update pushed by a legitimately compromised publisher account — because from Microsoft's perspective, it came from the right account, signed with the right keys. GitHub, OpenAI, Grafana, and Mistral all had security teams. They all got hit.
TeamPCP knows that the weakest link in any modern development organization isn't the network perimeter or the application code. It's the implicit trust developers place in the tools they use every day. An extension that auto-updates. A package that someone installed two years ago and forgot about. A CI/CD action that pulls from a third-party repo.
The answer isn't to stop using VS Code extensions or open-source packages. It's to treat your developer toolchain with the same discipline you'd apply to production infrastructure: know what's installed, control what updates, keep credentials out of places malware can reach them.
The boring hygiene. It's still the most effective defence.
We work with small dev teams and tech-adjacent organizations on practical security posture — the stuff that actually reduces risk, not compliance documentation that sits in a drawer. If you want to review your credential exposure or tighten up your CI/CD pipeline, get in touch.