GitHub's Internal Repos Breached Via Employee's Use of Malicious VS Code Extension

Longtime Slashdot reader Himmy32 writes: GitHub has announced on X that their internal repositories have been breached through a compromised VS Code Extension on an employee's workstation. Bleeping Computer reported that the attack is linked to TeamPCP who have been in the news for a recent campaign affecting Checkmarx, Trivy, SAP, TanStack, and Bitwarden. The group appears to be attempting to sell the stolen code on cybercrime forums. "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," the company said. "Our current assessment is that the activity involved exfiltration of GitHub-internal repositories only. The attacker's current claims of ~3,800 repositories are directionally consistent with our investigation so far."

Although the investigation remains ongoing, GitHub says it has "no evidence of impact to customer information stored outside of GitHub's internal repositories." The company has also not said whether it's in contact with the hackers or if it's received a ransom demand.

I'd like to say "Use Pulsar" because I do

[Tora]

But in reality it can happen w/any system that has open-submit add-ons.

Re:

[MIPSPro]

I'm too old and cranky to stop using cvs and/or git exclusively at home. For my own FOSS projects, I simply distribute a signed code tar ball and supply my GPG public key on the websites. I understand why some folks use free repositories, but it's never made sense for my projects and I can't really see where it's worth the risk to myself or my users in this age of supply chain attacks. I don't see Github surviving this. Anyone who sticks with them at this point is pretty ideological or just stubbornly igno

Re:

[tlhIngan]

It's less about the repository and more about the whole lifecycle tracking it provides.

It hosts code, but it also provides an environment to report issues, and have those issues tracked through to a commit. It also makes it easy to handle contributions from other people.

If you have a small project, it's no big deal to do it manually. But once a project gets big enough, you really want something to track bugs, support tickets, fixes, releases, pull requests and code reviews.

And "big enough" is basically at t

Re:I'd like to say "Use Pulsar" because I do

[martin-boundary]

You don't have control over users. For my ancient Free projects, I've always hosted them on my own personal site. However because they are GPL, some people "helpfully" host a copy on GitHub. I don't particularly like it but they've done it. I don't update their copy or fix any bugs there.

Re:

[Hentes]

While it can happen to any IDE, most serious IDEs like Eclipse have a pretty well organized repo, VSCode is an outlier with its addon market being a free for all. I normally prefer freedom, but given how much damage a malicious addon can cause I feel like some moderation is warranted here.

Re:

[Himmy32]

Well, any system that has unsandboxed or restricted extensions. Something like Zed that has extensions compiled to WebAssembly and then can restrict the capabilities [zed.dev] is a more secure model.

Re:

[ceoyoyo]

Use the most basic text editor you can find. Type your git commit on the command line with your own fingers like Linus intended.

Diabolical.

[Iamthecheese]

I hate the overuse of the word "diabolical" but in this one case, it fits. There's no way a normal coder could detect this. The only fix is to lock down your whole stack rigidly, and pay the price in productivity and unhappy developers.

Re:Diabolical.

[gweihir]

Lets rephrase that a bit: There is a away that any sane coder can avoid this with high probability: Not installing add-ons that have bad supply-chain security on critical systems. Such as systems with access to critical repositories. This is also something you find in _every_ serious security control catalog: Separate, specially secured machines to be used for any high-privilege access paths.

How do you tell an add-on has bad supply chain security? Simple: Do you have good evidence that they have solid security? No? Then you must assume it is bad. There is higher productivity and there is plain gross negligence. Installing add-ons with questionable security in a productive environment except on carefully privilege restricted machines is completely unacceptable and strictly forbidden in any well-run enterprise.

It was also far less bad than what could have happened. The attacker only stole code. The attacker could have added backdoors and other malware to the repositories instead.

There is really noting "diabolical" here. Just an entirely expected attack type hitting a woefully unprepared target and target organization.

Re:

[Iamthecheese]

>Do you have good evidence that they have solid security? No? Then you must assume it is bad.

Which in practice means "no open source tools"

Re:

[gweihir]

Nope. That is insightless nonsense. It has nothing to do with open or closed.

Re:

[coofercat]

I'd say 'diabolical' could fit here, for these reasons:

1) Github is owned by Microsoft
2) VSCode, and it's extensions marketplace are owned by Microsoft
3) The data lost was far in excess of what any one developer with a malicious extension should have had access to

They, more than anyone else, could have/should have vetted the marketplace before letting their people install random crap from it. They could have potentially made VSCode more resistant to malicious extensions. They could have publicly vetted the

Re:

[gweihir]

Well, in the sense that Microsoft becomes a bigger and bigger problem with regard to security, I do agree

Nobody admits it: supply chain attacks are EASY

[MIPSPro]

NPM has been pretty solid proof but all over you see supply chain attacks on systems that rely in low-or-no vetting for code submissions and now we also see "upstreaming" where they attack the supply chain network itself or the network operator in order to be able to drop code anywhere they want.

It sucks, but the only way is to do a LOT more vetting. This of course puts FOSS at a disadvantage, unfortunately. The initiative is usually carried by the attacker. So, until the spy-vs-spy counter-AI-supply-cha

Re:

[gweihir]

