GitHub's Internal Repos Breached Via Employee's Use of Malicious VS Code Extension (bleepingcomputer.com) 21
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.
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 (Score:2, Insightful)
But in reality it can happen w/any system that has open-submit add-ons.
Re: (Score:2)
Re: (Score:2)
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: (Score:3)
Re: (Score:2)
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: (Score:2)
Diabolical. (Score:2)
Re:Diabolical. (Score:4, Insightful)
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: (Score:1)
Which in practice means "no open source tools"
Re: (Score:2)
Nope. That is insightless nonsense. It has nothing to do with open or closed.
Nobody admits it: supply chain attacks are EASY (Score:2)
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: (Score:2)
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: (Score:3)
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 (Score:3)
So I guess my comment is: Mission accomplished, Microsoft.
Re: (Score:2)
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 (Score:2)
In before you detect my supply chain attack.
Extension Unconfirmed (Score:2)
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: (Score:1)
Seems irresponsible to me.
Shouldn't the first order of business be to announce what extension was compromised so others can avoid it?
Re: (Score:2)
Re: (Score:1)
My point is there shouldn't be any "likely" or "probably" involved here.
The announcement should clearly state what the threat vector was.