DEV Community

Yelyzaveta Dymchenko
Yelyzaveta Dymchenko

Posted on

How Not to Pull a "GitHub Engineer" With Your VS Code Extensions

If a GitHub engineer — someone who works at the company that literally hosts the world's code — can get their computer hacked through a VS Code extension... you probably should read this.

Spoiler: staying safe is not hard. It's just a few small things most developers never bother doing because nothing bad has happened yet.

Let me save you the trouble of learning this the hard way.


What Happened (May 2026)

On May 19, 2026, GitHub told the world that hackers had broken into roughly 3,800 of its private repositories. The entry point was a VS Code extension called Nx Console — a popular tool used by millions of developers, with a verified badge from Microsoft.

But here's what makes this story interesting: it wasn't a simple "someone installed a bad extension" situation. It was a chain of events, each one making the next possible.

Here's how it actually went:

  1. Attackers first broke into TanStack — a set of popular JavaScript packages used by many projects. They snuck a credential-stealing payload into those packages.

  2. One of the developers who maintains Nx Console used TanStack in their own work. When the malicious TanStack package ran, it stole that developer's GitHub login credentials.

  3. With those stolen credentials, the attackers published a malicious version of Nx Console to the VS Code Marketplace.

  4. The malicious extension, once installed and running, quietly collected everything it could find on the machine: passwords, API keys, SSH keys, GitHub tokens, AWS and Google Cloud credentials, even contents of 1Password vaults.

  5. It sent all of that out silently — using HTTPS, the GitHub API, and DNS, all of which look like completely normal traffic.

  6. One of the people who had Nx Console installed and auto-updated happened to be a GitHub employee. Their stolen GitHub tokens gave the attackers access to 3,800 internal repositories.

This wasn't a dumb mistake by a careless person. It was a well-planned attack that moved through multiple trusted tools before anyone noticed.


Why VS Code Extensions Are Riskier Than You Think

When you install a VS Code extension, it gets full access to your computer. It can:

  • Read and write any file you can open
  • Send data over the internet to anywhere
  • Run programs in the background
  • Read your passwords, API keys, and .env files
  • Access your SSH keys and cloud account credentials

Most antivirus tools won't catch this. Extensions are written in JavaScript, not the kind of files security tools usually flag. The malicious Nx Console payload was a small piece of code hidden inside a larger file. It didn't look like malware because most of it was still the real, working extension.

Also worth knowing: the "Verified Publisher" badge means Microsoft confirmed the publisher is real, owns a domain, and has been on the Marketplace in good standing for at least six months. That's a useful signal — but it can't protect you if that publisher's account gets stolen. In the Nx Console case, it was the real, verified publisher. Just with stolen credentials.


How Attackers Do It (So You Can Spot It)

There are a few tricks they keep using:

Fake extensions with similar names — they publish something called prettierteam.prettier instead of the real esbenp.prettier-vscode. Same icon, same description, different publisher. Most people don't check.

Poisoned updates — they steal a real publisher's account credentials and push a bad update to an extension people already trust. Your computer auto-updates it. This is exactly what happened with Nx Console.

Sleeper extensions — they publish something harmless, wait for people to install it, then flip a switch in a later update. By then you trust it. Auto-update does the rest.

Extensions that actually work — some malicious extensions do exactly what they say they do. They're just also stealing your data at the same time. Much harder to notice.


What You Can Actually Do

1. Look at What You Have Installed

Run this in your terminal:

ls ~/.vscode/extensions/
Enter fullscreen mode Exit fullscreen mode

Go through the list. If you don't recognize something, or haven't used it in months — delete it. Every extension you remove is one less way in.

For the ones you keep, take 30 seconds to check:

  • Does it have a real GitHub page with real activity?
  • Does the number of installs make sense for what it is?

A color theme with 9 installs and no GitHub link is worth being suspicious about.

2. Turn Off Automatic Updates

Go to Code → Settings → Settings then click the small JSON icon in the top right corner. Add these two lines:

{
  "extensions.autoUpdate": false,
  "extensions.autoCheckUpdates": false
}
Enter fullscreen mode Exit fullscreen mode

Why do you need both?

  • extensions.autoUpdate — stops VS Code from downloading and installing updates on its own
  • extensions.autoCheckUpdates — stops VS Code from even checking for updates in the background

They're separate settings that work independently. If you only turn off one, VS Code can still do part of the process on its own. With both off, nothing changes on your computer unless you go and click update yourself.

This is the single most important thing on this list. The GitHub breach specifically happened because auto-update silently installed a bad version of a trusted extension. If that engineer had auto-update off, they would have updated Nx Console manually — and by the time they got around to it, the malicious version would already have been pulled.

3. Install a Network Monitor (macOS)

LuLu is a free app for Mac that tells you whenever any program on your computer tries to send data somewhere. Think of it like a doorbell for your internet traffic.

brew install --cask lulu
Enter fullscreen mode Exit fullscreen mode

After you install it: go to System Settings → Privacy & Security → Allow LuLu, then restart your Mac.

A word of honesty here: LuLu would not have stopped the GitHub breach specifically. The malicious Nx Console sent stolen data out through GitHub's own API and normal HTTPS traffic — the same connections the real extension makes every day. A popup saying "Nx Console wants to connect to github.com" would look completely normal. LuLu is most useful when an unknown extension tries to connect to some random server you've never heard of. For attacks that use trusted services like GitHub or DNS as the exit route, it won't help much.

That said — LuLu is still worth having. Most malicious extensions do phone home to unfamiliar servers, and LuLu catches those.

4. Check Before You Install Anything New

Before installing any extension, take 30 seconds:

  • Verified checkmark on the publisher → good sign, but not a guarantee (the Nx Console publisher was verified — their account was just stolen)
  • Real GitHub repo with recent commits → good sign
  • High install count for a popular tool → good sign
  • Name that looks almost like a well-known extension → warning sign
  • Just published, no history → warning sign
  • A simple theme or formatter that wants to run scripts → big warning sign

A theme extension has no reason to run commands on your computer. If something simple wants unusual permissions, that's your answer.


The Honest Part

There is no list somewhere that will keep you safe. By the time a bad extension shows up in a security report, people have already been affected. And as the GitHub case shows, sometimes the attack goes through tools you genuinely trust and have used for years.

What actually helps is simpler:

  1. Fewer extensions — you can't get hurt by something you didn't install
  2. Manual updates — gives you a chance to check before anything changes on your machine
  3. LuLu — catches extensions phoning home to unknown servers
  4. Habit — check before you install, not after something goes wrong

The people doing this are patient and organized. The GitHub attack started with one compromised JavaScript package, moved through a developer's stolen credentials, through a trusted extension, and ended with 3,800 private repositories being stolen. Every step looked normal until it was too late.

The good news is that most developers aren't doing any of this yet. Doing even two or three of these things puts you in a much better position than most.


Top comments (0)