On 20 May GitHub confirmed that around 3,800 internal repositories had been exfiltrated. The route in was not an unpatched server or a stolen credential. It was a Visual Studio Code extension. One employee installed a trojanised version of the Nx Console extension, the attacker's code ran with the same permissions as the employee's editor, and the extortion crew TeamPCP started advertising the contents for fifty thousand dollars.
GitHub's own statement was matter of fact. "The attacker's current claims of ~3,800 repositories are directionally consistent with our investigation so far." No customer data outside those internal repositories, they said. They removed the malicious extension, isolated the endpoint, and began incident response. The TanStack npm supply-chain attack a few weeks earlier was the same actor and the same pattern.
If your reaction is "well, that's a developer problem", read on. Almost everything in this story has a non-developer equivalent inside an SME.
What an extension can actually do
A VS Code extension, once installed, runs with the permissions of the editor. The editor has access to the files the user is editing, the git credentials cached on the machine, any environment variables the developer has set, and the network. That last one is the important one. The extension can talk to any server on the internet without anyone watching. There is no popup, no review, no "this extension would like to send 800MB to an address in Eastern Europe, allow?" question.
The same is true of browser extensions. A Chrome extension with "read and change all your data on the websites you visit" is reading the contents of every internal SaaS tool the user has open. That includes the CRM, the finance system, the HR portal, the shared Google Drive. Most extensions ask for that permission as a matter of course. Most users grant it without thinking, because almost every extension asks for it.
The same is true of mobile apps with accessibility permissions. The same is true of any "AI assistant" desktop app that reads the screen. The category is wider than people realise.
Why this one mattered
Three things made the GitHub incident notable.
The extension was a real one. Nx Console is a legitimate, widely used developer tool. The attacker did not write something new; they took the real one, added their payload, and put it on the marketplace under a similar name. Anyone searching for the genuine article had a reasonable chance of installing the wrong one. This is how npm and PyPI attacks work too. The defence "I only install software I trust" does not cover the case where the wrong copy of the trusted thing is what gets installed.
The blast radius was the whole repo set. The compromised endpoint had checked out, or could check out, the company's internal code. Once the attacker had remote access through the extension, fetching the rest was just git commands. There was nothing about the source code that required extra credentials to read once you were on the machine of someone who could already read it.
It propagated. TeamPCP had already used the same trick against npm and PyPI, and were linked to the "Mini Shai-Hulud" campaign that targeted OpenAI employees. The same crew, the same playbook, three different targets in a month. The first time it works, it gets done again.
What an SME should take from this
You probably do not have a private GitHub estate worth exfiltrating. You do have browser extensions installed across your laptops, IDE extensions on your developer machines, and maybe a handful of desktop "productivity" tools sitting in the system tray. Each is a piece of software that runs with the user's permissions and talks to the internet without supervision.
Make an inventory. For staff laptops you can list browser extensions through the management console of Chrome, Edge, or whatever browser is standard. For VS Code, the command code --list-extensions will print them. If neither is in place, ask the team to send you a screenshot of their extensions tab. The point is to know what is running before deciding what to keep.
Pick a small allow list. For most non-developer staff the useful browser extensions are a password manager, an ad blocker, and maybe a screenshot tool. For developers the list is longer but still finite. Anything outside the list goes through a request process. The request process can be informal, an email to IT or the owner-manager, but the default has to be "not installed" rather than "installed unless someone notices".
Verify identity, not just name. The compromised Nx Console extension had a near-identical name to the real one. The publisher account, the install count, and the listing history are stronger signals than the name. The official extension is usually the one with hundreds of thousands of installs and a publisher who matches the project's GitHub organisation. If a popular tool suddenly has a new publisher with three installs, that is the impostor.
Treat the developer laptop as a privileged endpoint. Developers can usually reach the source code, the production secrets, and often the deployment pipeline. That makes their machine equivalent to a domain admin workstation in the old Windows model. The same rules should apply: a tighter software inventory, faster patching, and the assumption that any tool installed on it can reach everything that machine can reach.
Watch outbound network traffic from privileged machines. A VS Code extension exfiltrating gigabytes of source code looks, on the network, like a sustained upload to an unfamiliar host from a machine that does not normally do that. Most SMEs do not have this in place; most should at least know whether their firewall or endpoint tool can flag it.
The thing to internalise is that the attack surface of a workstation now includes its add-ons. The marketplace is wide, the review process is light, and the install button is one click. Treat the question "what is allowed to run on this machine" as a real question your business has an answer to, not a default left to the user.
How Steelwise can help
Building an extension allow list, a request process, and a basic outbound traffic check for the machines that matter most is the kind of practical work we do with clients. Get in touch.