13 ms·

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

• gus_ 5mo 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 https://news.ycombinator.com/item?id=48191680
  • alexfoo 5mo 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 5mo 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_ 5mo 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.
      • alexfoo 5mo ago
        Ah yes, sandboxing/limiting a VSCode plugin is not impossible. I was thinking in more general terms (such as post install scripts within npm/python packages). Random test code in golang packages. There's an awful lot that people don't vet because keeping up with the vetting is a huge burden which seems pointless until you're the one that gets hacked. The trick is to infect a plugin that has a legitimate reason for accessing the internet or running certain commands, and then coming up with ways to abuse that to exfiltrate the data. Or exfiltrating via DNS queries, or some other vector that isn't so obvious as "allow TCP/UDP connections to the whole world". That or just repeatedly pester a user for permissions until one user (and you only need one within the organisation) relents and grants it.
        • gus_ 5mo ago
          the pop-ups fatigue is already an issue, and not an easy one to solve. Pretty much like SIEM/SOC alerts. > The trick is to infect a plugin that has a legitimate reason for accessing the internet or running certain commands, and then coming up with ways to abuse that to exfiltrate the data. Or exfiltrating via DNS queries, or some other vector that isn't so obvious as "allow TCP/UDP connections to the whole world". They'll get there, maybe. But the reality is that right now, everyone allows outbound requests blindly. Instead of speculating, I suggest to actually investigate current IOCs and common tactics of malicious npm/pip/plugins/VS extensions. Something like this: https://github.com/evilsocket/opensnitch/discussions/1119 https://github.com/evilsocket/opensnitch/discussions/1119 Or use OpenSnitch (or Lulu, Glasswire, ZoneAlarm anyone?:D etc) to actually analyze real VS malicious extensions or npm packages and see if it stops the exfiltration, and if not, suggest ways to improve it. For example: https://markdownpastebin.com/?id=9c294c75f09349d2977a4ccd250f0629 https://markdownpastebin.com/?id=9c294c75f09349d2977a4ccd250...
  • dang 5mo ago
    (We merged this thread hither - it was originally in https://news.ycombinator.com/item?id=48201316 https://news.ycombinator.com/item?id=48201316)
  • amluto 5mo 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".
    • applfanboysbgon 5mo 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.
      • dylan604 5mo ago
        > You're a programmer, right? This is my position as well, but it's rarely received well. Usually, a response like "why would I rewrite something that's already been written and available?" By writing the code, I know how it works. I know it is not infected with crap. I know it will not in the future be infected with crap from a down stream dependency. It seems to me this really took off with node to the point that it's laughable at what people will include with no thought at all. I know component libraries have existed for many other languages before, but node just stands out to me
        • lovich 5mo ago
          Most bosses look poorly upon spending their budget on rewriting software that already exists and simultaneously most bosses(although not the exact same set) don’t care about security until a disaster has already occurred. And it’s also not like you’re going to literally write every piece of software you use, unless you’ve started all the way down at machine code you’re drawing the line somewhere on using code written by other people.
• 2OEH8eoCRo0 5mo ago
  So which extension? Why don't they tell us?
  • vldszn 5mo ago
    There are rumours that was NX Console VS code extension https://github.com/nrwl/nx-console/security/advisories/GHSA-c9j4-9m59-847w https://github.com/nrwl/nx-console/security/advisories/GHSA-... https://www.stepsecurity.io/blog/nx-console-vs-code-extension-compromised https://www.stepsecurity.io/blog/nx-console-vs-code-extensio...
    • raverbashing 5mo ago
      Sounds like another "why even bother" extension, made to automate things that shouldn't be automated
    • vldszn 5mo ago
      [dead]
    • vldszn 5mo ago
      UPD: it’s confirmed now by the CEO of Nx https://x.com/jeffbcross/status/2057236396658811020?s=46&t=_RN2fQnPTv5buAq00Oxwaw https://x.com/jeffbcross/status/2057236396658811020?s=46&t=_...
      • bmandale 5mo ago
        > One of our developers was compromised by a recent supply-chain compromise on Tanstack ...which in turn was caused by bad design of github's CI pipeline. Funny how it all comes back around like that.
        • vldszn 5mo ago
          Yeah..full circle
  • cmg 5mo ago
• dang 5mo ago
  Previous thread in sequence: GitHub is investigating unauthorized access to their internal repositories - https://news.ycombinator.com/item?id=48201316 https://news.ycombinator.com/item?id=48201316 - May 2026 (321 comments)
• sunshine-o 5mo 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 5mo 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 5mo 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.
      • deleted 5mo ago
        [deleted]
      • dylan604 5mo ago
        At some point, these people will come up with a ransom-as-a-service that you can subscribe to make monthly payments. It's no different than having to pay criminals monthly for security to prevent them from harming your themselves.
  • deckar01 5mo 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-o 5mo ago
• jmclnx 5mo ago
  Another day another issue with Microsoft products, what else can be said :( At least they are being upfront these days.
• 1970-01-01 5mo ago
  But, it did not go down! Progress!
  • skullone 5mo ago
    Don't jinx it!
  • marcosdumay 5mo ago
    It's working, we just don't know what it's doing.
    • baq 5mo ago
      GitHub confirmed skynet
  • LkpPo 5mo ago
    No time to deploy, nobody must move a muscle during the forensic investigation!
• tekacs 5mo 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 5mo ago
    3800 is low for an org like GitHub. Glad it’s highly likely not all their repos are compromised.
    • organsnyder 5mo ago
      Given the attack vector, it's possible that the impacted repos were ones that see more activity.
  • eddythompson80 5mo 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 5mo ago
    It sounds low to me, I worked at a Fortune high number a few years ago and they had more.
  • dgellow 5mo ago
    I was part of an org with more than 15k repos
    • clutch_coder99 5mo ago
      Damn that's alot. I'm wondering how many engineers handled all that?
      • dgellow 5mo ago
        I cannot share much details, but one thing: livegrep had no issues handling that many repos! That project is such a blessing https://github.com/livegrep/livegrep https://github.com/livegrep/livegrep
• codedokode 5mo 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 5mo 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 5mo 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 5mo ago
      And volumes. Volumes are not fun with podman. Ironically my team tried GitHub Codespaces and never looked back. Super cheap and uses DevContainers.
      • unethical_ban 5mo ago
        What's the difference between Podman and docker for volumes? Other than needing to add Z to get volumes to mount with SELinux
        • NewJazz 5mo ago
          Maybe permissions when going rootlesz?
        • miki123211 5mo ago
          If you're root on a system and use Docker volumes, you can always `sudo ls` and access those volumes outside of the container. If you're just a user running containers under Podman, it's more tricky.
• josefritzishere 5mo ago
  Is it premature to blame AI Microslop?
  • dakiol 5mo ago
    It's definitely AI slop. So tired of pushing AI-generated crap to production at my company
  • efilife 5mo ago
    https://github.com/nrwl/nx-console https://github.com/nrwl/nx-console Looks like it
• innoying 5mo 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?source=friends_link&sk=57cd6a6d5c191eaa267cfac5ba2d035c 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/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/streaming-the-audit-log-for-your-enterprise https://docs.github.com/en/enterprise-cloud@latest/admin/mon... [2]: https://docs.github.com/en/enterprise-cloud@latest/authentication/authenticating-with-single-sign-on/about-authentication-with-single-sign-on https://docs.github.com/en/enterprise-cloud@latest/authentic... [3]: https://docs.github.com/en/enterprise-cloud@latest/authentication/authenticating-with-single-sign-on/authorizing-an-ssh-key-for-use-with-single-sign-on https://docs.github.com/en/enterprise-cloud@latest/authentic... [4]: https://docs.github.com/en/enterprise-cloud@latest/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/managing-allowed-ip-addresses-for-your-organization https://docs.github.com/en/enterprise-cloud@latest/organizat... [5]: https://docs.github.com/en/enterprise-cloud@latest/organizations/managing-programmatic-access-to-your-organization/setting-a-personal-access-token-policy-for-your-organization#restricting-access-by-personal-access-tokens https://docs.github.com/en/enterprise-cloud@latest/organizat... [6]: https://edu.chainguard.dev/open-source/octo-sts/overview/ https://edu.chainguard.dev/open-source/octo-sts/overview/ [7]: https://docs.github.com/en/enterprise-server@3.16/admin/monitoring-and-managing-your-instance/monitoring-your-instance/about-system-logs#log-files-for-the-http-server https://docs.github.com/en/enterprise-server@3.16/admin/moni...
• a-dub 5mo ago
  [dead]
• fg137 5mo 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 https://github.com/microsoft/vscode/issues/52116 [1] https://news.ycombinator.com/item?id=42979994 https://news.ycombinator.com/item?id=42979994 [2] https://news.ycombinator.com/item?id=46855527 https://news.ycombinator.com/item?id=46855527
  • zx8080 5mo 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 5mo ago
    Why would you sandbox extension? Just don’t install crap maybe.
    • Hackbraten 5mo ago
      Any good, benign extension can be taken over and weaponized with malware.
    • pixl97 5mo ago
      This mans security onion has one layer.
    • Gigachad 5mo 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.
    • 5mo ago
• notnullorvoid 5mo ago
  I really hope this pushes Microsoft to add a explicit permission system to VS Code extensions, and improve security of dev containers.
  • fg137 5mo ago
    Not holding my breath. This issue has been open since 2018 https://github.com/microsoft/vscode/issues/52116 https://github.com/microsoft/vscode/issues/52116
    • notnullorvoid 5mo 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.
  • pamcake 5mo 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.
    • notnullorvoid 5mo 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.
      • TiredOfLife 5mo ago
        Zed is even worse about arbitrarily downloading random stuff from random websites and executing it
        • notnullorvoid 5mo ago
• BrunoBernardino 5mo 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.
• vldszn 5mo 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 https://github.com/zizmorcore/zizmor - set locally: pnpm config set minimum-release-age 4320 # 3 days in minutes https://pnpm.io/supply-chain-security https://pnpm.io/supply-chain-security - for other package managers check: https://gist.github.com/mcollina/b294a6c39ee700d24073c0e5a4e93104 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-actions https://docs.socket.dev/docs/socket-firewall-free#github-act...
  • arandomhuman 5mo ago
    friendly reminder: use vim :)
    • vldszn 5mo ago
      =)
    • leni536 5mo ago
      It honestly surprises me we don't hear news about vim/neovim plugin supply chain attacks.
      • arandomhuman 5mo ago
        probably a much smaller dependency graph (lesser usage of transitive dependencies)
      • gus_ 5mo ago
        https://www.reddit.com/r/neovim/comments/1j45stl/someone_wrote_malicious_code_in_the_neovim_plugin/ https://www.reddit.com/r/neovim/comments/1j45stl/someone_wro...
    • IcyWindows 5mo 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.
