After the Nx Console Breach: What Should Your Editor Be Allowed to Read?

Published on May 21, 2026 by The Kestrel Tools Team • 8 min read

A Slack ping lands at 9:14 AM: “Do you have Nx Console installed in VS Code? Don’t open your editor until you confirm.” You check, you confirm, and somewhere between the second coffee and the security team’s follow-up you realize the thing that just may have read your .env files isn’t a package — it’s the IDE you live in.

This week’s headlines were technically right and operationally misleading. GitHub disclosed today that the breach affecting roughly 3,800 repositories was carried out through a malicious version of the Nx Console VS Code extension, distributed via the same TanStack-adjacent npm supply-chain compromise that filled Hacker News nine days ago. BleepingComputer corroborated the link on May 20. By the time you read this, the affected version is gone and the marketplace listing is patched. Good.

But the part of the story that doesn’t fade with the news cycle is the threat model. An npm package and an editor extension are both “code you didn’t write,” and they share the same supply chain — but they have wildly different permissions on your machine. A pinned package-lock.json is a meaningful audit. A list of installed VS Code extensions, for most developers, isn’t.

This post is the explainer that should have come with the headline: what an editor extension can actually access, why this vector is harder to audit than npm, and the 60-second checklist you can run before you open VS Code tomorrow morning. We build Kestrel Tools, a privacy-focused suite of online utilities that runs entirely in your browser, so we have an opinion about where workspace-resident tooling ends and ephemeral tooling begins. We’ll get to that, but the audit checklist comes first.

What is the vscode extension supply chain attack?

A vscode extension supply chain attack is a compromise where a trusted VS Code extension is republished with malicious code through the Visual Studio Marketplace, and the editor’s auto-update mechanism quietly delivers the malicious version to every developer who has it installed. In the Nx Console incident disclosed by GitHub on May 21, 2026, a compromised maintainer flow allowed an attacker to push a tampered build of Nx Console; the bad version was live long enough to touch approximately 3,800 repositories before it was caught and pulled.

The shape of the attack matches the npm playbook: trusted publisher, single point of failure on credentials, fast republish, slow detection. The difference is what the malicious code can reach once it lands. An npm package activates when you import it; a VS Code extension activates the moment you open a folder.

What can a VS Code extension actually access?

This is the question almost nobody asks before they click “Install,” and the answer is broader than the marketplace listing implies.

A VS Code extension running in the standard Node-based extension host can:

  • Read every file in the workspace folder you opened. Including .env, .env.local, .npmrc, ~/.aws/credentials if you happen to have opened your home directory, and any private key sitting in a secrets/ subfolder.
  • Read the contents of every editor tab. Even files outside the workspace, if you’ve opened them.
  • Execute shell commands. Through vscode.tasks or by spawning a child process directly. This includes git, npm, aws, gh, and anything else on your $PATH.
  • Read and modify the integrated terminal. An extension can write keystrokes into a terminal you have open, capture its output, and inject commands.
  • Make outbound network requests. No CSP, no same-origin policy, no prompt. The Node runtime in the extension host has the same network access your shell does.
  • Persist data across sessions. Through globalState, workspaceState, or files written anywhere the user can write.
  • Install or trigger other extensions. Including extensions with their own broad permissions.

There is no granular permission system. There are no scopes. When you click “Install” on a VS Code extension, you grant all of the above, in one click, with no per-permission consent flow. The marketplace shows a publisher name and a verified-publisher badge. That’s the user-facing trust signal.

Compare this to a browser extension, which has to declare permissions in a manifest and prompt you on install, or a phone app, which runs in an OS-level sandbox with explicit grants. VS Code extensions are closer to a binary you chmod +x and run.

Why is this harder to audit than an npm package?

Three concrete reasons.

1. There’s no lockfile. Your package-lock.json records exact versions of every npm dependency, with content hashes. An identical install on a teammate’s machine resolves to byte-identical packages. Your VS Code extension list has no such artifact. Each developer’s editor pulls extensions from the marketplace at install time and auto-updates them silently. There’s no team-wide pin, no review checkpoint, no diff.

2. Auto-update is on by default. VS Code’s extensions.autoUpdate setting defaults to true. This is convenient when an extension ships a bug fix and dangerous when an extension ships compromised code. The malicious Nx Console version reached most installed users within hours of being published, before the marketplace pulled it.

3. The blast radius extends past the extension’s stated purpose. A linter extension that says “checks your code for style issues” can — once installed — also read your .env file, run git push, and post the output to a remote server. The marketplace listing doesn’t bound what the extension is technically allowed to do. It only describes what the extension says it does.

The npm world has spent a decade building partial mitigations: lockfiles, npm audit, Dependabot, Socket, Snyk, signed publishes, 2FA on the registry. The VS Code extension ecosystem has marketplace verification and a reactive takedown process. That’s it. The asymmetry between the two stories is the actual news, and it didn’t make the headline.

How to audit your installed VS Code extensions in 60 seconds

