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:

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

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:

[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

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.