• psadauskas 5mo 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 5mo ago
    i mean, then you say it like that…
    • midtake 5mo ago
      Microsoft is the inverse hand of Midas, turns everything into shit.
      • dbalatero 5mo ago
        Mierdas, as they say.
      • bhadass 5mo ago
        these days it's just Microslop
      • pixl97 5mo ago
        With $101 billion in profit last year I wish I could turn things into $hit as well as they do.
        • andrei_says_ 5mo ago
          You could, with a large enough captive audience.
          • jrgd 5mo ago
            or a large enough hand
      • loloquwowndueo 5mo ago
        Everything Microsoft makes sucks. If they decided to make vacuum cleaners though, they wouldn’t suck, they would blow.
• thrawa8387336 5mo ago
  Who uses GitHub in 2026
• schpet 5mo 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 5mo 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 5mo 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.
• cdrnsf 5mo ago
  That's one way to make things open source.
  • dlcarrier 5mo 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.
• assanineass 5mo ago
  [dead]
• LeoPanthera 5mo 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 5mo ago
    someone above mentioned it's been confirmed as nx console here: https://github.blog/security/investigating-unauthorized-access-to-githubs-internal-repositories/ https://github.blog/security/investigating-unauthorized-acce...
• aizk 5mo ago
  And now, the hackers will be able to scan the repos for more vulnerabilities. Vulnerabilities all the way down.
