The GitHub breach wasn't clever, and that should worry you

Almost a decade later, the mechanics of this type of breach have barely changed: break in somewhere, abuse the trust afforded by the breached company's reputation, and use its signed software updates to push legitimate-looking malware straight past the external controls of third parties. In May 2026, GitHub posted that attackers had breached and stolen the data of almost 4,000 of its internal repositories; the company that stores the world's code lost its own. On the surface you could imagine this as another complex breach of a well-hardened victim, but it wasn't. There was no sophisticated zero-day; nobody breached a GitHub application or exploited any weakness in GitHub's external estate directly. Instead, one GitHub employee installed a valid Visual Studio Code extension, a poisoned build of Nx Console, a tool installed on roughly 2.2 million machines globally and the malicious code went to work. It scraped the developer's credentials and phoned home with them, which let the attackers pivot into the internal repositories and walk away with the private data.

This is the same playbook as CCleaner, with very few changes. Supply chain attacks like these exploit the implicit trust we all place in third parties, rather than vulnerabilities in our security controls or our people. Every piece of software used, every extension marketplace downloaded from, and every CI pipeline runs on an assumption that the thing you are installing is fine, because a) the publisher is known, b) the install count is high, and (critically) c) it has always been fine before.

Start at the End

As with all supply chain attacks, this GitHub breach was not an isolated incident, it was a link in a chain, and understanding that chain is the key to understanding the breach as a whole.

On a Red Team engagement against something like an Active Directory environment, we start from the goal, say a Domain Administrator account, or whichever account or group unlocks the crown jewels in legal, HR or finance, and work backwards. We identify who or what can grant those privileges, then how to reach them, mapping the web of privileges back to our standing start before attacking forward up that chain, using legitimate paths so as not to trip any alarms. Planning an attack like the GitHub breach works the same way: start at the goal, and trace how one might reach it while setting off as few alarms as possible.

• The crown jewels are GitHub's internal repos. Hacking in directly seems unlikely.
• The standing start is nothing, but we have a trick: GitHub employees are likely to be using a range of VS Code extensions.
• We also know Microsoft has malware-scanning weaknesses between an extension being submitted and published, and there is a gap to exploit.
• Get credential-scraping code into an extension the GitHub team uses, and it can detonate inside GitHub and exfiltrate credentials.
• With valid credentials we can access what we need without tripping any safeguards, because every process between installing the extension and logging in is working exactly as intended.