Well, nobody that makes their money as a supplier and supporting suppliers admits it. Independent security experts have warned of this type of attacks being far too easy for a decade or two. This is not the first such attack. On top of that, LLM-type AI has put this kind of attack withing reach of pretty low skill attackers.

I do agree that more vetting is needed. Also, amateur-hour in supply-chains needs to be over. I am not saying FOSS needs to be over, but some insight into software security and supply ch

Re:

[MIPSPro]

People screw up badly all the time. So, these types of attacks will happen probably regardless of AI making it that much easier to pull off. I'm curious when you say "but some insight into software security and supply chain security will also be required from people doing FOSS. That is unfortunate, bit the only way." Since you always come across as a big-government communist type, what's your solution, a big prison term for any FOSS author who doesn't fix vulnerabilities? Gulags for volunteers? "Comrade we'

Re:

[gweihir]

You sound really stupid and disconnected here. I am neither "communist" nor "big government" and that is blatantly obvious from what I write. I am anti-stupid though, and that directly concerns you.

Obviously, the only punishment for insecure FOSS is irrelevancy.

Re:

[CAIMLAS]

There's another way to mitigate this, and it's ideologically difficult for a lot of Open Source people to accept... but you'll have to diverge from the tried and true path. AI makes this much easier: instead of using $popular_thing_everyone_uses, you use something else - either COTS or roll-your-own. Yes, it might be bugs, and yes, they might be security bugs, but unless they're painfully obvious issues where you didn't do your due diligence, it's going to be a more obscure target which will require more ta

Re:

[drinkypoo]

There's another way to mitigate this, and it's ideologically difficult for a lot of Open Source people to accept...

The big problem is not ideological.

but you'll have to diverge from the tried and true path. AI makes this much easier: instead of using $popular_thing_everyone_uses, you use something else - either COTS or roll-your-own. Yes, it might be bugs, and yes, they might be security bugs, but unless they're painfully obvious issues where you didn't do your due diligence, it's going to be a more obscure target which will require more targeted attacks.

Humans are vulnerable to making the same kinds of errors, and security is hard, so you're going to either be highly likely to make predictable errors that are going to be easy to find or you're going to need to pull in some libraries to handle security.

No, this doesn't solve anything and it's 100% "security through obscurity".

IOW it's not a useful suggestion, especially now that there are exciting new tools for finding vulnerabilities rapidly.

Re:

[MIPSPro]

I think the truth of either thesis will be determined by how many RCE's they find in things like IP/TCP stacks and always-on-can't-block-them services like OpenSSH. So far, given the size of the attack surface, the OpenBSD team is beating the living dogshit out of AI. That might change, but they haven't even found any RCE's in *any* OS that are that fundamental. So, if being secure means just turning off old services you don't need anyway, and maybe moving toward something like port-knocking to expose your

Re:

[drinkypoo]

Of course, I've always said that if you have untrusted users you are fucked. LPEs are a dime a dozen and can break anything, even VMware tenant separation.

The problem is, you're going to be opening connections outward, and you might be compromised that way. Say, through your browser. As long as LPE remains possible then that opens the door to owning your whole system, to say nothing of the damage they can do to your data even without one.

GitHub

[PPH]

... was an important resource for open source projects for many years. Since Microsoft took it over, it seems to be falling on its face frequently.

So I guess my comment is: Mission accomplished, Microsoft.

Re:

[gweihir]

Indeed. Microsoft "security is our highest priority" security level successfully established!

Why am I not surprises these people screw up massively time and again. I mean who overlooked that such addons have no business being on a system with high access privileges? But now, a separate system for admin work is obviously too expensive...

In before

[awwshit]

In before you detect my supply chain attack.

Extension Unconfirmed

[Himmy32]

Apparently which extension is still unannounced, from StepSecurity's reporting on the breach [stepsecurity.io]:

Update: On May 19, 2026, GitHub publicly disclosed that approximately 3,800 of its internal source code repositories were exfiltrated after an employee's device was compromised by a poisoned VS Code extension. GitHub has not named which VS Code extension was involved. Given the timing, many in the security research community believe the Nx Console compromise described in this post is a likely candidate, although this has not been confirmed by GitHub.

Re:

[innocent_white_lamb]

Seems irresponsible to me.

Shouldn't the first order of business be to announce what extension was compromised so others can avoid it?

Re:

[Himmy32]

It is likely that it was Nx Console since that's the only recent announcement. And that was only breached for under an hour. So it probably won't be avoid it, but to deal with the consequences. If you had it installed and VS Code running, then you hopefully panic rotated all of your keys already.

Re:

[innocent_white_lamb]

My point is there shouldn't be any "likely" or "probably" involved here.

The announcement should clearly state what the threat vector was.

Re:

[Himmy32]

You aren't going to find me disagreeing with you on that point.

Just the second point is that if you had the extension and the app open, you'd be screwed. So by the time there's any announcement, avoidance is already moot and the package already removed from the extension store. Any extension right now is vulnerable to the same attack.

Microsoft being Microsoft.

[found404]

VS Code from Microsoft. Github, Microsoft owned. Security researchers have been warning about this for years. Microsoft was told, repeatedly. Microsoft "did" what it always does - cash their paychecks, laughing all the way to the bank.