• urbandw311er 5mo 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-c9j4-9m59-847w https://github.com/nrwl/nx-console/security/advisories/GHSA-...
  • K3UL 5mo ago
    GitHub confirmed that it's indeed the nx console extension, in their blog post: https://github.blog/security/investigating-unauthorized-access-to-githubs-internal-repositories/ https://github.blog/security/investigating-unauthorized-acce...
    • urbandw311er 5mo 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 5mo ago
  A good day not to be using Electronjs trash.
  • Gigachad 5mo ago
    Electron has nothing to do with the exploit here. A Vim plugin would have just as much ability to run malware.
    • skydhash 5mo 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.
      • Gigachad 5mo ago
        I’m not sure this is true. Vim needs extensions even more than VS code since many basic features like full project code search or go to definition aren’t in the base vim. And vim has package managers that make installing and updating packages as easy as vs code. VS Code like npm are only the targets because they are the most popular, not because they are uniquely vulnerable.
        • tliltocatl 5mo ago
          > full project code search grep > go to definition /definition Not even using vim, I'm more of a micro person.
• QuantumNoodle 5mo ago
  I'm more surprised hackers found a large enough uptime window to do this.
  • hungryhobbit 5mo 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 5mo 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.
    • QuantumNoodle 5mo ago
      Giggity.
    • miki123211 5mo ago
      *since coding agents caused their commit rate to increase 14x.
      • platevoltage 5mo ago
        A problem that they contributed to.
        • nicce 5mo ago
          Maybe they actually try to increase the uptime now by making Copilot plans worse.
  • gjtorikian 5mo ago
    Copying a joke posted somewhere else? Wow https://x.com/anshuc/status/2056898035159056558 https://x.com/anshuc/status/2056898035159056558
