alt.hn

5/20/2026 at 1:43:37 PM

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

 https://www.bleepingcomputer.com/news/security/github-confirms-breach-of-3-800-repos-via-malicious-vscode-extension/

by Timofeibu

5/21/2026 at 10:19:59 AM

I've been telling less computer literate folks not to install random stuff since the nineties, and I can't understand how many devs are doing just that these days.

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.

by wvh

5/21/2026 at 10:27:06 AM

Answer: Because the "random stuff" (plugins for VS Code and other IDEs) solves real problems and nothing bad happens most of the time.

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....

by Sweepi

5/21/2026 at 1:10:41 PM

"solves real problems and nothing bad happens most of the time."

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.

by cess11

5/21/2026 at 3:01:27 PM

I suppose people did learn that it isn't that bad or costly after all and the risk and the bandaids are still better than the cost of being the first to try and fix software supply chains for good. As things stand, I don't know how that might even be done if it's supposed to not be a better bandaid and someone has to do the legwork and it can't be so costly or impractical to overworked IT teams that everyone is just going to ignore it.

by dividedbyzero

5/21/2026 at 1:14:27 PM

At least in my experience depending on how serious the company was about security plugin downloading would be prohibited.

by zitterbewegung

5/21/2026 at 3:40:39 PM

Can relate. A lot of the times it is the process that is slowing people down, and it is unrealistic for any corporation to do security audition for everything developers need on time, so unfortunately rules have to be bent.

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.

by ferguess_k

5/21/2026 at 10:37:36 PM

Worse, is when the "team" doing the auditing is one guy, and that guy leaves with no replacement... and you need to explain to mgt that their new product release hasn't gone out for 3 months because you can't get the new versions of modules cleared and into the internal repo for production apps.

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.

by tracker1

5/21/2026 at 3:35:04 PM

> solves real problems and nothing bad happens most of the time

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.

by rTX5CMRXIfFG

5/21/2026 at 4:21:24 PM

Are you suggesting that AI-written code tends to be more secure than human-written code? Because there are many examples to the contrary, starting with MoltBook.

by TheFlyingFish

5/21/2026 at 4:54:21 PM

Not really, no. That's not even the point. Say for example they're just the same level of security. Then what value does a human even offer to a company if AI can do the same quality of work faster? It's not as if the company benefits from something like "human discernment", because as predicated in this thread, developers exactly have none of that, since they don't care about the security aspect of the VSCode extensions that they use. Might as well lay off the human developers and just use AI for as long as the latter is cheaper. How many people does a company really need to update its VSCode to the version that blocks the malicious extension? Do you need more than one and does that person have to be full-time?

by rTX5CMRXIfFG

5/21/2026 at 1:30:16 PM

This is how you end up with the total dumpster fire known as npm.

by stalfosknight

5/21/2026 at 10:26:34 AM

The vast majority of devs in the last few years have either been raised as sloppers or transitioned from developers to sloppers. Programming has evolved into a blackbox where fewer than ever people know how a program works, despite the numbers of "programmers" has skyrocketed. Just a few months ago a friend had a job interview(fake one obviously) where he was asked to clone a repo and do some stuff on it. The repo contained some vs code hooks which did a ton of stuff in the background installing backdoors and whatnot. In my friend's case, that was a non-issue since he was running it in a VM but I recon thousands of others have fallen victim of such attacks and have no clue still.

by axegon_

5/21/2026 at 2:42:34 PM

Ask for yourself; I'm keeping my sanity back with stuff from https://t3x.org and the like. Scheme with logic/DIscrete Math, the MInikanren and the Mini Prolog it's incredibily powerful.

by anthk

5/21/2026 at 2:00:57 PM

What are “vs code hooks” exactly? A search for that or “VSCode Hooks” isn’t turning up anything for me in Kagi or Google…

by pseudocomposer

5/21/2026 at 3:06:19 PM

I assume they are called hooks, .vscode/settings.json - you can put some linters/tests which run automatically (from my understanding, something similar to git hooks, hence the reason I called them hooks). I generally hate the concept and I generally dislike vscode so... yeah.

by axegon_

5/21/2026 at 2:40:03 PM

I assumed they are meaning VSCode plugins that "hook" into the system.

by AshamedBadger56

5/21/2026 at 10:41:58 AM

[dead]

by clownpenis_fart

5/21/2026 at 4:00:17 PM

> I can't understand how many devs are doing just that these days.

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.

by thewebguyd

5/22/2026 at 1:11:27 PM

> 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.

It's about more than lack of admin access. One uncomfortable truth I've realized over the course of my career is that the more IT "manages", the worse my computer becomes by basically any metric you can think of: stability, performance, predictability, inspectability. I've lost count of the number of times IT have broken things for me. Often, the security software they require itself has unacceptable, careless security flaws (e.g., hardcoded passwords, completely incorrect permissions checks).

Uptime of systems, even laptops, that I own can be measured in months. IT and security departments mandate the installation of so much downright shoddy software that they often end up requiring (sometimes formally!) weekly reboots just to keep the system "stable".

Frankly, I've yet to work at a company where IT or security has done what I would consider to be adequate testing of their own policies and tools. I have sadly learned down to my bones that each time I'm informed (if I'm ever informed!) that some new thing on my system will henceforth be "controlled" by some department that sees policies and standards as their mandate, no matter whether they have a "test group" that trials the stuff ahead of me or not, my system is about to permanently degrade. And more often than not, literally no one will be able to answer basic questions about the behavior of the system anymore, because the kind of people who buy and implement turnkey corporate IT solutions don't really know much about what that software does. (After all, not having to really know what it does is the whole selling point of such solutions.)

by isityettime

5/21/2026 at 10:47:36 AM

Never underestimate the power of procastination disguised as productivity!

by keyle

5/21/2026 at 10:55:43 AM

It's stupid but understandable. Be it browsers or IDEs they lack much needed functionality but instead of completing their products so they can be used productively out of the box, they outsource this to the community and call it a feature. Doesn't matter how good your bug fixing and security policies are if you allow basically everyone to circumvent it. In a nutshell Microsoft is lazy. Don't use their products and beware of the extension/module creep elsewhere.

by emsign

5/21/2026 at 11:15:38 AM

Because you need to install things to get things done. In the world of perfect security and order it's impossible to get anything done, much the same as it's impossible to do in complete chaos.

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.

by locallost

5/21/2026 at 12:31:27 PM

Did work for a company last week that get popped pretty badly during a round of Shai even though they were aware of the packages.

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.

by ofjcihen

5/22/2026 at 6:17:44 AM

In AI era the way to install software is to pass a random script from internet to shell with sudo privileges.

Thats enough to see how much AI crowd cares about security.

by pojzon

5/21/2026 at 1:27:12 PM

So you've been telling companies to stop using CI/CD too right?

by casey2

5/21/2026 at 8:40:00 AM

There is a Feature request from 2018 that I have been following for a long time to ask for VSCode Sadbox. I do not understand how Microsoft is not putting it up in priority.

https://github.com/microsoft/vscode/issues/52116

by jakemm

5/21/2026 at 9:42:35 AM

"VSCode Sadbox" -- pun intended or not, that's funny :-)

by xeyownt

5/21/2026 at 11:46:46 AM

Sandbox alone isn't sufficient because when loading a malicious extension into a session you might be exposing your environment variables to it. You also need explicit permissions, so that only relevant extensions can access secrets like this.

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.

by gchamonlive

5/21/2026 at 3:52:44 PM

Sufficient for what? It's sufficient for preventing an extension from accessing tokens on my filesystem, from connecting to arbitrary networks, stealing my browser session cookies, etc. It's sufficient for a fucking lot.

This is how browsers have been doing things for 20 years, it's ridiculous that a company worth billions isn't doing it.

by insanitybit

5/22/2026 at 6:23:33 PM

Sadly the LSP pattern means that most extensions launch their own process so there's limited sandboxing options there. Sure not every extension needs its own process, but if most of them do then there's very limited benefit from permissions or sandboxing. As nice as the LSP is, the design basically means any IDE wanting to use common ones need to let extensions include and start their own processes.

by hahn-kev

5/21/2026 at 10:58:56 AM

On one hand yes, sandbox everything. On the other the extensions still can change your code which you then run. Though you might only run it in a container at first.

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

by panzi

5/21/2026 at 11:43:20 AM

Sandboxing doesn't necessarily mean isolating the extension from all potentially dangerous functions, you can have a permission system so that for example a color theme extension can't modify files.

by HighGoldstein

5/21/2026 at 3:54:05 PM

Not every extension needs the ability to change your code, let alone change it without user interaction - similar to how iframe sandboxing can allow top level page navigations with user consent.

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.

by insanitybit

5/21/2026 at 5:51:46 AM

The security model, or almost lack of any whatsoever in VSCode drove me to only install MSFT extensions, then use Code Server in a docker container, but I decided I didn’t like using my editor in a browser.

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.

by camkego

5/21/2026 at 6:32:55 AM

Wait, how do you arrive at the thought that Zed is more secure? The one time I gave it a try, it tried to silently run npm -- yes, THIS[1] npm -- in the background without telling me, and I noped the heck out. Did I miss something?

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

by Balinares

5/21/2026 at 7:59:11 AM

Maybe I am wrong about this, but I think Zed will run the npm stuff on the dev-container if you are using dev-containers. That can be your isolated virtual machine image or docker instances. But I believe you do need to use Zed (stdio or ssh) dev containers to get that security isolation. I know it’s a pain, but for me, I am going to pay the logistics price for security until a better solution comes along.

by camkego

5/21/2026 at 3:56:36 PM

Zed plugins execute in wasm. LSPs execute outside of any sandbox, but that's still an obvious win. Your link isn't particularly relevant to an LSP unless the LSP itself is compromised.

Hopefully the system matures with time, but at least they're taking the problem seriously.

by insanitybit

5/21/2026 at 3:41:09 PM

Not defending the default behavior of zed, but it is possible to disable this. Setting `"lsp.<server>.binary.path": <some-path>` will stop zed from trying to install that server.

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.

by nbf_1995

5/21/2026 at 6:38:27 AM

Pretty sure any IDE worth anything that has JS support pulls NPM packages at some point to lint code, no? You're not giving me much to be outraged about without more information. Zed tries to set things up for you so you're not wasting hours trying to figure out how to set them up in a brand new editor.

by giancarlostoro

5/21/2026 at 12:07:50 PM

I do not use JS and certainly was not doing anything JS-related, and I do very much not expect my tooling to silently run code from insecure Internet sources on my machine. Which does not seem like an outlandish position to me? If you consider that acceptable, yourself -- fair enough, that's your call and it's your machine, but let's please not label that anything but grossly insecure?

by Balinares

5/21/2026 at 6:49:10 AM

No doubt an unpopular opinion, but if I install an app that is going to do things in the background, I'm going to hold that apps developers responsible for any breaches. If Zed needs javascript to do its job, it probably should be downloading it from their own servers, or even better, just ship the editor with all the code it needs to do its job.

by jay_kyburz

5/21/2026 at 9:19:06 AM

Yes, please ship everything that's needed because otherwise when I run your app in an isolated network namespace it will break. This also applies to builds. If I can't build your project from a clean git repo without internet access you are doing something wrong. (Yes I am aware that I likely just accused the majority of software devs of being wrong. I don't care I'm yelling at clouds here.)

by fc417fc802

5/21/2026 at 6:54:29 AM

I don't have node running on my pc, I either put it in a container or i don't use it.

Software that is mostly an electron app. I start using my browser for a web edition, or run it in a container/sandbox!

by srcoder

5/21/2026 at 9:02:36 AM

I think we reached the point where it's not reasonable to expect that Microsoft is capable of improving anything. Their products all go in the same direction.

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.

by miroljub

5/21/2026 at 7:53:10 AM

>The security model

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...

by aa-jv

5/21/2026 at 8:48:55 AM

I'm also currently trying to switch from VS Code to Zed and my biggest hope was a better performing editor. The startup time is way better but the typing input is so laggy on my 2018 MacBook Pro 15". It's far worse than VS Code. Also the power usage of Zed is high.

by zuhsetaqi

5/21/2026 at 11:08:19 AM

If it uses npm plugins, it's the same crap you get with vscode, just with a rust facade.

by coldtea

5/21/2026 at 3:56:11 PM

Zed plugins are wasm / somewhat isolated. LSPs are not sandboxed, but that's a massive reduction - trusting the LSP is far different from trusting arbitrary extensions.

The system is immature but it's directionally correct.

by insanitybit

5/21/2026 at 1:03:21 PM

Is helix too minimalist? No js, just rust and tree sitter queries. Full lsp integration and everything just works.

by galangalalgol

5/21/2026 at 1:20:35 PM

FWIW VScode can be used in a docker container or remote server from the local client. See devcontainers and VSCode over ssh.

by mfro

5/21/2026 at 4:43:06 PM

At least some of your extensions will still run in the client editor instance, not on the server side. That limits exposure a bit but when colour themes have been known attack vectors in VSCode it’s far from a panacea.

by jon-wood

5/21/2026 at 7:44:02 AM

> … use Code Server in a docker container …

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

by no-name-here

5/26/2026 at 6:10:05 AM

most likely - used this for 6 months before dropping vs code and loved it if you don't mind using the browser

by rrvsh

5/21/2026 at 11:43:30 AM

> I hope Zed continues to improve their extension and language server security model.

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.

by IshKebab

5/21/2026 at 12:37:33 PM

Running binaries I already have installed in a containerized environment is fine, automatically installing them on host machine and/or container is not.

I should be able to limit what binaries extensions have access to though.

by notnullorvoid

5/20/2026 at 8:16:12 PM

I really hope this pushes Microsoft to add a explicit permission system to VS Code extensions, and improve security of dev containers.

by notnullorvoid

5/20/2026 at 10:17:30 PM

I really hope this pushes users (here: devs and maintainers) to decrease their reliance on Microsoft and especially stop outsourcing security to them.

Migrate off vscode already.

by pamcake

5/20/2026 at 10:46:30 PM

I won't say "you can take my VS Code from cold dead hands" or anything, but it is a very good tool, and Microsoft hasn't yet fucked it up the way they have so many other things.

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)".

