GitHub Got Hacked via Its Own VS Code Marketplace

GitHub's official statement reads like something you'd see stitched onto a throw pillow in a crisis communications office: "We are investigating unauthorized access to GitHub's internal repositories. While we currently have no evidence of impact to customer information... we are closely monitoring our infrastructure for follow-on activity."

That's the cleaned-up version. The actual situation is messier, weirder, and—if you stare at the attack chain long enough—genuinely unsettling in ways that go beyond any single breach.

Here's what happened, as best as we can reconstruct it.

The Breach, Layer by Layer

On May 18th, a malicious version of the NX Console VS Code extension was published to the Visual Studio marketplace at 12:30 UTC. NX Console is a legitimate, widely-used tool with 2.2 million installs and a verified publisher badge. The compromised version stayed live for 18 minutes before being pulled. On OpenVSX—the alternative marketplace—it was available for 36 minutes.

Eighteen minutes doesn't sound like much. But VS Code doesn't wait for you to manually check for updates. According to Aikido Security's writeup on the incident, VS Code syncs installed extensions against the marketplace gallery whenever you interact with it—opening the extension sidebar, running a marketplace search, even background subsystem activity. The update can fire within minutes of a new version being published, not on the 12-hour timer most people assume. If your editor was open and your extension sidebar was visible during that window, you may have pulled the malicious build without knowing it.

Anyone who had NX Console installed with auto-update enabled during that window is advised to assume compromise and rotate everything: tokens, secrets, SSH keys, any credentials that touched disk.

The NX maintainer (Narwhal, the company behind NX) didn't receive the marketplace's upload notification email until six minutes after the malicious version went live. Microsoft registered the takedown ten minutes after that. By then, the gallery sync had already done its work.

Now for the part that connects this to GitHub's internal repos: the root cause of the NX Console compromise was a contributor's GitHub token that had been stolen in an earlier supply chain attack—specifically, fallout from the broader "Shyllet" attack wave that's been quietly compromising packages for weeks. Someone had that token sitting in a pile of stolen credentials, tested it, confirmed it still worked, and used it to publish a malicious extension release.

That malicious extension then ran on a GitHub employee's device. GitHub confirmed this in a follow-up post: "Yesterday, we detected and contained a compromise of an employee device involving a poisoned VS Code extension." The attacker's claimed haul of 3,800 internal repos is, per GitHub, "directionally consistent" with what their investigation has found so far.

So the chain looks like this: earlier supply chain attack → stolen token → malicious extension published → GitHub employee's editor auto-updated → internal repos exfiltrated. Each link is its own documented failure mode. Together they produced something that looks almost elegant, if you can say that about a hack.

The Microsoft-Owns-Everything Problem

One reply to GitHub's disclosure, from a developer named Darren, got a lot of traction for good reason:

"Just to be clear, Microsoft's GitHub was compromised when a Microsoft developer using Microsoft's VS Code installed the rogue extension from Microsoft's VS Code extension library, which is moderated and hosted by Microsoft."

That's not snark for its own sake—it points to something structurally strange. The VS Code extension marketplace has been a known vector for malware for years. Theo (t3.gg), who covered this incident in a recent video, surfaced a reply from 2024 directed at GitHub's then-CEO: "Can you fix the issue with people deploying malware in VS Code extension marketplace? I'm getting tired of sending mails every week to the hidden email that they had for it." That was over a year ago.

The volume of malicious extensions in the VS Code marketplace isn't a secret. Security researchers have been flagging it. Companies like Socket—which found the original Shyllet attack and has since uncovered hundreds of compromised packages in ecosystems like AntV—have been doing the detection work that Microsoft hasn't. Socket just raised a $60M Series C at a $1B valuation, which tells you something about market demand for what they do. The fact that external firms are faster at catching these exploits than the platform that hosts the code is a real tension worth sitting with.

Theo frames this as a cultural problem: "The severity of Microsoft's lack of security culture around these things is absurd and it's going to keep burning them aggressively." That's a strong read, and it may be right. But there's a harder question underneath it: even a company with excellent security culture would struggle to manually review every update to every extension across a marketplace this size. The system itself creates conditions where 18 minutes is enough.

The Pile of Stolen Tokens Nobody Has Finished Going Through

This is the part that doesn't resolve cleanly.

The token used to publish the malicious NX Console extension was stolen weeks or months ago, in the earlier wave of Shyllet-related compromises. Whoever holds that data is still working through it. As Theo puts it: "They have too much data to go through... every few days, they're going to find something they didn't realize they had. They're going to test it and confirm that it's a token that still works. And then they're going to go do a whole new set of exploits."

Even if every currently-known vulnerability gets patched today, there's a cache of valid credentials in someone's hands that hasn't been fully exploited yet. That's not speculation—it's the demonstrated pattern of the last several weeks, with new downstream attacks emerging from the same original breach.

And here's where the AI angle gets uncomfortable: Theo notes that sorting through a giant pile of stolen tokens to find exploitable ones, then automating the publication of malicious extension versions, is exactly the kind of task an LLM agent handles well. What once would have taken months of careful human work now takes a loop and a prompt. The same capabilities that make agentic coding tools useful make the attack surface wider.

npm's Response Misses the Point

Separately from the VS Code incident, the npmjs account resurfaced to announce a response to the ongoing supply chain attacks: invalidating all npm granular access tokens with write access that bypass two-factor authentication, and recommending "trusted publishing" as the path forward.

Trusted publishing (attaching a specific GitHub repo and Action to your npm deployment pipeline, so publishing can only happen through that Action) sounds like a reasonable fix. The problem, as Theo explains, is that most of the compromised packages were already using trusted publishing. The attack vector was cache poisoning in GitHub Actions—specifically, the difference between using pull_request_target and pull_request as your Action trigger. The former allows cache access from forked PRs; the latter doesn't. Tanstack got hit this way: someone filed a malicious PR, deleted it immediately, poisoned the cache, and the next release restored it with the exploit included.

Recommending trusted publishing as the solution to attacks that ran through trusted publishing is, at minimum, an incomplete answer.

Auto-Update Was Always a Trade-Off

Here's an honest tension that nobody really wants to sit in: auto-updating is how we avoid a long tail of users running outdated, vulnerable software. That's a real problem. Developers don't update manually. Regular users update even less. The whole reason auto-update exists is because the alternative—waiting for people to notice and act—demonstrably doesn't work.

But auto-update also means a publisher with a compromised account has a direct push channel into every machine running their extension, with no review gate and no waiting period between publication and installation. Both of these things are true simultaneously. The trade-off made sense when the risk was stale software; it looks different now that stolen tokens can turn trusted publishers into attack vectors on an 18-minute timeline.

What the right answer is here—mandatory review delays, staged rollouts, publisher verification overhaul, something else—isn't obvious. What's clear is that the current system was designed for a threat model that no longer describes reality.

The GitHub breach was contained. Critical secrets were rotated. The malicious extension was pulled. But the token dump that enabled it is still out there, still being processed, still producing new attacks on a schedule nobody outside the attackers knows.

By Yuki Okonkwo, AI & Machine Learning Correspondent, Buzzrag