GitHub confirms breach of 3,800 repos via malicious VSCode extension

Almost no manager will sign-off spending time on building stuff in-house if its available "for free".

This is also in no way a new thing. How much code was written in notepad++ in the '00ies? Did anyone bother to check if the plugins did sth. malicious? We also used some weird closed-src "addon" for the Nullsoft installer to get a product out of the door, dont remember what the problem was exactly....

Turns out no amount of communication to the team matters when you set Copilot to autopilot and it’s not aware of the compromised packages.

I suspect that’s going to be a trend.

I am telling people to wear helmets when they drive a car, this would save hundreds of thousands of lives every year in the world, but somehow I cannot convince them.

And even if this exists, and you are sandboxed, with all guardrails and such, if you trust an extension that later gets compromised, you'd get the same sadness. It's the problems with trusting trust all over again...

Maybe sandboxing, plus freezing updates for at least a week, then on each update reviewing the permissions for each extension, then reviewing the extension itself for compromises. Something that should be done not by the user but by the supply chain itself.

I heared zed sandboxes extensions. I should have a look at that editor some day.

[1] https://www.reddit.com/r/programming/comments/1tapmvi/mass_n...

I'm guessing you're referring to https://coder.com/docs/code-server ?

The best case for Microsoft software I hope for is that they do only some minor UI cosmetic changes, but even that often goes catastrophically wrong.

To be honest I doubt there's much that they can do. Many many language servers cannot run in WASM, or it would be super hard to compile them to WASM. So Zed either has to allow running arbitrary binaries like VSCode, or accept that they're going to have really poor extension support.

I just don't use VSCode and I discourage its use in any environment in which I have to work. It has already been demonstrated that it is a major security hole - not just through the public extensions, but also in terms of the telemetry data transmitted back to Microsoft in order that they can invest millions in it and yet charge nothing for it...

https://fosstodon.org/@lukewrites/100907932236227641

The problem is really how the very popular recent things on top have been built: Docker, npm, pip.

I personally do not have docker, npm or pip installed on my workstation because I know that any `xxx install` is almost the equivalent of downloading and executing a `.exe` on a Windows 95 back in the days.

Apparently what happened here is a Github employee VScode downloaded a compromised extension and it ran wild in his $HOME (npm, another Microsoft gem is involved here if I remember correctly).

How was the OS supposed to prevent that?

Migrate off vscode already.

I use Emacs for my day-to-day stuff. I don't think Emacs extensions are more secure by design. Pretty sure that, if I wanted to, I could craft an extension that does bad things. I'm not sure how hard it would've been to sneak it past MELPA or (is there really anything else people are using these days? Used to be Marmalade, but I think it's gone), but, it's people, and people make mistakes, so, there's some % chance that a bad extension can be inserted there. Such security problems happen to a lesser extent (if at all?) in the Emacs world because of the size of the user base. It's simply impractical to target a small community, as it's always a numbers game.

Very unwillingly, and with a lot of contempt, I use Android, where this "explicit permissions system" you speak of exists. There are many reasons to hate Android, and the "explicit permissions system" is a prominent member in that collective.

