How a Poisoned VS Code Extension Breached GitHub — And What Every Developer Should Do Right Now

On May 18, 2026, a popular VS Code extension called Nx Console was hijacked. Within minutes, it was used to steal developer credentials. Within days, it led to a confirmed breach of GitHub's own internal repositories. About 3,800 private repos were stolen.

This is not a theoretical attack. This actually happened. And it started with something most of us do every day — opening VS Code.

Here is what happened, who is at risk, and most importantly, what you should do right now to protect yourself.

What Is Nx Console?

Nx Console is a VS Code extension with over 2.2 million installs. It gives you a visual interface for Nx, which is a popular build tool used by teams that manage multiple projects inside a single repository (called a monorepo). Think of it as a dashboard for running builds, generating code, and managing dependencies — instead of typing long terminal commands.

It is mostly used by frontend and full-stack developers working with Angular, React, and Node.js in medium-to-large teams.

What Happened — Step by Step

This was not a simple hack. It was a chain of attacks, where one breach led to the next.

Step 1 — The TanStack Breach: Weeks earlier, a separate open-source project called TanStack was compromised. During that attack, one of the Nx team's developers had their GitHub credentials stolen without knowing it.

Step 2 — Planting the Payload: On May 18 at 3:18 AM UTC, the attacker used those stolen credentials to push a hidden commit into the official Nx GitHub repository. This was an "orphan commit" — it had no parent history, no visible branch, and no connection to any pull request. It contained just two files: a package.json and an obfuscated index.js with the malicious payload.

Step 3 — Publishing the Poisoned Extension: At 12:36 UTC, the attacker used stolen VS Code Marketplace publishing credentials to release version 18.95.0 of Nx Console. It looked and behaved exactly like the normal extension. But on startup, it silently ran a shell command that downloaded and executed the hidden payload from that planted commit.

Step 4 — Stealing Everything: The moment a developer opened any workspace, the extension quietly went to work. It harvested tokens and secrets from GitHub, npm, AWS, HashiCorp Vault, Kubernetes, 1Password, and even Claude Code configurations. It then sent the stolen data out through three different channels — HTTPS, the GitHub API, and DNS tunneling — so even if one channel was blocked, the others would still work.

Step 5 — The GitHub Breach: A GitHub employee happened to have the poisoned extension installed. Their stolen credentials gave TeamPCP access to GitHub's internal code repositories. GitHub confirmed that roughly 3,800 internal repositories were exfiltrated. They say customer data stored in customer-owned repos was not affected, but the investigation is still ongoing.

The malicious version was live for only about 11 minutes before the Nx team detected and removed it. But 11 minutes was more than enough.

What Made This Attack So Dangerous

A few things stand out about this attack that make it different from a typical malware incident:

It came from an official source. The extension was published to the real VS Code Marketplace using real publishing credentials. There was no fake listing, no typosquatting, no shady download link. It was the same extension page that 2.2 million developers already trusted.

It used signed provenance. The payload included full Sigstore integration and could generate valid SLSA provenance attestations. In plain terms, this means the attacker could publish further poisoned npm packages that would appear as legitimate, cryptographically verified builds. The security tools designed to catch fakes would have approved them.

It was smart about who to target. The payload skipped machines with fewer than four CPU cores and avoided Russian or CIS time zones. This was designed to run only on real developer machines and avoid security research sandboxes.

It installed a persistent backdoor. On macOS, it dropped a Python backdoor that used the GitHub Search API as a dead drop for receiving further commands. Even after removing the extension, the backdoor would remain.

Are You Affected?

You may be affected if:

• You had Nx Console installed in VS Code, Cursor, or any compatible editor
• Version 18.95.0 was installed between 12:36 and 12:47 UTC on May 18, 2026
• You opened any workspace during that time

Check your machine for these signs of compromise:

• A file at ~/.local/share/kitty/cat.py
• A file at ~/Library/LaunchAgents/com.user.kitty-monitor.plist (macOS)
• A file at /var/tmp/.gh_update_state
• Any files matching /tmp/kitty-*
• A Python process running cat.py
• Any process with __DAEMONIZED=1 in its environment