• mcoliver 5mo 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.
  • Gigachad 5mo 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.
    • charlieyu1 5mo 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.
      • inlined 5mo ago
        What are you withholding from the sandbox without making it useless?
        • atq2119 5mo ago
          Internet access. An editor extension does not need it.
          • sedatk 5mo ago
            All AI agent extensions disagree in unison.
• purpleidea 5mo ago
  What's inside the canada.tar.gz one?
• pamcake 5mo 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 5mo ago
  question is why are people still using vscode or coding by hand?
• dotwaffle 5mo 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 5mo 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 5mo ago
  Why is the extension not being named?
  • TiredOfLife 5mo ago
    Because the link is blogspam. https://github.blog/security/investigating-unauthorized-access-to-githubs-internal-repositories/ https://github.blog/security/investigating-unauthorized-acce... links to https://github.com/nrwl/nx-console/security/advisories/GHSA-c9j4-9m59-847w https://github.com/nrwl/nx-console/security/advisories/GHSA-... Nx Console
• CivBase 5mo 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 5mo 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 5mo 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.
• fhn 5mo ago
  Good. They are eating their own dog food
• eneveu 5mo 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 5mo ago
    If you don't do it for every update, then there is no real point in doing that in the first place.
• kittikitti 5mo 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.
• zx8080 5mo 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-here 5mo 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-access-to-githubs-internal-repositories/ https://github.blog/security/investigating-unauthorized-acce... > “unnamed” Why is “unnamed” in quotation marks?
• efilife 5mo ago
  What was the extension what the fuck? No mention of the name anywher?e
• nullbio 5mo ago
  This is why uninstalled 90% of my VSCode extensions last year. The writing is/was on the wall.
• monster_truck 5mo ago
  Where's the torrent
• mococa 5mo ago
  Zed extensions are sandboxeds with restricted permissions btw…
• prodigycorp 5mo 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?
  • itake 5mo ago
    [dead]
  • ViAchKoN 5mo 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 5mo 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-3854 https://www.wiz.io/blog/github-rce-vulnerability-cve-2026-38...
• Onplana 5mo ago
  If they tighten up things, it would impact the ease of use.
• Pxtl 5mo 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!"
• cnguyen1494 5mo ago
  [flagged]
• vladsiu 5mo ago
  [dead]
• lxxpxlxxxx 5mo ago
  Is there any way to know if my repos were affected?
  • Bairfhionn 5mo ago
    If you work for Github you are likely affected.
    • deleted 5mo ago
      [deleted]
    • lxxpxlxxxx 5mo ago
      Oops, I missed the 'internal' part
• freakynit 5mo ago
  Updated: Catalog of all major npm/nodejs ecosystem attacks since May 2025-2026: https://npm-supply-chain-attacks-25-26.pagey.site/ 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/ https://npm-supply-chain-attack-techniques.pagey.site/
  • dgellow 5mo ago
    I genuinely wish you good luck keeping track of all npm issues to come
    • freakynit 5mo ago
      lol.. thanks.. I'll try... not an easy work though :-P
• danpalmer 5mo ago
  Why does a company in GitHub's place allow employees to install random VSCode extensions?! That seems grossly irresponsible.
  • wyclif 5mo ago
    You're assuming they allow it, but it might be against policy.
    • baxtr 5mo 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.
      • hhh 5mo ago
        They can enforce it with an MDM. Policy should be enforced where possible not just notified to people.
        • baxtr 5mo ago
          Absolutely agree. But enforcing is so much more effort than creating wiki pages with LLMs.
    • danpalmer 5mo 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.
      • paholg 5mo ago
        When I worked at Amazon, I had to run a special Amazon Linux. But I could just install whatever I wanted. I used emacs with whatever plugins I wanted. Big tech can be suprisingly not locked down!