It just so happens that TeamPCP (UNC6780 to Google's threat intelligence team) had recently exploited a pull_request_target weakness in TanStack: by poisoning its GitHub Actions build cache and waiting for the code to execute, they compromised the TanStack package. TanStack was consumed in some way by Narwhal Technologies, the company that maintains Nx Console. Once into Nx, they placed a credential harvester in the package, signed it, and published. That's the in. A GitHub employee downloads and runs the Nx Console extension, trusting its prior provenance, known publisher, high downloads, protects them implicitly. The code executes in the context of a VS Code extension, credentials are stolen, and GitHub's internal repos are accessed.

Three things about this chain stand out, and none of them were luck:

• The attacker did not rely on anyone slipping up, as in a traditional social engineering exercise. Nx Console is not some dodgy package from a nobody; developers install it precisely because it has the install numbers, the verified-publisher tick and the marketplace pedigree that imply earned trust.
• They relied on speed, but not on luck. The poisoned extension sat on the marketplace for only eleven to eighteen minutes before being pulled. That reads like a fluke, or a race condition, but it is neither. VS Code and editors like it update extensions automatically, so any machine set to auto-update that checked in during that window installed the malicious Nx build, with no review step and no cooling-off period between publish and install. The attacker does not need to lie dormant for long; once launched, a few minutes will do.
• The laptop was never the goal. The credential stealers in these campaigns are tuned for what lives on a developer's machine: GitHub and npm tokens, cloud keys, secrets-manager material. The workstation was just a hop in the chain towards the CI/CD systems, source repos and production environments that were the real targets.

This is a pattern, not a freak event

Treating this as a lucky break or a freak event is folly. It belongs to a much larger pattern of attacks that any threat model worth its salt has to assume is ongoing.

The pattern is well documented by now, and not limited to this credential-theft example. A few other notable examples from the last decade, far from an exhaustive list, are worth reading up on:

• 2020 – SolarWinds / SUNBURST. Russian intelligence breached the build system for SolarWinds' Orion network monitoring product and inserted a backdoor.
• 2024 – XZ Utils / liblzma. To avoid detection, the attacker spent years legitimately maintaining the xz compression library before inserting a backdoor into liblzma.
• 2025 – the Shai-Hulud worm. A self-propagating worm, very similar in attack vector to the TanStack > Nx Console > GitHub credential-harvesting run.

You cannot defend what you cannot list

Partly due to the complexity of internal corporate networks, and partly due to budget pressure, many organisations lean on their external surface to stop the majority of attacks, leaving a blind spot around third-party risk. When a campaign like the GitHub attack happens, security teams face the same blunt question from management: "Are we exposed to this?" – a question answered in an afternoon by teams in the know, or after weeks or months of manual digging, if ever.

This is the best case for a robust Software Bill of Materials (SBOM). An SBOM produced once as a tick-box exercise is about as useful as a paper umbrella, it looks great until the rain starts. One that is regenerated continuously, version-controlled alongside the code it describes, and genuinely queryable during an incident is the difference between answering management by lunchtime and a week, month or year of not knowing. An SBOM alone, however, will not tell you whether what you are running has gone bad. For that you need the other half: continuous dependency scanning.

Old-school dependency scanning compares your installed packages against a database of known vulnerabilities, published CVEs, bugs and the like. That approach simply cannot see attacks like the GitHub breach. A freshly poisoned package version has no CVE, and by the time one exists the damage has likely already been done.

Continuous dependency validation closes that gap by changing the question. Instead of asking whether a package is known-bad, it asks whether it looks like the kind of thing that turns out to be bad, and it asks the moment a dependency is added or updated. This heuristic assessment is standard in every next-gen AV or EDR, yet largely absent from the package-management world. Socket Security is a decent example to point at, because that shift is the whole basis of how it works: rather than waiting for a vulnerability to be catalogued, it flags the traits supply chain malware tends to share – unexpected install scripts, heavily obfuscated code, network calls with no obvious purpose, maintainer accounts created last week. These hallmarks show up well before any researcher has had time to dig through the code and confirm malicious intent.

Because these attackers rely on speed, the timing of checks is critical: they belong in ongoing activity, not a once-a-year review. The recent variant of Shai-Hulud, nicknamed Mini Shai-Hulud, showed what that timing buys you. Researchers caught the malicious publish wave and tagged the affected versions as known malware; GitHub ultimately removed 640 malicious packages and invalidated more than 61,000 npm tokens. This is not an endorsement of any one product (though Socket does appear to do a good job) – the point is that this kind of malware can be caught the day it ships, as long as someone or something, preferably both, is watching the dependency web continuously, not just when management, regulation or year-end testing gets round to it.

What to actually do about it

This is a problem with solutions:

• Create an SBOM, and understand what is installed across the organisation and where. This alone will massively lower the response time of any future breach.
• Control what gets installed, by implementing approval steps for browser extensions, editor extensions, office add-ins, connected SaaS apps and the like.
• Run internal penetration testing and Red Teaming to ensure horizontal and vertical privilege escalation is prevented as far as possible.
• Review the configuration of developer machines. Developers typically run at higher privilege than other employees, and their credentials carry more weight, which makes them prime targets.
• Implement a proper heuristic scanner for third-party software, not just a bug-scanner.
• Prepare a response runbook before you need it. Having the decisions already made, identifying affected systems, isolating hosts, removing bad components, rotating credentials, lowers stress during an incident and speeds the response, limiting the fallout.

Where this leaves us

Almost a decade separates the CCleaner investigation and this GitHub breach, and the uncomfortable truth is how little the attackers have had to learn in between. The tooling has changed and the targets have shifted, but the playbook is the one from 2017: find something trusted, ride its reputation and its update channels, and let the victim's own automation carry the malicious code inside. That is what makes these attacks so effective, they abuse the trust implied by third-party reputation, and you never defended those surfaces because you assumed someone else had.

The tidy wall most organisations still picture around their estate no longer describes reality. Between cloud, remote working, third-party integrations and software dependencies, that wall has eroded, and internal and external estates have blended. You can still map the new perimeter, watch it continuously, and test internal and external systems robustly. You can give this paradigm the same seriousness the old world gave external systems, or wait for the next attack to find the weaknesses for you. One of those is considerably cheaper than the other.

For help making sense of all of this, figuring out strategies to improve robustness, implementing disaster recovery plans, running exercises to test those plans, and responding to incidents if the worst should happen, speak to Thomas Murray's Cyber Risk team on +44 (0)20 8057 7100, 24/7, 365.