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 • 2 months ago

1054 460 2 months ago

Previous thread in sequence:

GitHub is investigating unauthorized access to their internal repositories - https://news.ycombinator.com/item?id=48201316 - May 2026 (321 comments)

gus_6• 2 months ago

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

alexfoo4• 2 months ago

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.

kotaKat• 2 months ago

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

gus_6• 2 months ago

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.

esseph2• 2 months ago

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?

dang2• 2 months ago

(We merged this thread hither - it was originally in https://news.ycombinator.com/item?id=48201316)

amluto3• 2 months ago

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

applfanboysbgon2• 2 months ago

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.

dang2• 2 months ago

Previous thread in sequence:

GitHub is investigating unauthorized access to their internal repositories - https://news.ycombinator.com/item?id=48201316 - May 2026 (321 comments)

2OEH8eoCRo0• 2 months ago

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

vldszn6• 2 months ago

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

raverbashing• 2 months ago

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

vldszn6• 2 months ago

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

cmg2• 2 months ago

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.

james2doyle• 2 months ago

I’ve used djlint on a liquid project and it worked well. It supports twig too: https://djlint.com/docs/languages/twig/

They also have an online demo/playground so you can at least give it a shot to see if it works.

I’ve used the twiggy LSP before and there seems to be a few VS code extensions for it: https://marketplace.visualstudio.com/items?itemName=moetelo.... and https://marketplace.visualstudio.com/items?itemName=Stanisla...

nightpool2• 2 months ago

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

I wonder if it was open-vsx specific?

Atotalnoob2• 2 months ago

It’s nx console

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

sunshine-o4• 2 months ago

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.

smashed• 2 months ago

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?

tyre• 2 months ago

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.

deckar01• 2 months ago

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.

sunshine-o4• 2 months ago

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

jmclnx• 2 months ago

Another day another issue with Microsoft products, what else can be said :( At least they are being upfront these days.

1970-01-01• 2 months ago

But, it did not go down! Progress!

skullone• 2 months ago

Don't jinx it!

marcosdumay• 2 months ago

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

baq• 2 months ago

GitHub confirmed skynet

LkpPo• 2 months ago

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

tekacs• 2 months ago

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

MrDarcy• 2 months ago

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

organsnyder• 2 months ago

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

eddythompson80• 2 months ago

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.

newsoftheday• 2 months ago

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

dgellow8• 2 months ago

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

clutch_coder99• 2 months ago

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

tempay• 2 months ago

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.

noelsusman• 2 months ago

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

dijit• 2 months ago

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.

Galanwe• 2 months ago

The breach is about internal repositories, not user repositories.

nightpool2• 2 months ago

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)

PAndreew• 2 months ago

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.

htrp• 2 months ago

no pruning of repos?

paulddraper• 2 months ago

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

Some of those could be forks.

philipp-gayret• 2 months ago

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.

robotnikman• 2 months ago

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

ashishb2• 2 months ago

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

Gigachad12• 2 months ago

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.

skissane2• 2 months ago

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.

unix4ever• 2 months ago

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.

ryanhecht• 2 months ago

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

jamesfinlayson• 2 months ago

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

wazHFsRy• 2 months ago

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

dirkc• 2 months ago

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!

sunshine-o4• 2 months ago

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.

codedokode• 2 months ago

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.

jandrese• 2 months ago

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.

duped• 2 months ago

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

internet101010• 2 months ago

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

NewJazz3• 2 months ago

Don't build your ide on electron then.

varun_ch• 2 months ago

Electron was invented to build an IDE on.

IshKebab2• 2 months ago

Sandboxing on Linux is extremely difficult task.

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

noir_lord2• 2 months ago

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

Plan 9 was designed, Linux accreted.

josefritzishere• 2 months ago

Is it premature to blame AI Microslop?

dakiol• 2 months ago

It's definitely AI slop. So tired of pushing AI-generated crap to production at my company

efilife2• 2 months ago

https://github.com/nrwl/nx-console

Looks like it

innoying• 2 months ago

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

fg1372• 2 months ago

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

zx80802• 2 months ago

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!

ozim3• 2 months ago

Why would you sandbox extension?

Just don’t install crap maybe.

Hackbraten• 2 months ago

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

pixl973• 2 months ago

This mans security onion has one layer.

Gigachad12• 2 months ago

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.

fhn2• 2 months ago

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

bbor3• 2 months ago

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

tstrimple2• 2 months ago

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

Atotalnoob2• 2 months ago

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.

notnullorvoid7• 2 months ago

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

fg1372• 2 months ago

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

notnullorvoid7• 2 months ago

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.

pamcake2• 2 months ago

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.

notnullorvoid7• 2 months ago

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.

hungryhobbit2• 2 months ago

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

ajross• 2 months ago

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.

Gigachad12• 2 months ago

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.

spudlyo• 2 months ago

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

simiones5• 2 months ago

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.

panchtatvam• 2 months ago

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 )

