The news that every software development team feared has come true: GitHub confirmed that an attacker gained access to and extracted content from approximately 3,800 internal (GitHub-internal) repositories, following an incident on an employee's device who had installed a poisoned Visual Studio Code extension.
According to the company's public statement (as reported by international media), GitHub detected and contained the breach, removed the malicious version of the extension, isolated the endpoint, and immediately initiated incident response. The company's current assessment is that the activity was limited to the export of GitHub-internal repos, with no indication so far of an impact on customer data outside of internal repositories.
The case is linked to claims by TeamPCP on cybercrime forums, where there was talk of “~4,000 private code repos.” The hackers demanded at least $50,000 to sell the data (with the classic “it’s not a ransom, it will be sold to a buyer” rhetoric).
See also: GitHub Actions: Supply chain attack steals CI/CD credentials
Why this incident is different (and more worrying)
The "hardest" part of the story is not just the number of repos. It's the pattern: an everyday work tool (editor extension) turns into a Trojan horse and gains access to everything the developer sees: tokens, credentials, config files, environments, even access to private code. The chain of trust breaks where you least expect it: at the workstation.
In practice, even if an extension "seems harmless," it can:
– read files in the home directory,
– detect environment variables,
– “lift” tokens (GitHub, cloud, package registries),
– affect CI/CD through stolen secrets,
– pave the way for a second wave of attack (build pipeline compromise).
GitHub breach: What we know so far (in simple terms)
– GitHub says the entry point was an employee device with a poisoned VS Code extension.
– The company says it has no indication of impact to customer data outside of GitHub-internal repos (for now).
– The hackers’ claims of scale (~3,800 repos) are considered consistent with the investigation.
See also: Gemini CLI: Critical vulnerability allowed supply chain attacks
The crucial question for the market: Does it affect other organizations?
Even if the breach only concerns GitHub-internal code, the incident is a wake-up call for everyone: the “trust marketplace extensions” model without governance and allowlisting should not exist. The real damage in such attacks is often not the initial leak, but the follow-on: stolen secrets that are quietly used weeks later.
What DevSecOps teams should do today
1) Immediately inventory and audit VS Code extensions
– Record which extensions are installed on corporate devices.
– Remove those that are not absolutely necessary.
– Implement allowlist corporately (approved publishers/IDs only).
2) Limit the secrets that the workstation “sees”
– Stop having long-lived tokens in plain text (e.g. in dotfiles).
– Use short-lived credentials where possible.
– Isolate signing keys/critical secrets outside of developer endpoints.
3) Rotation on high-risk keys
Even if you are not GitHub, the incident shows what can happen if a token “leaks” from a workstation. Start rotation with:
– GitHub tokens / fine-grained tokens,
– CI/CD secrets,
– cloud API keys,
– package registry tokens,
– production credentials.
4) Check logs and anomalies
– Inspect audit logs on GitHub/CI for unusual clones, new tokens, and access to repos that don't fit the team's profile.
🔒 Protect your privacy with Proton VPN
Swiss VPN from the creators of Proton Mail — strict no-logs policy, strong encryption, and built-in NetShield that blocks ads, trackers, & malware.
- ✔ No-logs, based in Switzerland (except 14-Eyes)
- ✔ NetShield: blocks ads, trackers & malicious domains
- ✔ Covers all devices — free version available
The link is an affiliate link — SecNews may receive a commission at no additional cost to you. It does not affect the independence of our article writing.
See also: OpenAI confirms breach via TanStack supply chain attack
What does it mean for Greece/businesses/admins/users?
For Greek software companies, startups, banks and organizations that “run” CI/CD on GitHub, the incident is a practical reminder that security does not end at the account’s MFA. The attack can start from an extension, an npm dependency or a plugin and end in a code/secret leak. For IT/security teams in Greece, the priority is governance in developer tools (extensions, package managers, runners) and strict secrets management.
Source: https://www.bleepingcomputer.com/