If you find any of these, assume your machine is fully compromised.

What You Should Do Right Now

Whether you were directly affected or not, this attack teaches us that the tools we trust the most are now the tools attackers want to compromise the most. Here is what every developer should do:

1. If You Were Affected — Emergency Steps

• Kill any suspicious processes listed above and delete the files from disk
• Rotate everything. Every GitHub token, npm token, AWS key, SSH key, database password, API key, cloud credential — anything that was reachable from that machine. Not tomorrow. Now.
• Update Nx Console to version 18.100.0 or later
• Check your Git history and npm publish logs for any activity you did not initiate
• Alert your team and your security lead

2. Pin Your Extension Versions

VS Code auto-updates extensions silently in the background. Most developers never notice when an extension version changes. This is exactly what the attacker counted on.

Disable automatic extension updates in VS Code. Go to Settings and search for extensions.autoUpdate and set it to false or onlyEnabledExtensions. Review changelogs before updating manually. Yes, it is extra work. But it is the same discipline you already apply to production dependencies.

3. Stop Keeping Production Credentials on Your Dev Machine

This is the most important takeaway. If your laptop has AWS keys, Kubernetes configs, database passwords, 1Password vault access, and npm publish tokens all sitting on it — then one compromised extension and everything is gone.

• Use short-lived tokens instead of long-lived ones. Most cloud providers support this.
• Use just-in-time access — request elevated permissions only when you need them, and have them auto-expire.
• Consider using a separate machine or VM for production operations. Your daily coding machine should not be the same context where you can deploy to production or access customer databases.
• If you use 1Password or any password manager CLI, do not leave sessions open indefinitely.

4. Treat Your GitHub Tokens Like Passwords

The entire Nx attack chain started because one contributor had a GitHub personal access token sitting around from an older breach. That single token gave the attacker write access to the official repo.

• Go to github.com/settings/tokens right now and audit every token you have.
• Delete any token you do not actively use.
• Set expiry dates on every token. 30 days max for anything with write access.
• Use fine-grained tokens with the minimum scopes needed. A token that only needs to read one repo should not have write access to all your repos.
• Never put tokens in environment variables that persist across sessions unless absolutely necessary.

5. Be Careful About What Extensions You Install

VS Code extensions can run arbitrary code the moment you open a workspace. That is a huge amount of trust you are handing over.

• Audit your installed extensions regularly. Remove anything you do not actively use.
• Be suspicious of extensions that ask for broad filesystem or network access.
• Watch for sudden version jumps or unexpected updates from extensions you use daily.
• Consider using VS Code's Restricted Mode for workspaces where you handle sensitive projects.

6. Separate Your Environments

The reason this attack was so devastating is that a single compromised developer machine gave attackers access to everything — the code, the tokens, the cloud, the CI/CD pipeline, the password vault.

Start thinking about blast radius. If one machine gets compromised, how much can an attacker reach from it? The answer should be "as little as possible."

• Use different machines or VMs for development vs production access
• Do not reuse the same SSH keys or tokens across environments
• Set up alerts for unusual activity on your GitHub, npm, and cloud accounts

7. Watch for the Next One

This is not a one-time event. 2026 has already seen supply chain attacks targeting axios (npm), Notepad++ (update channel), Bitwarden (npm CLI), and a leaked CISA credential dump — all before this Nx Console incident. The TeamPCP group is specifically going after developer tools because developers are the ones with the most valuable access.

Stay informed. Follow security advisories for the tools you use. Keep an eye on changelogs. And when something feels off — a weird update, a new process running, unexpected network activity — investigate before you dismiss it.

The Bigger Picture

The uncomfortable truth is that the software supply chain is broken in a fundamental way. We trust code from thousands of strangers every day — through package managers, extensions, CI actions, and build tools. Most of the time it works. But when it does not, the damage is catastrophic.

GitHub's own internal repos were breached because an employee opened VS Code. That is how thin the line is now.

The attack surface is not your firewall anymore. It is your code editor. It is your package manager. It is the GitHub Action you added last month. Treat them accordingly.

Stay safe. Stay updated. And go rotate those tokens.