This is the part you can do right now. It takes about a minute on a normal extension list.

Step 1 — list what’s installed.

code --list-extensions --show-versions

You’ll get a list like nrwl.angular-console@18.34.0. Pipe to a file if you want to share with security.

Step 2 — flag anything you don’t recognize. For each entry, ask: do I remember installing this, and do I still use it? VS Code accumulates extensions like a teenager’s bedroom. Most developers have at least one or two that landed there as a recommended-extension prompt in a project they no longer touch.

Step 3 — check publishers against the marketplace. Open https://marketplace.visualstudio.com/items?itemName=<publisher>.<name> for any extension you’re not sure about. Look for: verified publisher badge, a real homepage, a public source repository. An extension with no source link, no homepage, and a publisher name that looks slightly off is a yellow flag.

Step 4 — disable auto-update for sensitive extensions. In settings.json:

{
  "extensions.autoUpdate": false,
  "extensions.autoCheckUpdates": true
}

This flips the default: you’ll be notified about updates but won’t apply them silently. The trade-off is that you’ll have to click “Update” yourself, which most teams forget about until it bites them. For high-trust environments, the friction is the point.

Step 5 — uninstall the ones you no longer use.

code --uninstall-extension <publisher>.<name>

Fewer extensions, smaller attack surface. The single most effective hardening step is also the most boring one.

What to do if you had Nx Console installed during the breach window

If the affected Nx Console version was on your machine at any point in the past few days, treat your editor session as compromised and run the standard rotation playbook. The exact version range is in GitHub’s disclosure thread; check there for the canonical numbers before assuming you’re clear.

  • Rotate any credentials that were readable from your workspace. This includes .env values, cloud provider keys (AWS, GCP, Azure), any token in ~/.npmrc or ~/.gitconfig, GitHub PATs, SSH keys if your home directory was open in VS Code.
  • Check git log on every repo you opened during the window for unexpected commits, especially to branches you don’t typically push to.
  • Audit recent npm publishes under any registry token that lived in .npmrc. The TanStack incident’s ancestry suggests the same threat actor is interested in registry credentials.
  • Reinstall Nx Console from the patched version — the marketplace listing has been updated by the time you’re reading this.
  • Tell your security team. Even if you think nothing leaked. The incident response value of an honest “I had this installed during the window” is high; the cost of staying quiet and being wrong is much higher.

None of this is novel — it’s the standard credential-rotation drill. The only twist is that the trigger isn’t “I leaked a key on GitHub,” it’s “I had an extension installed.”

Where ephemeral browser tools fit in this picture

Here’s the architectural honesty section, because it’s the reason this post exists.

An editor extension is workspace-resident: it lives in your IDE, gets reactivated every time you open a folder, and inherits your filesystem and network permissions. An ephemeral browser utility is exactly the opposite. You open a tab, paste data into a form, see the result, close the tab. There is no persistent code on your machine. There is no auto-update. There is no .env reader sitting silently in your editor host.

This isn’t a knock on extensions — they exist because the editor is the right place for some workflows, like AI code completion or a project-aware linter. But for one-off transformations — a JSON pretty-print, a JWT decode, a base64 round-trip, a hash check, a color conversion — the trade-off shifts. An editor extension’s persistence is overhead you didn’t need; an ephemeral browser tool that runs entirely client-side gets the job done with a strictly smaller attack surface.

This is the architecture choice behind Kestrel Tools. Every utility — JSON Formatter, JWT Decoder, Hash Generator, Color Converter, image and PDF tools — runs in your browser. The tool never sees your data because there’s no endpoint to receive it, and there’s no extension to compromise because there’s no extension at all. Open DevTools while you use it; verify the empty network tab yourself. That’s the same “trust the architecture, not the marketing” point we made about npm-built SaaS tools nine days ago, applied one layer up the stack.

The takeaway

The Nx Console incident is a reminder that your VS Code extension list is a supply chain you don’t audit. There’s no lockfile, no per-permission grant, no team-wide pin, and auto-update is on by default. Once installed, an extension can read every file in your workspace, run shell commands, and make arbitrary network requests — without prompting you again.

The practical response is the same shape every time:

  • Run code --list-extensions --show-versions and prune the ones you no longer use.
  • Disable extensions.autoUpdate for sensitive setups.
  • Verify publishers and source repos for the extensions you keep.
  • Rotate credentials if you had Nx Console (or any other compromised extension) installed during the breach window.
  • For one-off data transformations, prefer ephemeral browser tools over workspace-resident extensions when the workflow allows it.

The TanStack postmortem and the Nx Console disclosure are the same family of incident with different access levels. Pinning your package-lock.json is necessary; auditing your editor extensions is the part most teams haven’t gotten around to. This week is a reasonable nudge to start.

If you want a few one-off utilities that work entirely client-side and never see your data, our free toolset at kestreltools.com is a reasonable place to begin. Open DevTools while you use it. Verifying is faster than trusting, and it survives the next breach.