by hungryhobbit

5/21/2026 at 12:20:35 AM

> Microsoft hasn't yet fucked it up the way they have so many other things.

Not for lack of trying, the amount of CoPilot cruft bundled with the core IDE is growing quarterly.

by overfeed

5/21/2026 at 12:58:40 AM

Seriously. I think I saw they just added another “please use the agent chats here!” button.

Every updates release notes is like 90% “now with more copilot plz use it.”

by dd8601fn

5/21/2026 at 8:16:05 AM

Sir Copealot a noble knight whose services remained unwanted.

by 21asdffdsa12

5/21/2026 at 8:37:38 AM

they pushed copilot too far.

by shideneyu

5/21/2026 at 8:14:53 AM

Makes me wish, we could just have some "Metric" sin-goat, that is basically some nonsense fork of the project, that the process can ruin for "promotion" crystals or whatever, while the actual project runs unaffected on in the background.

by 21asdffdsa12

5/20/2026 at 11:35:20 PM

Vs code is a weapon, designed to fracture. It being “good” is a weapon as well. https://ghuntley.com/fracture/

by loloquwowndueo

5/21/2026 at 5:23:12 AM

That seems like a very, very long-winded way of accusing them of "embrace, extend, extinguish"? Which is obviously not falsifiable, but just feels a bit trite at this point, IMO.

by kristiandupont

5/21/2026 at 11:11:52 AM

>Which is obviously not falsifiable

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?

by coldtea

5/21/2026 at 7:55:31 AM

Its trite until you have to explain to your boss why your editor brought down the business.

by aa-jv

5/21/2026 at 8:38:44 AM

Things feeling trite isn't a counterargument, though.

by philipallstar

5/21/2026 at 7:55:03 AM

>Microsoft hasn't yet fucked it up

I beg to differ. Have you inspected its network traffic?

by aa-jv

5/21/2026 at 8:39:18 AM

can you develop ?

by shideneyu

5/21/2026 at 11:18:16 AM

Can I develop without using tools that snoop on my private system and exfiltrate data while I'm trying to develop?

Yes, very definitely.

Can you?

by aa-jv

5/21/2026 at 12:34:46 AM

Did you try intellij ever?

And are you a vscode original? or came from vim/emacs?

by iririririr

5/20/2026 at 11:16:04 PM

[dead]

by sieabahlpark

5/20/2026 at 10:55:18 PM

> Migrate off vscode already.

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.

by ajross

5/21/2026 at 5:46:54 AM

> Any extensible, customizable display editor can be coerced into behaving badly by installing external code.

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.

by skydhash

5/21/2026 at 9:35:32 AM

I like neovim but I am under no illusion that plugins developers would be more conscious about security. The thing is there is no marketplace so it is less easy to make your plugin suddently advertised and installed by thousands of people without having a killer feature.

by prmoustache

5/21/2026 at 11:31:52 AM

To hijack a vim plugin/emacs package, you would have to take over the repo. Or take over elpa/melpa (for emacs) or vim awesome (to redirect users to your malicious repo). Both are way tricker than the exploitation tactics used on JS based projects.

by skydhash

5/20/2026 at 11:25:39 PM

The problem is not VS code itself. It's the fact extensions can access things outside of the editor. As far as I am aware, no editor sandboxes extensions.

by Gigachad

5/21/2026 at 12:20:52 AM

Part of the problem is that people are adding a metric fuck ton of extensions onto a text editor trying to make it into an IDE.

If you start with an IDE first you likely need far fewer extensions.

by stephenr

5/21/2026 at 7:56:15 AM

How about just don't become dependent on an IDE and don't use technologies which require that dependency...

by aa-jv

5/21/2026 at 8:04:06 AM

Good point. Any editor is a needless dependency.

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.

by stephenr

5/21/2026 at 8:26:25 AM

Ah, good old 'M-x scream-into-void'. My most-used Emacs feature after 'M-x butterfly'.

by tmtvl

5/21/2026 at 11:10:37 AM

True developers don't leak the keys to their sources just because they need convenience-features from a "free IDE with tons of sexy bells and whistles" ..

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.

by aa-jv

5/21/2026 at 2:30:13 PM

Your comment implies that you've somehow misunderstood my comments and thus think that I am using Microsoft's hot garbage text editor with a million plugins.

I can assure you I am not.

by stephenr

5/21/2026 at 3:06:12 PM

Your comment came across as sarcasm directed at aa-jv's position that folks are lured into the VSCode abyss and stay there because their comfort level won't let them leave, while VSCode - meanwhile - continues to be a huge security liability for any project where it is used.

by rigonkulous

5/21/2026 at 3:43:32 PM

... the only sarcasm I posted was about screaming at the universe in response to his suggestion that the only alternative to people loading up a text editor with a million shonky plugins to try and make it an IDE, is to eschew all IDEs.

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.

by stephenr

5/22/2026 at 8:45:08 AM

Well your point didn't come across at all, just sayin'.

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.

by rigonkulous

5/20/2026 at 10:32:41 PM

> 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.

by notnullorvoid

5/21/2026 at 4:42:21 AM

Let me save you some hassle. I test drove Zed for a week after the v1.0 release. My projects deal exclusively in dev containers. I spent more time troubleshooting issues than actually working. Things which VS Code handles transparently, like installing the support libraries to run a chrome debug session, say. Your local SSH agent isn’t forwarded into the container, so git push doesn’t work natively. That’s after you’ve had to add your project as a safe directory in your container’s git config, because it isn’t mapped to your local git config. Things which I was disappointed and surprised were not addressed prior to v1.

by -iad

5/21/2026 at 12:11:49 PM

Thanks, after seeing this and others talk about it silently installing node and other tools that's enough for me to dismiss it as a viable option.

by notnullorvoid

5/21/2026 at 2:57:04 AM

Zed is even worse about arbitrarily downloading random stuff from random websites and executing it

by TiredOfLife

5/21/2026 at 3:20:21 AM

How so?

Part of what seemed good about Zed was that extensions have explicit permission controls.

by notnullorvoid

5/21/2026 at 3:33:48 PM

It will auto-install and configure any LSPs that it thinks is suitable for the code you're working on. Found that out the hard way when a new experimental Elixir LSP got added which conflicted badly with my existing installed one

by sevenseacat

5/21/2026 at 10:19:18 AM

There's nothing really special about VSCode here, except that it's really popular. You could just as easily attack Emacs or Vim or Sublime or [...] users by distributing a malicious extension.

by simiones

5/21/2026 at 11:53:52 AM

You can’t attack them that easily because of the different publication method. Emacs, Vim, and Sublime have a pull model (like linux distros), not a push model. Meaning you add your repos to the package hub, you do not upload an archive to them. The Hub will pull in you changes (or the plugin manager will do so). The only way in is to take over the repo itself.

by skydhash

5/21/2026 at 2:55:29 PM

Not sure how Vim and Sublime work, but for Emacs, publishing to MELPA is absolutely a push process, where you open a PR to MELPA's repo with a recipe for your new package; and, once it's accepted, every commit to your repo results in a new package build on MELPA's servers that Emacs users will get when they update / install the new plugin.

by simiones

5/21/2026 at 3:21:22 PM

It’s not. The developer never build a package and then upload on melpa. Melpa will fetch the needed files and build the package. It’s not truly secure, but an attacker would need to publish a new commit and wait for quite some time for people to update.

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.

