Live data from Hacker News

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

bleepingcomputer.com

251–260 of 488 posts

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

#251

Earlier quoted context omitted.

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

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

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.

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

#252
Updated: Catalog of all major npm/nodejs ecosystem attacks since May 2025-2026: https://npm-supply-chain-attacks-25-26.pagey.site/

All used techniques and mitigation strategies, including this one: https://npm-supply-chain-attack-techniques.pagey.site/

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

#253
post #209

Earlier quoted context omitted.

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…

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.

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.

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

#254
post #250

Earlier quoted context omitted.

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…

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

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.

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

#255
post #131

Earlier quoted context omitted.

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.

> 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 a…

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

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

#257

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?

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

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

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

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

#259

Earlier quoted context omitted.

Internet access. An editor extension does not need it.

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.

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

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

#260
post #37
post #24

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

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

Damn that's alot. I'm wondering how many engineers handled all that?
Post reply on HN