• camkego 5mo 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.
  • Balinares 5mo 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_npm_supply_chain_attack_hits_tanstack/ https://www.reddit.com/r/programming/comments/1tapmvi/mass_n...
    • giancarlostoro 5mo 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.
      • jay_kyburz 5mo ago
        No doubt an unpopular opinion, but if I install an app that is going to do things in the background, I'm going to hold that apps developers responsible for any breaches. If Zed needs javascript to do its job, it probably should be downloading it from their own servers, or even better, just ship the editor with all the code it needs to do its job.
        • fc417fc802 5mo ago
• sharts 5mo ago
  something something javascript, npm, etc.
• cdnsteve 5mo ago
  So basically we are now waiting for a wave of massive new exploits coming via GitHub itself. Lovely
  • brador 5mo ago
    The cloud is just someone else’s computer.
• gizzlon 5mo 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 5mo ago
  Insane to think GH has at least 3800 internal repos.
  • chii 5mo ago
    well, own dogfood and all that, i'm not surprised?
  • mrklol 5mo 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 5mo 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.
  • classified 5mo ago
    Does it have a source-level debugger for Rust?
  • raxxorraxor 5mo 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.
  • dgellow 5mo ago
    Are sublime text extension less risky?
• NexraGear 5mo ago
  [flagged]
• BatteryMountain 5mo 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.
• classified 5mo 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 5mo ago
  Sigh. I guess there isn't any "min-release-age" for extensions ...
• furyman 5mo 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 5mo 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 5mo 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 5mo 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 5mo 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 https://github.com/microsoft/vscode/issues/52116
  • xeyownt 5mo ago
    "VSCode Sadbox" -- pun intended or not, that's funny :-)
  • panzi 5mo 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 5mo 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.
    • insanitybit 5mo 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.
  • gchamonlive 5mo 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.
• KnuthIsGod 5mo ago
  Each day NeoVim / LazyVim sounds better to me...
  • enbugger 5mo ago
    It shouldn’t. Same 3rd party extensions distribution model like in VSCode just written in Lua instead
  • gus_ 5mo ago
    https://www.reddit.com/r/neovim/comments/1j45stl/someone_wrote_malicious_code_in_the_neovim_plugin/ https://www.reddit.com/r/neovim/comments/1j45stl/someone_wro...
• jack-pissy 5mo 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 5mo 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...
  • dgellow 5mo ago
    I might just go back to emacs :(
    • zeafoamrun 5mo ago
      That should be a :)
      • dgellow 5mo ago
        Maybe, but I remember why I left my beloved-but-extremely-slow emacs :p
  • prmoustache 5mo 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 5mo ago
    Both Emacs and Neovim gives you full control IF yhats what you're after.
• shandilyaharsh 5mo ago
  shouldn't anthropic give mythos access to github, prolly the most insecure piece of software while also being the most important one
• lexybarton 5mo 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.
• deleted 5mo ago
  [deleted]
• vldszn 5mo ago
  “Nx Console VS Code extension was the initial access vector in the GitHub breach” Source: https://news.ycombinator.com/item?id=48216614 https://news.ycombinator.com/item?id=48216614
• otikik 5mo 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 5mo 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_ 5mo 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.
    • clownpenis_fart 5mo ago
      [dead]
    • pseudocomposer 5mo 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…
      • AshamedBadger56 5mo ago
        I assumed they are meaning VSCode plugins that "hook" into the system.
      • axegon_ 5mo ago
        I assume they are called hooks, .vscode/settings.json - you can put some linters/tests which run automatically (from my understanding, something similar to git hooks, hence the reason I called them hooks). I generally hate the concept and I generally dislike vscode so... yeah.
• shawakash54 5mo ago
  [flagged]
• Oxlamarr 5mo ago
  [flagged]
• felooboolooomba 5mo 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-o 5mo 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?
    • AlienRobot 5mo 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.
      • neop1x 5mo ago
        For linux we have bubblewrap, firejail, apparmor and selinux (popular ones, there are far more). But it is often complicated and annoying to set up. Normally one would expect sw developers would write security rules for their apps but it is difficult due to amount of different sandboxing tools and various distro-specific configuration changes. It would be nice to have it sorted out somehow. Actually Snap is an interesting example of something done in that regard.
• buio 5mo 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 5mo 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.
• poelzi 5mo 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 :)
  • wutwutwat 5mo 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.
    • poelzi 5mo 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
• CroviaTrust 5mo ago
  [flagged]
• ryanshrott 5mo ago
  [flagged]
• mixdup 5mo 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)
• rohitsriram 5mo ago
  [dead]
• snazarov92 5mo 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 5mo 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.
• jas-park-dev 5mo ago
  [flagged]
• throwawaypath 5mo ago
  [flagged]