by skydhash

5/21/2026 at 3:37:26 PM

My point is, if I want to create a malicious Emacs plugin, I can do the following:

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.

by simiones

5/21/2026 at 4:01:57 PM

> 2. Wait for people to pick up this new extension, while it's still benign

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.

by skydhash

5/21/2026 at 4:13:54 PM

Sure, but this is just an accident of Emacs being a much more niche product, not related in any way to the design of the package system. If Emacs suddenly gained VSCode's popularity, I can assure you that numerous new users would simply look through MELPA and pick up packages that sound useful, and quickly end up picking up malware - nothing in Emacs prevents this any more than VSCode.

by simiones

5/21/2026 at 4:36:35 PM

> I can assure you that numerous new users would simply look through MELPA and pick up packages that sound useful, and quickly end up picking up malware

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.

[0]: https://melpa.org/#/magit

by skydhash

5/22/2026 at 9:17:58 AM

Transparent doesn't mean secure. The very source of this issue was a recent NPM supply-chain attack, and you can also check the sources of any NPM package that you use. NPM also relies on peer dependencies, and this is exactly why malware spreads so efficiently in the ecosystem - just like it helps spread bug fixes, it also helps spread malware as efficiently.

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).

by simiones

5/20/2026 at 11:28:23 PM

Emacs has been a viable option for going on a half century now. The GNU Emacs 31 branch[0] was cut recently and is barreling towards a new release. It might be time to give it another look.

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

by spudlyo

5/21/2026 at 8:01:17 AM

Sure. Microsoft will spin up a "SuPeR AI AgEnT" that will "fix" the issue. As an added benefit, it will officially promote Edge and Win 11 ( or K2 )

by panchtatvam

5/21/2026 at 8:40:16 AM

It is said that these agents make one 100x more productive by some accounts. Microsoft is big on AI agents.

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?

by 0xpgm

5/20/2026 at 8:19:52 PM

Not holding my breath. This issue has been open since 2018 https://github.com/microsoft/vscode/issues/52116

by fg137

5/20/2026 at 9:01:27 PM

Yeah, the only thing that gives me hope is the optics of this happening to GitHub. Though it seems possible VS Code team could double down on the opinion that this isn't a permission/sandboxing problem, and is instead a scanning/threat detection problem.

by notnullorvoid

5/21/2026 at 1:34:34 PM

Oh, you mean like only extensions approved by MS can be published? Similarly to Google, Apple, Mozilla and others?

by deely3

5/21/2026 at 8:43:46 PM

No I don't mean like that. Explicit permissions control what the extension can do, similar to websites needing explicit permission to access a users camera. An example is a theme extension with permission to change the theme, but having neither permission to run scripts/executables, nor dynamically access the filesystem.

There's no connection to authoritative approval, other than making ecosystems without or without that kind of strict approval safer.

by notnullorvoid

5/21/2026 at 9:29:25 AM

Before I say anything: I don't use VSCode and have no intention of doing so. Most of my experience is gained vicariously, through working with or helping someone else who does.

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).

by crabbone

5/21/2026 at 10:19:49 AM

> 1. Users learn to use their tools.

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.

by mschuster91

5/21/2026 at 1:09:00 PM

> That Just Won't Happen.

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.

by crabbone

5/20/2026 at 10:15:28 PM

Vs code extensions have been terrifying for a long time. Such a wild and obvious attack vector. I'm constantly getting pop ups in vscode to install an extension because it recognizes a certain file type. It's 50-50 whether that extension is owned by a company or some random dev. Some of these have millions of installs and on first glance appear to be official company owned extensions. I'm at a point in my life where I only installed official company owned extensions and even that is hard to be sure I'm not getting suckered. Sad state.

by mcoliver

5/20/2026 at 11:24:26 PM

The problem extends far beyond VS code. All extensions and executable code has the same problem. There was a case where Disney was hacked because an employee installed a BeamNG mod that had bundled malware.

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.

by Gigachad

5/21/2026 at 12:45:40 AM

Running code isn't the problem. The fact that (almost) all code runs at the same security level is.

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.

by miki123211

5/21/2026 at 1:11:34 AM

Fully agree with the first half of your comment. The second half goes off the rails, though.

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.

by atq2119

5/21/2026 at 2:03:01 AM

Agreed. What's frustrating is that we have models for how sandboxing can work and instead of investing efforts into nailing that experience, the OS providers are prone to turning it into a monetization/lock in layer instead. My VLC and VS Code should have an OS native way of being limited to particular functionality. But when the OS providers implement the sandbox, they center it around an App Store and restrictions on only apps that have been notarized where said notorization costs money or a requires a subscription. And then they remove the ability to do things which their own native apps can do and set tighter controlling rules on what APIs apps can ever have access to.

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.

by nstart

5/21/2026 at 2:41:39 AM

That exists on linux under flatpak, but it requires Wayland and Pipewire. Also many packages just request full system permissions rather than update to work in a sandbox.

It's in the works and one day we will have it but progress is slow.

by Gigachad

5/21/2026 at 5:36:00 AM

I really like openbsd's pledge. It's nice when you look at the code and see the program restrict itself to a smaller set of operations. Not everything in ports has adopted it, and the point is moot for closed source. But for the latter, VM and an isolated segment would be the proper solutions.

by skydhash

5/21/2026 at 10:25:53 AM

> My VLC and VS Code should have an OS native way of being limited to particular functionality.

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.

by mschuster91

5/21/2026 at 12:06:50 PM

A viable strategy is something like qubeos for isolating activities from each other. You can have a media vm, a dev vm, a bank vm, and a password/manager vm. Or you use different computers.

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).

by skydhash

5/21/2026 at 7:00:52 AM

As a "gun nut of tech", I have resolved this issue for myself with two computing categories for hardware I use: Hardware-I-trust and Hardware-someone-else-trusts. Sometimes these share information, and have to interact. Usually I am the one who decides how. Smartphones have never been in the category of "Hardware-I-Trust". For the first time in a long while my current employer paid for hardware is in that category for reasons of my own.

by dingdongditchme

5/21/2026 at 6:45:23 AM

> Yet, if we advocate for sandboxing in more places

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

by swiftcoder

5/21/2026 at 2:59:35 AM

Never let a crisis go to waste, huh?

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.

by salawat

5/21/2026 at 6:42:21 AM

> 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.

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.

by hnlmorg

5/21/2026 at 8:51:41 AM

This is about as useful as telling people to read the full terms of services of everything they use. That might be easier than auditing every line of code you run.

I’ll tell my employer to put the feature on hold for 20 years while I read the source of every package.

by Gigachad

5/21/2026 at 8:14:24 AM

Yes, because sandboxing gets us unusable OS like iOS or Android. It isn't a solution. Perhaps the gun nuts are right then. Better be a gun nut than a Google employee, probably.

by raxxorraxor

5/21/2026 at 3:29:41 PM

In what way is Android unusable?

by antiframe

5/21/2026 at 4:58:28 AM

Funnily enough a lot of this "extension sprawl" is caused by the _difficulty_ of installing tools on locked down Windows machines. I recently moved to a locked down SoE and instead of being able to use regular tools (which require a lengthy negotiation process to install) I now use extensions for absolutely everything, _because_ they're not currently policed in the same way...

by xyzzy123

5/21/2026 at 6:09:26 AM

At my last workplace I was not allowed to install JSON viewer/prettier extension for my browser, but I was allowed to install VScode with random JSON plugins.

by ihateolives

5/21/2026 at 8:36:36 AM

I see the same thing. Similar for PyPI and NPM registry actually.

by 3form

5/21/2026 at 12:13:17 AM

I don’t understand why we don’t just sandbox everything. We have done it for web browsers, we can definitely do it for VSCode extensions.

by charlieyu1

5/21/2026 at 12:32:32 AM

What are you withholding from the sandbox without making it useless?

by inlined

5/21/2026 at 1:11:53 AM

Internet access. An editor extension does not need it.

by atq2119

5/21/2026 at 4:55:06 AM

Most sandbox systems today, take seatbelt from Apple for instance, only strip permissions. If your extensions without internet access calls a tool that needs it, boom access denied or worse, weird network issues.

One would need some kind of ring system where less privileged processes can call higher privileged processes with their own sandbox permissions.

by larusso

5/21/2026 at 6:41:17 PM

Sure, that's the main challenge with building good sandboxing systems. But it's not actually that hard to do when the will to do it is there.

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.

by atq2119

5/21/2026 at 5:52:17 AM

Let the user grant permissions at install time. An error is a success in this scenario.

by therealdrag0

5/21/2026 at 1:34:30 AM

All AI agent extensions disagree in unison.

by sedatk

5/21/2026 at 5:59:23 AM

It could request access to a specific domain which you can approve or deny

by californical

5/21/2026 at 2:21:52 AM

Because it's hard to create a system that is both sandboxed and powerful. You can't have an extension system that allows a plugin to run a locally installed linter or view the status of docker containers but can't execute something malicious.

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.

by Gigachad

5/21/2026 at 5:22:28 AM

> You can't have an extension system that (...)

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".

by moring

5/21/2026 at 5:42:52 AM

I don’t know what linters you use, but the ones I like are the ones that show you problems in the workspace stably, not just in the files that happen to be open and altering as files open and close.

You can always improve, but pretending like there’s an easy solution is lazy - if it was easy it would have been done.

by vlovich123

5/21/2026 at 6:47:57 AM

This was bad wording on my part. I wrote "open" but that should have been "files in the workspace/project". Really, "open" WRT files is so overloaded already, they can be in the workspace, have an editor tab open for them, or have an active file handle, to name just three.

> 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.

by moring

5/21/2026 at 4:30:24 PM

Im highlighting that defining that sandbox policy cohesively in a way that works for all the different extensions types you’d want to support and doesn’t overwhelm the user with permission fatigue is difficult as to be impossible.

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.

by vlovich123

5/21/2026 at 6:24:45 AM

These kinds of permissions lists have been mostly a failure in history. Users see a massive list of permissions, or permissions constantly changing between updates and just ignore them because there’s no way to reasonably audit them or take any action on them.

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.

by Gigachad

5/21/2026 at 6:46:13 AM

Ideally, the permission list is meant for curators which end-users trust and can rely on.

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.

by moring

5/21/2026 at 8:53:07 AM

Most of the recent compromises have been from trusted people who had their accounts compromised. So just picking someone you trust doesn’t work out.

by Gigachad

5/21/2026 at 7:03:32 AM

I don’t know, we got rid of things like CGI and Java Applets for web but things are still useful enough

by charlieyu1

5/21/2026 at 6:19:22 AM

The shit show that's called lastpass, which I unfortunately know, was hacked because a developer installed a bad version of Plex Media Server on his work computer.

by yard2010

5/21/2026 at 12:23:54 AM