0xpgm2• 2 months ago

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?

crabbone2• 2 months ago

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

mschuster912• 2 months ago

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.

deely3• 2 months ago

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

notnullorvoid7• 2 months ago

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.

BrunoBernardino• 2 months ago

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.

vldszn6• 2 months ago

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

arandomhuman2• 2 months ago

friendly reminder: use vim :)

vldszn6• 2 months ago

leni536• 2 months ago

It honestly surprises me we don't hear news about vim/neovim plugin supply chain attacks.

IcyWindows• 2 months ago

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.

mikeweiss2• 2 months ago

Or how about just don't allow your VS extensions outbound Internet access ...

no-name-here7• 2 months ago

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?

no-name-here7• 2 months ago

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.

psadauskas• 2 months ago

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.

notnmeyer• 2 months ago

i mean, then you say it like that…

midtake• 2 months ago

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

ozim3• 2 months ago

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.

stogot• 2 months ago

It is hard for Microsoft to do the right things*

FTFY

lacker• 2 months ago

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

https://bonkersworld.net/organizational-charts

BowBun• 2 months ago

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

dlcarrier2• 2 months ago

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.

0xpgm2• 2 months ago

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

getpokedagain2• 2 months ago

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.

LiamPowell• 2 months ago

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

guiambros• 2 months ago

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

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

dmix• 2 months ago

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

thrawa8387336• 2 months ago

Who uses GitHub in 2026

schpet2• 2 months ago

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.

alexfoo4• 2 months ago

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"

schpet2• 2 months ago

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.

spockz• 2 months ago

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.

cdrnsf• 2 months ago

That's one way to make things open source.

dlcarrier2• 2 months ago

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.

LeoPanthera• 2 months ago

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.

tangwwwei• 2 months ago

someone above mentioned it's been confirmed as nx console here: https://github.blog/security/investigating-unauthorized-acce...

aizk• 2 months ago

And now, the hackers will be able to scan the repos for more vulnerabilities. Vulnerabilities all the way down.

urbandw311er2• 2 months ago

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

K3UL• 2 months ago

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

urbandw311er2• 2 months ago

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.

dude250711• 2 months ago

A good day not to be using Electronjs trash.

Gigachad12• 2 months ago

Electron has nothing to do with the exploit here. A Vim plugin would have just as much ability to run malware.

skydhash10• 2 months ago

No one using vim will install the kind of extensions I found on the usual VS Code setup. And most don't even autoupdates.

QuantumNoodle3• 2 months ago

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

hungryhobbit2• 2 months ago

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.

pathartl• 2 months ago

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

QuantumNoodle3• 2 months ago

Giggity.

miki1232113• 2 months ago

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

gjtorikian2• 2 months ago

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

fragmede• 2 months ago

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

mcoliver• 2 months ago

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.

Gigachad12• 2 months ago

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.

charlieyu12• 2 months ago

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.

miki1232113• 2 months ago

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.

xyzzy123• 2 months ago

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

yard2010• 2 months ago

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.

ToucanLoucan• 2 months ago

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”

at-fates-hands• 2 months ago

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.

cwnyth2• 2 months ago

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

no-name-here7• 2 months ago

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

xgulfie• 2 months ago

And they all want to auto-update, too.

wyclif4• 2 months ago

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

csomar• 2 months ago

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

no-name-here7• 2 months ago

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 )

purpleidea• 2 months ago

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

pamcake2• 2 months ago

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?

jehnnysmith• 2 months ago

question is why are people still using vscode or coding by hand?

dotwaffle• 2 months ago

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?

huey77• 2 months ago

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?

bfivyvysj• 2 months ago

Why is the extension not being named?

TiredOfLife3• 2 months ago

Because the link is blogspam.

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

CivBase• 2 months ago

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.

neya• 2 months ago

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.

nerdix• 2 months ago

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.

fhn2• 2 months ago

Good. They are eating their own dog food

eneveu• 2 months ago

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.

BoneShard• 2 months ago

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

kittikitti• 2 months ago

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.

zx80802• 2 months ago

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

no-name-here7• 2 months ago

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?

efilife2• 2 months ago

What was the extension what the fuck? No mention of the name anywher?e

nullbio• 2 months ago

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

monster_truck• 2 months ago

Where's the torrent

delduca• 2 months ago

Zed extensions are sandboxeds with restricted permissions btw…

prodigycorp• 2 months ago

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?

ViAchKoN• 2 months ago

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

drewda• 2 months ago

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

Onplana• 2 months ago

If they tighten up things, it would impact the ease of use.

Pxtl• 2 months ago

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

lxxpxlxxxx2• 2 months ago

Is there any way to know if my repos were affected?

Bairfhionn• 2 months ago

If you work for Github you are likely affected.

lxxpxlxxxx2• 2 months ago