Companies like MS, Google etc. always default to this way of solving their security issues: by restricting their users from doing useful things. They model their users as a herd of brainless lemmings who must be herded with an iron fist in order for them not to plunge to their deaths (yes, I know, real-life lemmings don't do that, but we all know the metaphor). And this tactics is so common that the MS-lemmings learn to yearn for it.

The solution I want to see to this and similar problems is two-fold:

1. Users learn to use their tools.

2. Users learn to treat important information on their computers in a more defensive way, if they open the door for outside, potentially bad, software providers.

This is, of course, a pie in the sky sort of wish... But, imagine it was achievable, wouldn't the world be a better place? Now, I believe it's possible to approach these goals gradually, and it would still be better than a system imposed by the software provider that prevents users from doing useful things.

For example, Emacs has a mechanism to prompt users when attempting to use a particular functionality. Some of it is because the functionality can be surprising for the novice, some of it is because it could be dangerous from the security standpoint. So, in principle, VSCode could do that too. Eg. a user would have to interactively grant its extensions permissions to call whatever functionality within the editor, while some "dangerous" functionality would have to be removed from the JavaScript runtime available to VSCode and only made available in this interactive way (eg. when JavaScript code in VSCode extensions wants to call exec() or similar, it would have to call an overloaded exec() provided by VSCode, that would inform the user that such-and-such extension wishes to run such-and-such command, and that it needs their permission to do it).

A company that wants to remain secure would have to employ strict restrictions on installing software. Only installing npm packages and plugins from an internal preapproved repo for example.

At this point I try and get the most done with the least amount of extensions period. That and trying to get the rest of my code off of Github is the other.

Which is really insane when you think about it. Plan 9 had this sorted out decades ago.

AI is making this even worse. With coding agents, anyone can throw together a quick internal prototype of any idea they have, even if it has no hope of ever making it to production.

Some of those could be forks.

It's gotten a lot worse (and made news) more recently, as the downtime as increased.

The dreaded "process" to get a single tool registered, working and allowed, is the reason a company is slow, dysfunctional and usually failing at a task.

The security tax and speeding tickets on everything are a luxury destroying much value.

Don’t attack individuals for mistakes of a system.

Your security or their money (selling Copilot to enterprise customers): what would they choose, hmm? Surprise!

Just don’t install crap maybe.

We aren't talking about a single dev developing an IDE on their spare time. We are talking about a company with expenses and revenues in billions. They could develop and support replacement for every single extension in the vscode marketplace (most are redundants) and it would still be an invisible blip in their financial numbers.

A fine grained token is likely to have read access to the IaaS repo as that is likely the very repo they are operating on when the malware compromises them.

3800 repos up for blackmail may make a good headline but it's likely that Github don't really care about 3798 of those repos being made public. It'd be annoying for those 3798 to be made public but they can deal with that. It's the 2 repos that contain really important stuff that they really don't want to be made public. You can't rely on fine grained tokens to limit the leak of these things as, at some point, someone with that very access will get compromised.

Limiting TTL on tokens/auth isn't a perfect solution either. If the token is leaked via some malware it can be used to clone repos within minutes (even seconds) of being leaked. No-one wants to have to perform 2FA every few seconds in order to get on with their day.

IP based restrictions may help, but then the malware would probably evolve to include a tailscale/wireguard key so that the clone/exfiltration is done from the existing IP address and then the data is proxied away separately.

Future dev environments are going to be heavily sandboxed in terms of "do github stuff in this sandbox, copy files to another sandbox to do package updates, vet everything coming back, etc"

https://github.blog/security/investigating-unauthorized-acce... links to https://github.com/nrwl/nx-console/security/advisories/GHSA-... Nx Console

https://bonkersworld.net/organizational-charts

Guess what they did a year ago.

They removed 700 or so packages from NuGet proactively but those turned out to be false positives.

It is hard to do the right things.

Security researchers identified a series of exploitable vulnerabilities in github.com by using LLMs to review the compiled GitHub Enterprise Server binaries: https://www.wiz.io/blog/github-rce-vulnerability-cve-2026-38...

> for other package managers

For other js package managers. Sadly such functionality seems far less common for c# (nuget) or rust (cargo).

> add Socket Free Firewall when installing npm packages on CI to catch malware

It appears that functionality depends on blacklisting malware from being downloaded? But don't the repositories (npm, etc) take down malware once it's identified - is socket actually blacklisting malware faster than npm? That sounds unlikely, but maybe? For the vs code extension from the op post, it seems like it was live for like 18 minutes on the official vs code marketplace, and slightly longer on openvsx as ms sadly doesn't allow vs code clones to use the official marketplace.

vscode has no security model. It's not like swiss cheese where there are holes and some of the go all the way through. vscode is all hole with some cheese on the side. There is absolutely no isolation between the front-end process, the backend size (the thing that runs in the remote or the devcontainer), and any extensions or anything that might be in a repository whose authors you "trust".

The malware (be it a VSCode plugin, an npm package, or whatever is next) simply slurps up all of the users private keys/tokens/env-vars it can find and sends this off somewhere covertly.

It's trivial to do this in a way to avoid detection. The small payload can be encrypted (so it can't be pattern matched) and then the destination can be one of millions of already compromised websites found via a google search and made to look like a small upload (it could even be chunked and uploaded via query parameters in a HTTP GET request).