I've become equally paranoid about VSCode extensions. I remember using several other IDE's like Brackets, JetBrains, Sublime Text or Bluefish only having a few solid extensions to rely on to get my dev work done. Now it seems like anything you do, someone or some company has built an extension specifically for your task.

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.

by at-fates-hands

5/20/2026 at 11:51:49 PM

About the level of security in software I expect from the vendor who came up with “screenshotting your desktop every few seconds, OCRing those, and dumping the results to disk unencrypted in plain text”

by ToucanLoucan

5/21/2026 at 1:05:15 AM

I've stayed with Sublime, often to the derision of VSCode addicts. I love to see the "VSCode is perfect" uncritical thinkers get theirs.

by cwnyth

5/21/2026 at 6:43:07 AM

Sublime also has packages. https://packagecontrol.io

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.)

by no-name-here

5/21/2026 at 6:59:11 AM

I was feeling like sneering as well about how my emacs setup never caused any issues until I remembered emacs packages have zero protection whatsoever and can run anything anywhere, are ALL authored by some guy in Nebraska or Slovakia or something in their spare time :) but we don’t see any attacks since there’s so few of us still using emacs.

by brabel

5/21/2026 at 5:57:12 AM

I don't use VSCode, but doesn't their plugin ecosystem indicate if the plugin is MSFT-approved?

by wyclif

5/21/2026 at 6:23:23 AM

I'm guessing you're referring to the "Verified Publisher" blue checkmark next to the publisher's name and domain name, which proves the publisher owns the domain name and has 6+ months in the marketplace? https://code.visualstudio.com/docs/configure/extensions/exte...

(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 )

by no-name-here

5/21/2026 at 6:07:13 AM

That just means the domain was verified which costs like 10 bucks.

by csomar

5/21/2026 at 1:09:01 AM

And they all want to auto-update, too.

by xgulfie

5/20/2026 at 9:46:23 PM

I wonder if this was the compromised nx console extension that bit me yesterday. The timing seems identical. See https://github.com/nrwl/nx-console/security/advisories/GHSA-...

by urbandw311er

5/20/2026 at 10:09:17 PM

GitHub confirmed that it's indeed the nx console extension, in their blog post: https://github.blog/security/investigating-unauthorized-acce...

by K3UL

5/21/2026 at 9:38:30 PM

Nrwl are right to be sceptical about Microsoft’s published download numbers for the compromised extension. Given that my machine downloaded it a full two hours after it was supposedly unpublished.

by urbandw311er

5/20/2026 at 7:45:04 PM

Note that VS Code is built on Electron and it is a pain to sandbox because Electron has (had?) SUID sandbox helper, and you cannot run SUID binaries in sandbox easily. Sandboxing on Linux is extremely difficult task.

by codedokode

5/20/2026 at 7:55:01 PM

It feels so bad to see the "You need go give Chrome SUID Root for the sandbox to work". Setting a Web Browser SUID Root was an old joke about clueless users. It was the worst security screwup someone could imagine.

by jandrese

5/20/2026 at 8:27:11 PM

podman seems to handle rootless namespaces just fine, minor caveat for some perf overhead but it's not the end of the world.

by duped

5/20/2026 at 8:48:10 PM

And volumes. Volumes are not fun with podman. Ironically my team tried GitHub Codespaces and never looked back. Super cheap and uses DevContainers.

by internet101010

5/20/2026 at 10:21:03 PM

What's the difference between Podman and docker for volumes? Other than needing to add Z to get volumes to mount with SELinux

by unethical_ban

5/21/2026 at 12:49:55 AM

If you're root on a system and use Docker volumes, you can always `sudo ls` and access those volumes outside of the container.

If you're just a user running containers under Podman, it's more tricky.

by miki123211

5/21/2026 at 3:52:21 AM

`podman unshare && podman mount`

by GCUMstlyHarmls

5/21/2026 at 12:25:12 AM

Maybe permissions when going rootlesz?

by NewJazz

5/20/2026 at 9:52:01 PM

Don't build your ide on electron then.

by NewJazz

5/21/2026 at 3:06:43 PM

Electron was invented to build an IDE on.

by varun_ch

5/21/2026 at 7:02:25 PM

Nothing about that guarantees that it is suitable to the purpose

by HappMacDonald

5/21/2026 at 11:46:10 AM

> Sandboxing on Linux is extremely difficult task.

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

by IshKebab

5/21/2026 at 1:20:44 PM

With no disrespect to the Linux kernel programmers who are vastly better than I’ll ever be.

Plan 9 was designed, Linux accreted.

by noir_lord

5/20/2026 at 7:44:37 PM

Maybe I'm missing something really obvious, but... 3,800 repos? I guess I find it kind of surprising they have that many!

by tekacs

5/20/2026 at 8:18:53 PM

As others have said it's just a fraction. I'm in a medium size tech-related company and we have 7500+ in one Github org. We have two orgs, so altogether easily 10K+. Of course most of it is stale, obsolete, sandbox, personal tools, etc. I wouldn't be surprised if Github would have 100K+ internal repos or even more.

by PAndreew

5/20/2026 at 9:15:35 PM

no pruning of repos?

by htrp

5/20/2026 at 9:30:17 PM

No OP but I used to work at a large company with a similar number of repos.

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.

by sbarre

5/20/2026 at 10:54:01 PM

This is a continual fight for me. At nearly every company I've had to compromise on using a graveyard repo for packages within a monorepo, even though git has the whole history already.

by a_t48

5/21/2026 at 6:44:36 AM

The problem with history is that you need to know when to look. If you're looking for some old code that you know existed but you don't know exactly what it was, you can't just browse to go and find it.

by Sander_Marechal

5/21/2026 at 6:57:53 AM

Sure, but beyond a certain point the code that's there isn't just drop in compatible.

by a_t48

5/20/2026 at 9:52:53 PM

Gitlab is so nice for this. You can group repos together so it is harder to lose track of stale projects.

by NewJazz

5/20/2026 at 10:15:07 PM

Breaks old stuff

by fn-mote

5/20/2026 at 8:35:13 PM

I worked for a food retail store once. I remember going in the first day wondering, how hard can it really be... From the outside, it looks like they have a simple website. The website to order things on was an amalgamation of 300+ repo's. GitHub lost less in this breach. It takes a lot of effort to keep things simple as you grow.

by philipp-gayret

5/20/2026 at 10:03:47 PM

Can confirm as someone working in the same field, we have a ton of repos

by robotnikman

5/20/2026 at 8:39:59 PM

Uber had 8000 repos at one point with 2000 engineers - https://highscalability.com/lessons-learned-from-scaling-ube...

by ashishb

5/20/2026 at 11:27:48 PM

Probably most of them are forks of some public repo with some patch applied and half of those are probably not even used internally anymore.

by Gigachad

5/21/2026 at 1:01:14 AM

Afaik, they eventually cleaned it up.

And it was each team owning multiple internal repos of their own deployments/libraries, and not, primarily, clones of public repos.

by ashishb

5/20/2026 at 10:21:02 PM

Something cool that I've always liked about working at GitHub is how much of the company _runs on GitHub_ -- A lot of teams, even non-technical teams, have their own repos just to organize docs/SOP's/designs/etc like a traditional knowledge work company might use a Sharepoint

by ryanhecht

5/20/2026 at 8:01:33 PM

Personally I have over a hundred, especially from quick prototypes, studies or instances of templates so I can easily see how over 18 years and many hundreds of employees you end up with thousands.

by tempay

5/20/2026 at 7:57:54 PM

3800 is low for an org like GitHub. Glad it’s highly likely not all their repos are compromised.

by MrDarcy

5/20/2026 at 8:34:00 PM

Given the attack vector, it's possible that the impacted repos were ones that see more activity.

by organsnyder

5/21/2026 at 1:34:57 AM

I remember working at a company with at least 5,000 repos across five or six GitHub orgs, plus more stuff in Perforce.

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).

by jamesfinlayson

5/20/2026 at 8:01:16 PM

I was part of an org with more than 15k repos

by dgellow

5/21/2026 at 5:53:44 AM

Damn that's alot. I'm wondering how many engineers handled all that?

by clutch_coder99

5/21/2026 at 7:08:18 AM

I cannot share much details, but one thing: livegrep had no issues handling that many repos! That project is such a blessing

https://github.com/livegrep/livegrep

by dgellow

5/21/2026 at 7:05:07 AM

That was my first instinct, but thinking about it just a little it doesn't seem crazy, esp for GitHub.

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!

by dirkc

5/20/2026 at 8:00:59 PM

It sounds low to me, I worked at a Fortune high number a few years ago and they had more.

by newsoftheday

5/20/2026 at 8:50:38 PM

In my personal experience, give it a decade or two, and any corporation will accumulate hundreds (or even thousands) of abandoned internal repos containing discontinued services, POCs/prototypes that never went anywhere, etc – people forget to archive them, or aren't sure whether something is still in use or not so err on the safe side.

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.

by skissane

5/20/2026 at 8:57:39 PM

Maybe though AI will make it better, assign agents to monitor, maintain and keep repos up to date or via A2A refer them to an agent to dispose of them in accordance with company requirements. I actually think AI will greatly help this type of problem.

by unix4ever

5/20/2026 at 10:26:35 PM

Autoarchiving repos which nobody has used in X years doesn’t require any AI - you can just write a bot to do it. People don’t, because it isn’t a priority. AI can make writing such a bot a bit easier, but can’t help much with getting approval from the powers that be to run it.

by skissane

5/21/2026 at 5:07:37 AM

Even their sales teams work with GitHub repos, so not that surprising I’d say.

by wazHFsRy

5/20/2026 at 8:27:47 PM

They have 800 engineers. So 3,800 repos is high, but not crazy.

Some of those could be forks.

by paulddraper

5/20/2026 at 8:00:04 PM

really? I mean these are internal repos. Probably most of them are random one-off experiments or a place to park code. Google has 2,900 "public" repos on github. Microsoft has ~8k "public" on github too. Can't even imagine how many they have on their internal systems.

by eddythompson80

5/20/2026 at 8:08:50 PM

Am I missing the joke here... they have hundreds of millions of repos.

by noelsusman

5/20/2026 at 8:12:30 PM

I think they mean that these are internal github-org repos.

The ones used for running the site itself.

Though, its so many that i think there are some customer ones in there too.

by dijit

5/20/2026 at 8:14:40 PM

No, there's no joke, you might have just misread the article (the 3,800 number is the number of internal GitHub repos the employee had downloaded on their personal computer / had access to on their own GitHub account)

by nightpool

5/20/2026 at 8:13:08 PM

The breach is about internal repositories, not user repositories.

by Galanwe

5/21/2026 at 8:20:47 AM

Because everything in Github is designed for growth: Easy to create a repo, very hard to delete it (a lot of scrolling, clicking, copy/pasting the full name of the repo, etc.) I mean "Deleting", not "Archiving".

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.