Oops, I missed the 'internal' part

freakynit2• 2 months ago

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/

dgellow8• 2 months ago

I genuinely wish you good luck keeping track of all npm issues to come

freakynit2• 2 months ago

lol.. thanks.. I'll try... not an easy work though :-P

danpalmer2• 2 months ago

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

wyclif4• 2 months ago

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

baxtr2• 2 months ago

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.

danpalmer2• 2 months ago

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.

exitb• 2 months ago

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?

21asdffdsa123• 2 months ago

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.

seanieb• 2 months ago

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?

gabrielgio2• 2 months ago

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

dannersy• 2 months ago

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.

camkego2• 2 months ago

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.

Balinares2• 2 months ago

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

giancarlostoro• 2 months ago

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.

srcoder• 2 months ago

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!

camkego2• 2 months ago

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.

nbf_1995• 2 months ago

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.

insanitybit5• 2 months ago

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.

no-name-here7• 2 months ago

… use Code Server in a docker container …

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

rrvsh• 2 months ago

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

aa-jv6• 2 months ago

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

zuhsetaqi• 2 months ago

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.

coldtea2• 2 months ago

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

miroljub• 2 months ago

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.

IshKebab2• 2 months ago

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.

notnullorvoid7• 2 months ago

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.

mfro• 2 months ago

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

jon-wood• 2 months ago

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.

sharts• 2 months ago

something something javascript, npm, etc.

cdnsteve• 2 months ago

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

brador• 2 months ago

The cloud is just someone else’s computer.

gizzlon• 2 months ago

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

elAhmo• 2 months ago

Insane to think GH has at least 3800 internal repos.

chii• 2 months ago

well, own dogfood and all that, i'm not surprised?

mrklol• 2 months ago

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.

zkmon• 2 months ago

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.

classified2• 2 months ago

Does it have a source-level debugger for Rust?

raxxorraxor2• 2 months ago

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.

dgellow8• 2 months ago

Are sublime text extension less risky?

BatteryMountain• 2 months ago

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.

classified2• 2 months ago

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

xyzal• 2 months ago

Sigh. I guess there isn't any "min-release-age" for extensions ...

furyman• 2 months ago

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.

9dev• 2 months ago

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.

shevy-java• 2 months ago

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.

Uptrenda• 2 months ago

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?

jakemm• 2 months ago

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

xeyownt• 2 months ago

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

panzi• 2 months ago

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.

HighGoldstein• 2 months ago

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.

insanitybit5• 2 months ago

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.

gchamonlive2• 2 months ago

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.

insanitybit5• 2 months ago

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.

hahn-kev• 2 months ago

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.

KnuthIsGod• 2 months ago

Each day NeoVim / LazyVim sounds better to me...

enbugger• 2 months ago

It shouldn’t. Same 3rd party extensions distribution model like in VSCode just written in Lua instead

gus_6• 2 months ago

https://www.reddit.com/r/neovim/comments/1j45stl/someone_wro...

jack-pissy• 2 months ago

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

ulimn• 2 months ago

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

dgellow8• 2 months ago

I might just go back to emacs :(

zeafoamrun• 2 months ago

That should be a :)

prmoustache2• 2 months ago

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.

lawn• 2 months ago

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

shandilyaharsh• 2 months ago

shouldn't anthropic give mythos access to github, prolly the most insecure piece of software while also being the most important one

lexybarton• 2 months ago

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.

vldszn6• 2 months ago

“Nx Console VS Code extension was the initial access vector in the GitHub breach”

Source: https://news.ycombinator.com/item?id=48216614

otikik• 2 months ago

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.

wvh• 2 months ago

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.

axegon_2• 2 months ago

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.

pseudocomposer• 2 months ago

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

anthk• 2 months ago

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.

Sweepi• 2 months ago

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

cess11• 2 months ago

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

zitterbewegung• 2 months ago

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

stalfosknight• 2 months ago

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

rTX5CMRXIfFG2• 2 months ago

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.

ferguess_k• 2 months ago

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.

keyle• 2 months ago

Never underestimate the power of procastination disguised as productivity!

emsign• 2 months ago

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.

locallost• 2 months ago

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.

ofjcihen• 2 months ago

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.

casey2• 2 months ago

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

thewebguyd• 2 months ago

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.

isityettime• 2 months ago

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

pojzon• 2 months ago

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.

felooboolooomba• 2 months ago

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.

sunshine-o4• 2 months ago

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?

AlienRobot2• 2 months ago

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.

lukewrites• 2 months ago

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

gib444• 2 months ago

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

buio• 2 months ago

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

luodaint• 2 months ago

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.

poelzi2• 2 months ago

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

wutwutwat2• 2 months ago

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.

poelzi2• 2 months ago

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

mixdup• 2 months ago

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)

snazarov92• 2 months ago

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.

zrn900• 2 months ago

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.

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

Related Stories