The hackers receive the bundle of compromised tokens/keys and go look at what they give access to. Most of the time it's going to be someone's boring home network and a couple of public or private github repos. But every once in a while it's a developer who works at a big organisation (e.g. Github) with access to lots of private repos.

The hackers can then use the keys to clone all of the internal/private repos for that organisation that the compromised keys have access to. Some organisations may have alerts setup for this, but by the time they fire or are actioned upon the data will probably be downloaded. There's no re-auth or 2FA required for "git clone" in most organisations.

With this data the hackers have further options:

a) attempt to extort the company to pay a ransom on the promise of deleting the data

b) look for more access/keys/etc buried somewhere in the downloaded repos and see what else they can find with those

c) publish it for shits and giggles

d) try and make changes to further propagate the malware via similar or new attack vectors

e) analyse what has been downloaded to work out future attack vectors on the product itself

Right now Github (and others recently compromised in similar ways) will be thinking about what information is in those internal repos and what damage would it cause if that information became public, or what that information could be used to find out further down the line.

"Customer data should not be in a github repo" is all well and good, but if the customer data is actually stored in a database somewhere in AWS and there's even just one read-only access token stored somewhere in one private github repo, then there's a chance that the hackers will find that and exfiltrate the customer data that way.

Preventing the breach is hard. There will always be someone in an org who downloads and installs something on their dev machine that they shouldn't, or uses their dev machine for personal browsing, or playing games, or the company dev infra relies on something that is a known attack vector (like npm).

Preventing the exfiltration is virtually impossible. If you have a machine with access to the Internet and allow people to use a browser to google things then small payloads of data can be exfiltrated trivially. (I used to work somewhere where the dev network was air-gapped. The only way to get things onto it was typing it in, floppy or QIC-150 tape - in the days before USB memory sticks.)

Detecting the breach is nigh on impossible if the keys are not used egregiously. Sure some companies can limit access to things like Github to specific IPs, but it wouldn't take much for the malware to do something to work around this. (I can see things like a wireguard/tailscale client being embedded in malware to allow the compromised machine to be used as a proxy in such cases.)

Alerting that requires manual response is nigh on useless as by the time someone has been paged about something the horse has already bolted.

Knowing what has been taken is also a huge burden. 3800 repos that people now have to think about and decide what the implications are. Having been through something like this in the past there are plenty of times people go "I know that repo, it's fine, we can ignore that one" only for it to contain something they don't realise could be important.

These kind of attacks are going to become increasingly common as they're proven to work well and the mitigations for them are HARD. It doesn't need to be targeted at all either, you just infect a bunch of different things and see what gets sent in.

If companies continue to not pay the ransom then we're going to get a lot more things published and many companies having to apologise for all manner of things that end up being leaked.

> “unnamed”

Why is “unnamed” in quotation marks?

I'm not saying it was whatwedo.twig, but I'm not saying it wasn't, either.

Edit: If anyone's got a good recommendation for a twig formatter for Cursor / VS Code, please let me know.

https://github.com/nrwl/nx-console/security/advisories/GHSA-...

https://www.stepsecurity.io/blog/nx-console-vs-code-extensio...

You have to take their words for it but how can you trust crooks?

It is a blind auction with a $50k minimum bid.