by sunshine-o

5/21/2026 at 12:05:08 PM

In addition, we need a fundamental change in OS security. It's not OK that every application you run has access to all your files and unfiltered internet access by default.

by felooboolooomba

5/21/2026 at 12:27:49 PM

Security mechanisms in most operating systems are good and has continued to evolve rapidly. I would say in Linux there might be too many and this is where the confusion come from.

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?

by sunshine-o

5/21/2026 at 4:02:35 PM

Just prevent VS Code from accessing the entire $HOME.

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.

by AlienRobot

5/21/2026 at 4:54:59 PM

For linux we have bubblewrap, firejail, apparmor and selinux (popular ones, there are far more). But it is often complicated and annoying to set up. Normally one would expect sw developers would write security rules for their apps but it is difficult due to amount of different sandboxing tools and various distro-specific configuration changes.

It would be nice to have it sorted out somehow. Actually Snap is an interesting example of something done in that regard.

by neop1x

5/21/2026 at 5:30:44 PM

Yes, and I wish Linux developers would see their own hypocrisy.

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.

by AlienRobot

5/22/2026 at 10:37:36 AM

Don’t forget that Linux is Unix inspired. And unix were meant to be used on servers and mainframe where root were used by a trained sysadmin. Users were not meant to install applications, and their actions has little impact on the system integrity (if they’re not actively attacking it)

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.

by skydhash

5/21/2026 at 11:34:02 PM

Don't forget user accounts!

by nurple

5/21/2026 at 3:03:57 PM

I’ve been using Little Snitch on my Mac for years now because I want to be aware of (and be able to turn off) the connections programs make. Probably the weirdest one I’ve caught was a new seagate hdd that required you to run an executable file to be able to format the drive, which then tried to connect to baidu.

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

by lukewrites

5/22/2026 at 5:45:25 AM

It's so noisy though because of apps' built in update checks and other legitimate things initially, which you then grant a process exception for. Per destination allow rules would also generate a lot of popups. Then the user just grants exceptions for all traffic or suffers alert fatigue

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

by gib444

5/20/2026 at 9:20:34 PM

That's one way to make things open source.

by cdrnsf

5/21/2026 at 1:02:00 AM

If you ever want to whistle blow or otherwise leak private information, this would be a great way to do it. Don't just blatantly run the script on your user account, but anonymously upload it as a plug-in that does the scraping and something useless, like tells you which floating-point numbers are even (none of them) then run that and play the victim.

by dlcarrier

5/20/2026 at 10:05:52 PM

I'm more surprised hackers found a large enough uptime window to do this.

by QuantumNoodle

5/20/2026 at 10:40:46 PM

For those not getting the joke, GitHub has had an increasingly difficult keeping itself up since Microsoft acquired them.

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

by hungryhobbit

5/21/2026 at 12:46:26 AM

*since coding agents caused their commit rate to increase 14x.

by miki123211

5/21/2026 at 1:17:24 AM

A problem that they contributed to.

by platevoltage

5/21/2026 at 6:33:51 AM

Maybe they actually try to increase the uptime now by making Copilot plans worse.

by nicce

5/20/2026 at 11:49:54 PM

Giggity.

by QuantumNoodle

5/20/2026 at 10:48:39 PM

No, it's had an increasingly difficult time keeping itself ever since they fixed their uptime metric collection, added Actions, and exploded in users.

by pathartl

5/21/2026 at 3:01:31 AM

Copying a joke posted somewhere else? Wow https://x.com/anshuc/status/2056898035159056558

by gjtorikian

5/21/2026 at 3:04:55 AM

Thinking a GitHub uptime joke is so creative only one person could have thought of it? Wow.

by fragmede

5/21/2026 at 12:47:16 PM

It’s a word for word copy from the original.

by gjtorikian

5/21/2026 at 2:25:40 PM

> holy sh*t, how did the attackers find a large enough uptime window to get in?

> 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

by QuantumNoodle

5/21/2026 at 8:23:05 AM

I was using Intellij until start of last year and then my organisation started pushing towards vibe coding. To my wonder, the models selection option is not available in Intellij but available only VSCode. The whole UI is mess and so scattered. It's a nightmare if you're coming from intellij. Plus on the verge of security violation on behalf of any extension you would just want to try on.

by furyman

5/21/2026 at 9:02:36 AM

I’d recommend just using a CLI harness in IntelliJ. The user experience is eons ahead, and you don’t miss out on anything other than flashy UI.

by 9dev

5/20/2026 at 7:43:13 PM

But, it did not go down! Progress!

by 1970-01-01

5/20/2026 at 8:31:56 PM

It's working, we just don't know what it's doing.

by marcosdumay

5/20/2026 at 8:59:00 PM

GitHub confirmed skynet

by baq

5/20/2026 at 8:57:13 PM

No time to deploy, nobody must move a muscle during the forensic investigation!

by LkpPo

5/20/2026 at 7:56:36 PM

Don't jinx it!

by skullone

5/20/2026 at 8:15:11 PM

The (lack of) security of VSCode has always been astounding. People have asked for sandboxing extensions for years [0] with little to no progress, and issues have been discussed a lot (e.g. [1][2]). I guess it hasn't been a big issue, likely because most developers are not complete idiots. But it only takes one developer and one bad extension to consequences like this.

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

[1] https://news.ycombinator.com/item?id=42979994

[2] https://news.ycombinator.com/item?id=46855527

by fg137

5/21/2026 at 12:45:23 AM

You don’t have to be an idiot to be hacked. A legit extension can be sold or compromised due to no fault of the engineer

Don’t attack individuals for mistakes of a system.

by Atotalnoob

5/20/2026 at 10:15:59 PM

I am so, so stressed about Sublime Text... It feels like a massive disaster just waiting to happen. They don't even run their own package marketplace :(

by bbor

5/21/2026 at 1:34:01 AM

There are so few users of sublime text that it likely isn’t a juicy enough target for these sorts of exploits.

by tstrimple

5/21/2026 at 2:12:23 PM

10% of developers use Sublime Text

by bbor

5/23/2026 at 7:22:51 PM

What an absolutely ridiculous claim to make.

by tstrimple

5/25/2026 at 3:43:40 PM

Well, give StackOverflow's survey team grief, not me...

by bbor

5/20/2026 at 9:09:01 PM

> but apparently Microsoft has put way more effort into their Copilot slop than security.

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

by zx8080

5/20/2026 at 9:48:16 PM

Why would you sandbox extension?

Just don’t install crap maybe.

by ozim

5/20/2026 at 9:58:10 PM

Any good, benign extension can be taken over and weaponized with malware.

by Hackbraten

5/20/2026 at 10:13:55 PM

This mans security onion has one layer.

by pixl97

5/20/2026 at 11:28:59 PM

Even if you don't install crap, the latest strategy is attacking the developer of one of the extensions or their build process so you can push a malware update to an otherwise legitimate extension.

by Gigachad

5/21/2026 at 12:17:07 AM

thanks for the sage advice. Next time you are infected with the flu you should just don't breath maybe.

by fhn

5/21/2026 at 6:27:13 AM

Interesting, this went Tanstack -> Nx Console -> GitHub

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

by gizzlon

5/21/2026 at 5:48:04 AM

Why does a company in GitHub's place allow employees to install random VSCode extensions?! That seems grossly irresponsible.

by danpalmer

5/21/2026 at 7:31:42 AM

Because centralized management of resources is the death of innovation, intrinsic motivation and speed?

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.

by 21asdffdsa12

5/21/2026 at 8:15:21 AM

This is the new old way. This was fine before irresponsible use of AI. Between vibe coding and using AI to find vulnerabilities as a result of vibes, I'm afraid that we will have to find ways to have more controlled environments.

by dannersy

5/21/2026 at 1:25:21 PM

It seems likely that some companies where the trade off shifts will head in that direction.

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.

by noir_lord

5/21/2026 at 8:10:52 AM

Move fast, break things, get internal repository leaked and lose all the 9s.

by gabrielgio

5/21/2026 at 9:19:11 AM

Im pretty sure GitHub reliability issues are a result of Microsoft centralized management (i.e migrate everything to azure, the only allowed cloud)

by dgellow

5/21/2026 at 9:26:55 AM

Tbh, at this point why does it matter if it was MS or not?

by gabrielgio

5/21/2026 at 4:54:39 PM

I don’t think it does, I was just pointing out their issues are likely caused by the centralized resource managementent (mentioned by https://news.ycombinator.com/item?id=48219114 you responded to), and not the „move fast, break things“ aspect. Just my guess. But yeah, it doesn’t matter if it is MS or GitHub itself

by dgellow

5/21/2026 at 8:00:53 AM

Your company getting hacked because of random plugins for emerging or dysfunctional ecosystems that don’t have enterprise management solutions yet is worth it to avoid friction?

by seanieb

5/21/2026 at 8:59:08 AM

Yes and no.

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.

by dust-jacket

5/21/2026 at 7:01:29 AM

It's true. But at the same time, isn't it crazy to conclude that a company should restrict their developers from using their own developer productivity tools and services? If Microsoft devs shouldn't use random VSCode extensions, how could anyone?

by exitb

5/21/2026 at 5:55:15 AM

You're assuming they allow it, but it might be against policy.

by wyclif

5/21/2026 at 6:10:59 AM

I’m pretty sure there is an policy on their internal wiki saying you shouldn’t do that.

Problem is: most employees don’t care to read these. Although I’m sure something like this could have been checked for during commit.

by baxtr

5/21/2026 at 7:10:11 AM

They can enforce it with an MDM. Policy should be enforced where possible not just notified to people.

by hhh

5/21/2026 at 8:43:09 AM

Absolutely agree. But enforcing is so much more effort than creating wiki pages with LLMs.

by baxtr

5/21/2026 at 6:26:55 AM

Fair point, I hadn't considered this, but wouldn't they just disallow it?

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.

by danpalmer

5/21/2026 at 7:09:14 AM

When I worked at Amazon, I had to run a special Amazon Linux. But I could just install whatever I wanted. I used emacs with whatever plugins I wanted.

Big tech can be suprisingly not locked down!

by paholg

5/26/2026 at 4:23:32 PM

Ah, that must have been AL2023, right? IIRC, it's tightly integrated with internal deployment toolchains like Apollo and Brazil (Amazon's internal package management and build systems).

by wyclif

5/21/2026 at 3:10:24 AM

Zed extensions are sandboxeds with restricted permissions btw…

by delduca

5/20/2026 at 10:27:10 PM

At what point did/does it start feeling naive to trust the integrity and output of Github Actions on general? Does it feel unlikely that an attacker would be able to get a foothold in that infrastructure?

by pamcake

5/21/2026 at 12:58:29 PM

