Top
Best
New

Posted by Timofeibu 10 hours ago

GitHub confirms breach of 3,800 repos via malicious VSCode extension(www.bleepingcomputer.com)
Previous thread in sequence:

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

421 points | 136 commentspage 2
schpet 3 hours 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.
alexfoo 2 hours 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"

schpet 1 hour 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 hours 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.
dotwaffle 1 hour 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?
1970-01-01 4 hours ago||
But, it did not go down! Progress!
marcosdumay 3 hours ago||
It's working, we just don't know what it's doing.
baq 3 hours ago||
GitHub confirmed skynet
LkpPo 3 hours ago|||
No time to deploy, nobody must move a muscle during the forensic investigation!
skullone 4 hours ago||
Don't jinx it!
fg137 4 hours 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

bbor 2 hours 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 :(
zx8080 3 hours 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!

ozim 2 hours ago||
Why would you sandbox extension?

Just don’t install crap maybe.

fhn 10 minutes ago|||
thanks for the sage advice. Next time you are infected with the flu you should just don't breath maybe.
Hackbraten 2 hours ago||||
Any good, benign extension can be taken over and weaponized with malware.
Gigachad 59 minutes 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.
pixl97 2 hours ago|||
This mans security onion has one layer.
pamcake 2 hours 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?
purpleidea 2 hours ago||
What's inside the canada.tar.gz one?
innoying 4 hours 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...

LeoPanthera 2 hours 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 54 minutes ago|
someone above mentioned it's been confirmed as nx console here: https://github.blog/security/investigating-unauthorized-acce...
2OEH8eoCRo0 4 hours ago||
So which extension? Why don't they tell us?
cmg 4 hours 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 4 hours 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...

nightpool 4 hours 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?

cmg 2 hours ago||
That’s very possible. I switch between Cursor and VS Code, don’t remember which it was that day.
vldszn 4 hours 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 4 hours ago|||
Sounds like another "why even bother" extension, made to automate things that shouldn't be automated
vldszn 3 hours ago|||
[dead]
BrunoBernardino 4 hours 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.

More comments...