Your extensions in VSCode have ambient access to your filesystem, your tokens, and your environment. The servers of tools like Claude Code or Cursor have that ambient access too. This was justified for Nx Console's purposes. This is justified in a coding agent's filesystem MCP. The exact same trust model: install it, it runs, you trust its scope implicitly.

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.

by luodaint

5/20/2026 at 9:18:43 PM

i'd love to be able to use fine grained tokens with gh and not expose every repo and org that i am connected to on github, but you can't see the results of a github actions check that way (no 'Checks' permission available). hoping these breaches push things in the direction of access being less annoying to manage.

by schpet

5/20/2026 at 9:35:26 PM

The problem is that the main target for these repos are the internal IaaS type repos that contain much of the juicy information.

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"

by alexfoo

5/20/2026 at 11:07:15 PM

i was more thinking like, if i am working on project ABC for org XYZ it's understandable that if my dev vm gets owned that ABC is leaked. it's not that acceptable if all of org XYZ's repos that i have access to get leaked. and especially not acceptable if everything i have access to, including other orgs, and the admin ability to do destructive operations on them, gets exposed. but status quo is that that's absolutely the case, and you basically need org specific github accounts to reduce the risk of that. or use the knee-capped fine grained PATs that github offers but don't work for common things like seeing if your PR is green.

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.

by schpet

5/21/2026 at 8:29:47 AM

I completely agree, but I don't think many developers will enjoy the new hoops that will need to be jumped through in order to do various things more securely.

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.

by alexfoo

5/20/2026 at 9:44:48 PM

I was noodling around with personal access tokens today on GitHub and found out that you actually can restrict tokens to specific repositories, orgs, etc. Not sure if actions is a scope that is available or not.

by spockz

5/20/2026 at 11:02:21 PM

I'd have thought that by now, most would have been swapping to WebAssembly. It's really nicely sandboxed, you expose it to only what you want, and you can compile a lot of languages into a WASM form meaning you're not stuck with only Javascript or similar. Am I naive for thinking that?

by dotwaffle

5/21/2026 at 6:04:23 AM

So basically we are now waiting for a wave of massive new exploits coming via GitHub itself. Lovely

by cdnsteve

5/21/2026 at 6:41:11 AM

The cloud is just someone else’s computer.

by brador

5/20/2026 at 9:05:04 PM

If only the company behind VSCode, the company behind NPM and the company behind GitHub could get together and figure out a solution to this.

by psadauskas

5/20/2026 at 10:25:15 PM

Perfectly demonstrating the truth of the "Microsoft org chart" cartoon.

https://bonkersworld.net/organizational-charts

by lacker

5/21/2026 at 12:52:07 AM

At first I though the Apple one had a half-dozen departments actually coordinating on something, but then I took a closer look and realized it's just more micromanagement.

by dlcarrier

5/21/2026 at 1:35:06 AM

I think the chart is still from the Steve Jobs era, who definitely was known to be a micromanager.

by stingraycharles

5/21/2026 at 4:00:07 AM

There’s an interview with someone talking about Steve having an extreme melt down rage about the header not being technically centered in one spot on the Apple page.

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

by bgro

5/21/2026 at 6:12:36 AM

And that's just the iPhone keyboard. The physical keyboards on MacBookPros are still terrible. I've had two of them where some of the keys shorted out or stopped working. Eventually, thinness has diminishing returns. I'd rather have a thicker/heavier keyboard where the keys don't die.

by wyclif

5/21/2026 at 4:29:42 AM

My thought on this was always that micromanaging in this structure is rational and maybe even the best. It's not really a Jobs thing—though he's (right or wrong) probably the picture most people have in their head when they think of visionary CEO—it's just that if the leader has a vision then it is great if they're capable of having everything run through them. It's when there's no vision at the top and no leaders sitting across the silos pulling things together that it helps the company to have people below with increasing autonomy. Whether the autonomous people should be higher or lower depends on which other org structure you've chosen. Silos are fine when leaders have a vision. That said, I haven't seen many groups that placed power in the place where their chosen org structure is meant to place power.

by cm11

5/21/2026 at 2:30:02 AM

This is 2011 though, a lot has changed since then. I doubt Facebook/Meta, for instance, is still as flat as it was then having read some ex-employee accounts

by 0xpgm

5/20/2026 at 11:57:17 PM

I've seen this a million times, but aren't the Amazon and Apple ones kinda the same, just differently shaped?

by BowBun

5/20/2026 at 11:58:51 PM

One has 1:2 fanout, the other has 1:50 fanout.

by danielheath

5/21/2026 at 1:57:59 AM

Also, Apple has master micromanager overriding managers.

by matkoniecz

5/21/2026 at 1:12:48 AM

Well, it certainly wasn't for lack of warning about the glaring risks...

https://github.com/microsoft/vscode/issues/52116

by guiambros

5/21/2026 at 2:28:20 AM

That is a very well written proposal, I wish someone wrote that sort of ticket for my software projects

by dmix

5/20/2026 at 9:45:20 PM

It is also company behind NuGet.

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.

by ozim

5/21/2026 at 12:20:14 AM

It is hard for Microsoft to do the right things*

FTFY

by stogot

5/21/2026 at 1:08:52 AM

In fairness, there was a time when I was unable to have a computer sort search results so the default hit was the plugin with 1000x more downloads than all the others combined.

by hedora

5/23/2026 at 9:04:44 AM

Continued devils advocate.

It is hard to do right things at their scale and when you do the right thing other division might actively work against you.

There was this „how companies work” image where MSFT was each division pointing guns at each other.

by ozim

5/20/2026 at 11:57:16 PM

Not trolling here but these things are by design cesspools ready for compromise. Any fully open ecosystem where contributions are not strictly reviewed is open to this problem. If you don't like it, don't use editor extensions and use a well audited editor.

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.

by getpokedagain

5/21/2026 at 12:53:06 AM

Extensions never had to be given unsandboxed access to everything. That's a choice that they actively made.

by LiamPowell

5/21/2026 at 1:56:42 AM

I mean I don't think some sort of "access control" within the editor is going to really address this. People edit sensitive text in their code editor and no matter what that is going to be available to most useful extensions. Even if you don't lose a credential or get some arbitrary script running to mine crypto on your machine you could have an extension function as a key logger and exfil code you really think is valuable.

by getpokedagain

5/21/2026 at 2:29:24 AM

It would have restrained the access here. The extension would have only had access to the repos opened by this individual rather than an api key that gave access to 3,800 repos.

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.

by Gigachad

5/21/2026 at 2:57:14 AM

Most of these problems could be solved with something like wasm/wasi where you can limit access to web, disk, etc... WASI is made to run code you don't trust, you could even limit compute third party is using so they can't mine crypto (I think it's called fuel limit). Ideally we would have whole IDE run in this kind of environment where we can explicitly say what it can and can't do.

by stanac

5/21/2026 at 12:58:31 AM

its easy to complain, words are cheap. fork it and change it if you don't like it

by wutwutwat

5/21/2026 at 1:12:38 AM

It's easy to wave a magic wand and have one developer do better than a corporation of tens of thousands. There is a reason I don't use Microsoft products: I can't do it myself and do won't do it for me.

by antiframe

5/21/2026 at 4:55:39 AM

There is no editor that sandboxes extensions as described.

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.

by lkjdsklf

5/21/2026 at 1:31:28 AM

Then you lose access to the VSCode marketplace which kind of defeats the purpose.

by jurgenburgen

5/20/2026 at 11:09:45 PM

[dead]

by sieabahlpark

5/20/2026 at 9:22:21 PM

i mean, then you say it like that…

by notnmeyer

5/20/2026 at 9:43:43 PM

Microsoft is the inverse hand of Midas, turns everything into shit.

by midtake

5/20/2026 at 9:56:19 PM

Mierdas, as they say.

by dbalatero

5/20/2026 at 10:09:36 PM

With $101 billion in profit last year I wish I could turn things into $hit as well as they do.

by pixl97

5/21/2026 at 12:27:05 AM

You could, with a large enough captive audience.

by andrei_says_

5/21/2026 at 2:30:14 AM

or a large enough hand

by jrgd

5/20/2026 at 11:33:31 PM

Everything Microsoft makes sucks. If they decided to make vacuum cleaners though, they wouldn’t suck, they would blow.

by loloquwowndueo

5/21/2026 at 12:31:29 AM

Just five years ago this opinion was heresy on HN. Those of us who still remembered their behavior in the 80s/90s were belittled.

"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."

by lysace

5/22/2026 at 12:04:43 PM

Well the vacuum cleaner joke is very old, was true then, is true now, has continued to be true despite some people having the wool pulled over their eyes and thinking that Microsoft was no longer the enemy at some point. They have always been the enemy. Stay on your toes, don’t let them in.

by loloquwowndueo

5/21/2026 at 1:02:40 AM

Pretty sure that was astroturfing.

by cwnyth

5/21/2026 at 1:10:17 AM

I always wondered what the division of pro-MS astroturfing was betweeen:

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)

by lysace

5/20/2026 at 9:56:40 PM

these days it's just Microslop

by bhadass

5/21/2026 at 9:41:57 AM

Pinning version and auditing updates might solve the problem of benign products going rogue... Can't we crowdsource, or otherwise curate the products.... I mean they (App Store, Play Store, Visual Studio Market Place, Microsoft Store,...) just don't seem to be much useful in this matter.

by lexybarton

5/20/2026 at 7:49:09 PM

If you own a GitHub organization and are looking for what changes/controls you can apply to reduce the risk/impact of PAT token exfiltration (and subsequent abuse) like what occurred here, I listed a few at the end of https://blog.bored.engineer/github-canarytokens-5c9e36ad7ecf...

- 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...

by innoying

5/21/2026 at 7:22:31 PM

So presumably what this malicious extension did was steal the Github employee's tokens/cookies and then the attackers had access to the internal Github repos

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)

by mixdup

5/21/2026 at 9:08:48 AM

I'm surprised that we have a lot of comments but still no alternative which would be secure by design. Meaning, not downloading stuff shadily in the background like Zed, or allowing extensions to roam free like VSCode...

by ulimn

5/21/2026 at 9:43:46 AM

I understand not wanting to ship a single IDE package with support for everyting by default. But in that case the IDE vendor should build and audit enough extensions themselves so you can have a working product without relying on untrusted/unaudited ones.

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.

by prmoustache

5/21/2026 at 1:00:28 PM

Both Emacs and Neovim gives you full control IF yhats what you're after.

by lawn

5/21/2026 at 9:14:34 AM

I might just go back to emacs :(

by dgellow

5/21/2026 at 9:30:55 AM

That should be a :)

by zeafoamrun

5/21/2026 at 8:02:17 PM

Maybe, but I remember why I left my beloved-but-extremely-slow emacs :p

by dgellow

5/20/2026 at 7:29:01 PM

So which extension? Why don't they tell us?

by 2OEH8eoCRo0

5/20/2026 at 7:49:33 PM

A few days ago I saw I had an update to the Twig extension. The UI flagged it as having new executable code in the update bundle, so I didn't install the update, disabled the extension as I wasn't working on Drupal views that day, and went about my work. I didn't have time to investigate the new update's contents. When I went back to the extension page, it was taken down: https://open-vsx.org/extension/whatwedo/twig

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.

by cmg

5/20/2026 at 8:27:08 PM

I'm not seeing anything on the official marketplace: https://marketplace.visualstudio.com/items?itemName=whatwedo...

I wonder if it was open-vsx specific?

by nightpool

5/20/2026 at 9:59:00 PM

That’s very possible. I switch between Cursor and VS Code, don’t remember which it was that day.

by cmg

5/20/2026 at 7:35:13 PM

There are rumours that was NX Console VS code extension

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

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

by vldszn

5/21/2026 at 1:11:19 AM

UPD: it’s confirmed now by the CEO of Nx https://x.com/jeffbcross/status/2057236396658811020?s=46&t=_...

by vldszn

5/21/2026 at 1:18:03 AM

> One of our developers was compromised by a recent supply-chain compromise on Tanstack

...which in turn was caused by bad design of github's CI pipeline. Funny how it all comes back around like that.

by bmandale

5/21/2026 at 1:57:26 AM

Yeah..full circle

by vldszn

5/20/2026 at 7:39:19 PM

Sounds like another "why even bother" extension, made to automate things that shouldn't be automated

by raverbashing

5/20/2026 at 9:12:38 PM

[dead]

by vldszn

5/21/2026 at 9:59:13 AM

So I have been thinking about this for a while - if your product has "plugins" there's only two ways forward:

* 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.

by otikik

5/22/2026 at 1:36:31 PM

> gigabytes upon gigabytes of random stuff that just gets pulled in from everywhere in IDEs, package managers, build pipelines and container images.

Let's face it though - things are working pretty well at gigantic scales despite that. Apparently, what we have now works. There would certainly be wrongdoers who abuse it at this scale, and some of them could be significant abuses. But, however you look at it, things are working well at large.

by zrn900

5/21/2026 at 7:13:10 AM

> "Yesterday we detected and contained a compromise of an employee device involving a poisoned VS Code extension. ..."

Am I blind or did they never say which extension that was?

by classified

5/21/2026 at 1:28:10 PM

Working hard on the github killer. Fully decentralized with nearly unbreakable release system. Multiple parties need to produce the same artifacts in the release workflow. IKA then signs the release on the network side, you sign your release using hardware token. Release pipeline analysis source code for malware on the complete dependency chain. Rust + Nix + SUI + WALRUS + SEAL + IKA - a complete decentralized economy. A few more weeks until testnet :)

by poelzi

5/21/2026 at 1:33:14 PM

Use those few weeks to write a proper product description and pitch, because I just read your entire paragraph and am no closer to understanding what you're building.

by wutwutwat

5/21/2026 at 2:08:37 PM

I have build a proper workflow system for complex work that composes environments from nix flakes (very extended flakes) - it allows you to combines deterministic with agentic steps. The release process is a workflow in your project that requires to generate reproducible outputs - nix does this for you. The network basically is a distributed CI system - Multiple parties need to check and build your release. When all parties agree, that the package is correct, the SUI smart contract gives it's go. IKA is a multi party encryption network which implements a novel MCP-2pc algorithm. Your release key is split in half - IKA has one part, you have the other. Only is both parties sign the transaction, your software package gets release. Every party, even your PC can be compromised, and it is very hard to just release malware in your package. The whole release pipeline needs to succeed ant then you need to sign it with your hardware token. There are mandatory workflows in the release pipeline that check your software for side loading, comparing your dependency tree to the last version published, etc.

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

by poelzi

5/21/2026 at 7:03:32 AM

I ditched VSCode for Sublime Text long back and don't feel missing anything. If any, my productivity and control over things has only improved.

by zkmon

5/21/2026 at 8:26:17 AM

I ditched Github for Gitea. If I want to share the code I can use completely distinct credentials and I don't "login" into my IDE. Although the latter doesn't help, an IDE can extract any form of secret just fine, but you can still minimise the risk.

by raxxorraxor

5/21/2026 at 7:15:31 AM

Does it have a source-level debugger for Rust?

by classified

5/21/2026 at 9:21:30 AM

Are sublime text extension less risky?

by dgellow

5/21/2026 at 12:36:05 AM

When installing IntelliJ IDEA extensions, I download the code and try to check it for malicious stuff using Claude Code... But not perfect since the code might not match what was released. We would need reproducible builds...

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.

by eneveu

5/21/2026 at 1:10:35 AM

If you don't do it for every update, then there is no real point in doing that in the first place.

by BoneShard

5/21/2026 at 12:01:28 AM

My company has extremely strict policies about installing software. We have to call up IT any time we want an application installed. As an engineer it's very annoying to deal with, but I understand it. Problem is they have no policy about extensions and npm/pip packages. It's a time bomb waiting to go off.

by CivBase

5/21/2026 at 2:06:55 AM

This is why uninstalled 90% of my VSCode extensions last year. The writing is/was on the wall.

by nullbio

5/20/2026 at 8:04:16 AM

so how did they exfiltrate the information without noticing? what OS was the developer using? what security measures were they using?

yesterday discussion https://news.ycombinator.com/item?id=48191680

by gus_

5/20/2026 at 7:42:10 PM

The security measure that the developer didn't use was completely refusing to use vscode.

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".

by amluto

5/20/2026 at 8:36:41 PM

Or you can just refuse to use random extensions. I built my own extensions if I needed them. You're a programmer, right? The whole point of extensibility is that you, or your company, can program what you need from your IDE, without having to make a whole IDE from scratch. I have since moved on to making my own IDE, mostly because I hate Electron and its >1gb memory footprint, but vscode served me so much better than anything else for years, without installing a single rando's extension.

by applfanboysbgon

5/20/2026 at 9:58:26 PM

Kind of.

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...

by amluto

5/20/2026 at 10:35:50 PM

It would be nice if there was an easy way to prevent people from installing vscode remotes on a shared server... Probably can run an ebpf routine to disallow creation of folders named . vscode*

by cozzyd

5/20/2026 at 11:32:02 PM

The shared part has almost nothing to do with this, IMO.

by amluto

5/21/2026 at 10:52:10 AM

Disabling ssh alternate channels will make it uncomfortable enough for most people to be a deterrant. But if you require multiple ssh channels for different reasons that won't be a solution for you.

by Bigpet

5/20/2026 at 9:09:05 PM

> I built my own extensions if I needed them. You're a programmer, right? The whole point of extensibility is that you, or your company, can program what you need from your IDE,

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.

by xienze

5/20/2026 at 9:14:58 PM

> just to do our day jobs.

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.

by applfanboysbgon

5/20/2026 at 10:52:17 PM

> people who hate programming and avoid doing it as much as possible, because they only got into it for the money.

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.

by xienze

5/20/2026 at 9:29:24 PM

bait

by aee

5/20/2026 at 9:03:36 PM

> You're a programmer, right?

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

by dylan604

5/20/2026 at 10:09:30 PM

Most bosses look poorly upon spending their budget on rewriting software that already exists and simultaneously most bosses(although not the exact same set) don’t care about security until a disaster has already occurred.

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.

by lovich

5/20/2026 at 8:55:17 AM

The 3800 repos weren't exfiltrated from the compromised machine.

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.

by alexfoo

5/20/2026 at 10:19:52 AM

> It's trivial to do this in a way to avoid detection

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.

by gus_

5/20/2026 at 12:51:53 PM

> but I still think that restricting outbound requests is a good measure

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.

by pixl97

5/20/2026 at 6:37:44 PM

> Why does VS need to establish outbound requests to any domain, without authorization?

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.

by array_key_first

5/20/2026 at 1:06:56 PM

There are plenty of exfiltration examples out there that could go through known, commonly-greenlit domains. Even exfil via DNS requests has been demonstrated.

by mmcwilliams

5/20/2026 at 7:34:38 PM

But at least in that case, there’s a chance that the outbound requests are blocked. Malware isn’t perfect. Simple measures can block a significant proportion of attacks.

by antonvs

5/21/2026 at 3:15:42 AM

We need to stop normalizing outbound connectivity by default. In fact we should be alerted anytime something tries to go outbound.

by mikeweiss

5/21/2026 at 3:24:50 AM

I found more details on how this particular attack worked:

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.

by cloudbonsai

5/20/2026 at 10:51:54 AM

Ah yes, sandboxing/limiting a VSCode plugin is not impossible. I was thinking in more general terms (such as post install scripts within npm/python packages). Random test code in golang packages. There's an awful lot that people don't vet because keeping up with the vetting is a huge burden which seems pointless until you're the one that gets hacked.

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.

by alexfoo

5/20/2026 at 1:33:55 PM

the pop-ups fatigue is already an issue, and not an easy one to solve. Pretty much like SIEM/SOC alerts.

> 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...

by gus_

5/20/2026 at 1:19:53 PM

> If companies continue to not pay the ransom then we're going to get a lot more things published

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?

by esseph

5/20/2026 at 7:42:24 PM

If paying the ransom doesn't stop your data getting leaked, nobody will pay the ransom. There is a rational basis for the ransomers to follow through with the deletion. Even the mob did provide "protection" when they coerced you into paying for it.

by SoftTalker

5/20/2026 at 9:45:20 PM

This sounds like a naive presumption. Are ransomware distributors well known for operating within strict hierarchies bound by culturally-ingrained traditions, or acting in the best interests of their own “greater good”?

Last I heard, teenagers can deploy ransomware with minimal technical knowledge or skill.

by nativeit

5/20/2026 at 9:05:07 PM

[dead]

by esseph

5/20/2026 at 7:34:45 PM

Because if they leak then nobody will pay the ransom in the future?

by senderista

5/20/2026 at 9:05:24 PM

(responded to a similar response above)

by esseph

5/20/2026 at 9:52:47 AM

> The malware (be it a VSCode plugin, an npm package, or whatever is next)

Not the first time we've seen a developer get popped thanks to a malicious game mod either...

by kotaKat

5/21/2026 at 10:24:54 AM

[flagged]

by Predaxia

5/21/2026 at 1:09:48 AM

If I'm using more than 5 extensions for a lightweight client like VSCode, I consider whether a full IDE is more appropriate since they have the functionality built in. The same features but from 3rd party extensions introduces more attack vectors.

by kittikitti

5/21/2026 at 3:18:15 AM

Someone scold me if I'm wrong but this is really worrying. Threat actors with Github's internal code means a huge acceleration in vulnerability discovery for the one platform where everybody warehouses their code.

How is this not really, really bad?

by prodigycorp

5/21/2026 at 5:50:15 AM

This will not reassure you, but the reason it isn't necessarily really bad is because it's only incrementally worse than the really bad news came out last month:

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...

by drewda

5/21/2026 at 3:48:05 AM

It is really bad. But I think other Git providers also have weaknesses. Maybe it is just not a public knowledge or exploited.

by ViAchKoN

5/21/2026 at 3:24:02 AM

[dead]

by itake

5/21/2026 at 8:38:26 AM

What are the take aways from this? Should we avoid extensions now? Only install extensions from who you trust? What about if they get owned and you have auto-update extensions on as most people do?

by Uptrenda

5/22/2026 at 9:35:07 AM

I can imagine that in the near future we're gonna have such news almost every day, with so many people starting to build software without knowing the basics of coding.

by snazarov92

5/20/2026 at 7:41:05 PM

Isn't 50k a bargain for what could potentially be in those files?

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.

by sunshine-o

5/20/2026 at 7:53:15 PM

The data has been stolen by a criminal group. Paying for "restoring" the data does not guarantee they will delete all copies. There is no way of proving they actually did and they have in fact very little incentive to actually delete it.

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

by smashed

5/20/2026 at 8:08:26 PM

> 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.

by tyre

5/20/2026 at 9:08:39 PM

At some point, these people will come up with a ransom-as-a-service that you can subscribe to make monthly payments. It's no different than having to pay criminals monthly for security to prevent them from harming your themselves.

by dylan604

5/20/2026 at 8:47:07 PM

> this is not a ransom … Send your offers … we are not interested in under 50k…

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

by deckar01

5/20/2026 at 9:45:25 PM

Sure but I meant I do find the minimum bid very low for such a high profile hack.

by sunshine-o

5/21/2026 at 8:34:40 AM

Microsoft is slowly killing GitHub the moment it became known as the Microslop company. Those incident reports have really amplified in the last few months.

by shevy-java

5/21/2026 at 12:15:08 PM

hmm I created my project based on malicious browser extensions. But I am starting to think that I should make it more broad and look at VSCode extensions too.

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..

by buio

5/20/2026 at 11:26:43 PM

The forum listing for the stolen source code (per the screenshot in article) says 1 buyer or they leak for free. Is GitHub about to become open source?

by huey77

5/20/2026 at 10:24:05 PM

What's inside the canada.tar.gz one?

by purpleidea

5/21/2026 at 1:42:46 AM

> "Yesterday we detected and contained a compromise of an employee device involving a poisoned VS Code extension. We removed the malicious extension version, isolated the endpoint, and began incident response immediately,"

So great that they removed the extension! Do they do it only after their own employee was infected? And why "unnamed" extension?

by zx8080

5/21/2026 at 3:40:23 AM

1. Microsoft did link the extension in their official post. Under hacker news guidance, I think that original source link should been posted instead of bleeping computer. https://github.blog/security/investigating-unauthorized-acce...

> “unnamed”

Why is “unnamed” in quotation marks?

by no-name-here

5/21/2026 at 12:02:49 AM

This has significant consequences for companies hosting their private repos with GitHub. It's a huge security threat if the attacked has access to the source code. At the very least, GitHub should let people know if their repo was part of the hack or not. It's the most responsible thing to do.

by neya

5/21/2026 at 12:25:34 AM

Well, the hacker group claims to have access to the Github source code according to the linked article. And apparently, one lucky buyer with at least $50,000 can also have access.

by nerdix

5/21/2026 at 7:12:49 AM

The chickens are coming home to roost across the industry. The next 5 years ALL technical debt will have to be repaid or you all will be eaten alive. Good luck all.

by BatteryMountain

5/21/2026 at 2:12:07 AM

Where's the torrent

by monster_truck

5/21/2026 at 3:51:29 AM

Microsoft: "you shouldn't run untrusted code, here's a mess of ugly dialogs for people to click through if they try."

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!"

by Pxtl

5/21/2026 at 6:52:32 AM

Insane to think GH has at least 3800 internal repos.

by elAhmo

5/21/2026 at 6:56:57 AM

Because it’s high or low? Imo it’s not that hard to reach that amount, they have quite a few employees, offering services for ~20 years and it’s probably also containing small repos - would’ve imagined way more tbh.

by mrklol

5/21/2026 at 6:55:40 AM

well, own dogfood and all that, i'm not surprised?

by chii

5/21/2026 at 9:12:58 AM

shouldn't anthropic give mythos access to github, prolly the most insecure piece of software while also being the most important one

by shandilyaharsh

5/21/2026 at 5:06:00 AM

Is there any way to know if my repos were affected?

by lxxpxlxxxx

5/21/2026 at 5:11:53 AM

If you work for Github you are likely affected.

by Bairfhionn

5/21/2026 at 7:22:31 PM

Oops, I missed the 'internal' part

by lxxpxlxxxx

5/20/2026 at 8:17:21 PM

Curious timing that I've started moving private repos to SourceHut a couple of weeks ago. It's pretty good and fast!

I'm also mirroring public ones to Codeberg.

I'll write about it when I'm done.

by BrunoBernardino

5/20/2026 at 9:43:16 PM

Has there been any confirmation of this from a source other than X? It's weird that that's the only source, and therefore makes me distrust the entire story.

by LeoPanthera

5/21/2026 at 12:15:40 AM

Good. They are eating their own dog food

by fhn

5/20/2026 at 7:48:34 PM

Is it premature to blame AI Microslop?

by josefritzishere

5/20/2026 at 7:56:10 PM

It's definitely AI slop. So tired of pushing AI-generated crap to production at my company

by dakiol

5/21/2026 at 8:52:19 AM

some of the repos that were listed by these hackers(summarized by LLM):

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

by jack-pissy

5/20/2026 at 7:42:53 PM

Another day another issue with Microsoft products, what else can be said :( At least they are being upfront these days.

by jmclnx

5/20/2026 at 9:44:44 PM

And now, the hackers will be able to scan the repos for more vulnerabilities. Vulnerabilities all the way down.

by aizk

5/21/2026 at 8:47:52 AM

Each day NeoVim / LazyVim sounds better to me...

by KnuthIsGod

5/21/2026 at 8:54:42 AM

It shouldn’t. Same 3rd party extensions distribution model like in VSCode just written in Lua instead

by enbugger

5/20/2026 at 9:55:49 PM

A good day not to be using Electronjs trash.

by dude250711

5/20/2026 at 11:30:16 PM

Electron has nothing to do with the exploit here. A Vim plugin would have just as much ability to run malware.

by Gigachad

5/21/2026 at 5:55:09 AM

No one using vim will install the kind of extensions I found on the usual VS Code setup. And most don't even autoupdates.

by skydhash

5/21/2026 at 6:29:34 AM

I’m not sure this is true. Vim needs extensions even more than VS code since many basic features like full project code search or go to definition aren’t in the base vim.

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.

by Gigachad

5/21/2026 at 8:15:41 AM

> full project code search

grep

> go to definition

/definition

Not even using vim, I'm more of a micro person.

by tliltocatl

5/21/2026 at 7:52:05 AM

Sigh. I guess there isn't any "min-release-age" for extensions ...

by xyzal

5/21/2026 at 2:00:42 AM

What was the extension what the fuck? No mention of the name anywher?e

by efilife

5/21/2026 at 11:07:40 AM

[flagged]

by shawakash54

5/21/2026 at 4:15:47 AM

[flagged]

by cnguyen1494

5/22/2026 at 2:05:26 PM

[flagged]

by jas-park-dev

5/21/2026 at 11:17:24 AM

[flagged]

by Oxlamarr

5/22/2026 at 8:24:16 AM

[dead]

by rohitsriram

5/21/2026 at 1:44:04 PM

[flagged]

by CroviaTrust

5/20/2026 at 8:32:28 PM

friendly reminder:

- 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...

by vldszn

5/21/2026 at 4:46:58 AM

Thanks!

> 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.

by no-name-here

5/21/2026 at 10:49:04 AM

[dead]

by vldszn

5/21/2026 at 3:17:20 AM

Or how about just don't allow your VS extensions outbound Internet access ...

by mikeweiss

5/21/2026 at 4:38:23 AM

How? I haven’t found a way to do that on windows, as even with third-party monitoring firewalls, extension's network access is indistinguishable from the rest of VS code, so you’d either have to disallow network access from both VS code and all of its extensions combined, or none of them?

by no-name-here

5/21/2026 at 10:47:23 AM

restrict code.exe to an allowlist. Also, many malicious actors rely on system commands to download or exfiltrate data.

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.
https://securitylabs.datadoghq.com/articles/mut-9332-malicio...

Or this one:

  const CONFIG_URL = 'http://clawdbot.getintwopc[.]site/config.json';
  function fetchConfigAndRun() {
     http.get(CONFIG_URL, (res)
they also establishes outbound connections to dropbox and other not expected domains:

https://www.aikido.dev/blog/fake-clawdbot-vscode-extension-m...

so maybe it's not bulletproof, but it helps to mitigate these threats.

by gus_

5/20/2026 at 10:33:41 PM

friendly reminder: use vim :)

by arandomhuman

5/20/2026 at 11:39:10 PM

If you are a person that installs extensions from public sources, it doesn't matter what IDE you use.

If you don't (or can't) install extensions, it also doesn't matter which IDE you use.

by IcyWindows

5/21/2026 at 4:46:02 AM

You can and should and I do glance at a diff of changes every time you update a vim plugin. To make this feasible - I only use a handful of plugins I *really need*.

by archargelod

5/20/2026 at 10:48:37 PM

It honestly surprises me we don't hear news about vim/neovim plugin supply chain attacks.

by leni536

5/20/2026 at 11:23:02 PM

probably a much smaller dependency graph (lesser usage of transitive dependencies)

by arandomhuman

5/20/2026 at 10:36:25 PM

=)

by vldszn

5/21/2026 at 3:20:25 PM

[flagged]

by ryanshrott

5/20/2026 at 9:25:21 PM

[dead]

by assanineass

5/21/2026 at 4:52:27 AM

[dead]

by vladsiu

5/20/2026 at 7:51:40 PM

[dead]

by a-dub

5/21/2026 at 7:04:05 AM

[flagged]

by NexraGear

5/22/2026 at 5:40:50 PM

[flagged]

by throwawaypath

5/21/2026 at 5:59:52 AM

something something javascript, npm, etc.

by sharts

5/20/2026 at 9:17:30 PM

Who uses GitHub in 2026

by thrawa8387336

5/21/2026 at 3:18:33 AM

If they tighten up things, it would impact the ease of use.

by Onplana

5/20/2026 at 10:30:06 PM

question is why are people still using vscode or coding by hand?

by jehnnysmith