GitHub Internal Repos Breached via Malicious VS Code Extension

TL;DR

On May 18, 2026, a trojanized version of the popular Nx Console VS Code extension was published to the Visual Studio Marketplace. It was live for only 11 to 18 minutes, but that was enough time for a credential-stealing payload to infect developer machines — including one belonging to a GitHub employee. By May 20, 2026, GitHub had publicly confirmed that the attacker, a financially motivated group calling itself TeamPCP (tracked as UNC6780), had used that single foothold to clone roughly 3,800 of GitHub's internal repositories. The stolen archive is now being shopped on cybercrime forums with an asking price north of $50,000. GitHub says customer data, public repositories, and enterprise tenants are not affected. The deeper lesson is structural: the modern IDE has become the highest-value attack surface on a developer's machine, and one unvetted extension can collapse the perimeter around an entire engineering organization.

Ready to see how it works:

• What Actually Happened: The 11-Minute Window That Cost 3,800 Repos
• Anatomy of the Attack: From Token Theft to Repo Exfiltration
• Who Is TeamPCP — and Where Mini Shai-Hulud Came From
• Why VS Code Extensions Are the New Supply-Chain Soft Underbelly
• The Real Blast Radius of 3,800 Internal Repos
• A Practical Hardening Playbook for Engineering Leaders
• How Ruh AI Is Adapting Secure Developer Workflows After the Breach
• Frequently Asked Questions

What Actually Happened: The 11-Minute Window That Cost 3,800 Repos

Most breach stories unfold over weeks. This one unfolded over 48 hours and started with eleven minutes of poisoned code sitting in the Visual Studio Marketplace.

The Nx Console Compromise on May 18, 2026

Nx Console is the official VS Code extension for the Nx monorepo build system, published by nrwl and used by more than 2.2 million developers worldwide. On May 18, 2026, an attacker who had already compromised the credentials of an Nx maintainer pushed a malicious build — version nrwl.angular-console v18.95.0 — to the Visual Studio Marketplace. Multiple incident reports place the window of malicious availability between roughly 11 minutes (per StepSecurity's reconstruction) and 18 minutes (per The Hacker News' reporting, which timed the window from 12:30 p.m. UTC to 12:48 p.m. UTC). Either way, it was barely long enough to brew a cup of coffee, and long enough to seed a global supply-chain incident.

What made the window so dangerous is how VS Code extensions update. The default behaviour is silent auto-update. Any developer who already had Nx Console installed and whose editor checked for updates inside that window pulled the trojanized build automatically, no click required. Initial telemetry from Microsoft suggested only 28 installs, but the Nx team's own analytics indicated the real number of compromised endpoints was likely over 6,000. One of those endpoints belonged to a GitHub employee.

The GitHub Disclosure on May 20, 2026

Two days later, in the early hours of Pacific Time on May 20, 2026, GitHub published a security notice confirming that a criminal group had exfiltrated roughly 3,800 of the company's internal repositories. The disclosure, first reported by BleepingComputer and shortly thereafter confirmed by TechCrunch, traced the intrusion back to the same poisoned Nx Console build. A GitHub spokesperson told Decrypt the company had "no evidence of impact to customer information stored outside of GitHub's internal repositories," and that public repos, enterprise accounts, and user data were not in scope of the compromise.

GitHub also acknowledged that the attacker's public claim of accessing approximately 3,800 repositories was "directionally consistent" with the company's own forensic findings — a notable concession, because in past incidents GitHub has been careful to push back on attacker numbers. The company said it had rotated critical credentials overnight, prioritizing the highest-risk secrets first, isolated the affected employee device, and activated full incident response. The dataset was listed for sale on an underground cybercrime forum with a floor price of $50,000, per reporting from The Record.

Anatomy of the Attack: From Token Theft to Repo Exfiltration

The mechanics of the breach are technically straightforward, which is precisely what makes the lessons portable.

The Trojanized Payload and the Bun Runtime

When a developer opened any workspace in VS Code with the poisoned Nx Console v18.95.0 installed, the extension silently ran a single shell command on startup. That command did two things: it downloaded the Bun JavaScript runtime, and it used Bun to execute an obfuscated index.js payload that had been planted in a hidden commit on the official nrwl/nx GitHub repository. Using Bun rather than Node.js was a deliberate evasion choice — Bun is far less commonly monitored by endpoint detection and response (EDR) rules tuned for Node-based malware.

Per The Hacker News' technical writeup, the payload included a deliberate safety check that skipped infection on machines configured for Russian or CIS time zones — a hallmark of certain financially motivated cybercriminal groups. Once past that check, the malware forked itself into a detached background process and began credential harvesting.

What the Credential Stealer Targeted

The credential stealer was unusually comprehensive for an in-the-wild VS Code payload. Multiple analyses, including those from StepSecurity and Help Net Security, confirm it was capable of pulling secrets from:

• 1Password vaults that were unlocked on the developer's machine
• Anthropic Claude Code configuration files (a sign of how aggressively attackers are now targeting AI-developer tool configs)
• npm authentication tokens
• GitHub personal access tokens, OAuth tokens, and SSH keys
• Amazon Web Services (AWS) access keys

The harvested data was then exfiltrated to attacker-controlled infrastructure. On the GitHub employee's machine, GitHub tokens were the prize. Those tokens are what let TeamPCP authenticate as a legitimate engineer and clone 3,800 internal repositories through the very APIs that GitHub itself publishes.

Why "Clone, Don't Push" Is the Crucial Detail

It is worth stressing what the attacker did not do. There is no public evidence that TeamPCP modified GitHub's internal source code, pushed back to production branches, or tampered with the GitHub service itself. The breach was read-only exfiltration, not code injection. That distinction matters because it bounds the customer impact (the GitHub service is unchanged) while still surfacing every secret, comment, internal design doc, vulnerability report, and unreleased feature plan that happened to live in those 3,800 repos.

Who Is TeamPCP — and Where Mini Shai-Hulud Came From

The GitHub breach is the headline-grabbing event, but it is not a standalone incident. It is the latest stop on a months-long campaign called Mini Shai-Hulud.

The Mini Shai-Hulud Campaign Lineage

Mini Shai-Hulud is named after the original Shai-Hulud worm, the first self-replicating malware ever observed in the npm ecosystem when it appeared in September 2025. TeamPCP, a financially motivated cybercriminal group also tracked by Mandiant and Google's threat-intel teams as UNC6780, emerged in late 2025 and adopted the Shai-Hulud worm playbook as the foundation for a coordinated, cross-ecosystem operation.

Per Tenable's CVE-2026-45321 FAQ and Security Boulevard's campaign tracker, TeamPCP's confirmed earlier victims include:

• Aqua Security's Trivy scanner (March 2026)
• The Bitwarden CLI npm package (April 2026)
• The SAP Cloud Application Programming Model npm packages, PyTorch Lightning on PyPI, the intercom-client npm package, and several Ruby gems (late April to early May 2026)
• A renamed fork of TanStack/router with a malicious commit under a fabricated identity, and ultimately 84 malicious versions across 42 TanStack npm packages, affecting over 170 packages in total (May 10–11, 2026)
• Mistral AI and OpenAI developer credentials (mid-May 2026)
• The Nx Console maintainer (May 18, 2026)
• GitHub itself (May 19–20, 2026)

The Worm Source Code Released Into the Wild

A pivotal moment came on May 12, 2026, when the source code of the Mini Shai-Hulud worm was leaked publicly. That leak immediately spawned copycat campaigns. Then on May 19, 2026 — the day before the GitHub disclosure — the npm maintainer account atool was compromised as part of a new wave that published 639 malicious package versions across 323 unique packages in approximately one hour, per VentureBeat's reporting. That single hour set the all-time record for the largest package-count burst of any Shai-Hulud-family wave to date.

This is not a story of a clever one-off heist. It is a story of an industrialized supply-chain attack engine that finally turned and pointed at one of the most strategically valuable targets on the planet.

Why VS Code Extensions Are the New Supply-Chain Soft Underbelly

The mechanics of this breach should worry every CTO and security leader, because the trust model around IDE extensions has not kept up with the value of the data those extensions can reach.

A modern VS Code extension runs as arbitrary third-party JavaScript inside the IDE process, with the developer's full local privilege. The Visual Studio Marketplace does perform automated malware and secret scanning on every package and signs every extension at publish time — and VS Code verifies that signature at install time, per the official runtime-security documentation. Those controls catch obvious malware. They do not catch a legitimate, signed, popular extension whose maintainer account has been compromised and which is updated for eleven minutes with a hostile payload.

The blue "verified" checkmark next to a publisher name is also weaker than it appears. Multiple independent researchers have shown that publishers can add new functionality to extensions while keeping the verified icon intact, meaning the badge proves only that domain ownership was verified at some point — not that the current build of the extension is trustworthy.

Three structural factors compound the risk:

1. Auto-update by default. Any developer with the extension already installed pulled the malicious build automatically.
2. No meaningful runtime sandbox. Extensions can shell out, write to disk, read environment variables, and reach the network.
3. Concentrated credentials. A 2026 developer machine routinely holds 1Password sessions, AWS keys, GitHub PATs, npm tokens, OpenAI keys, Hugging Face tokens, and Claude Code configs — every secret an attacker would want, sitting in one trust zone.

Combine those three and you get this incident. The chilling part is how repeatable it is.

The Real Blast Radius of 3,800 Internal Repos

GitHub has been clear and credible in stating that no customer data, public repository, or enterprise tenant was accessed. That is an important boundary and should not be downplayed. But "internal repositories only" still covers a great deal of valuable territory at a company that runs the world's largest source-code platform.

Internal monorepos at a company like GitHub typically contain:

• Service source code for back-office systems, internal tooling, and deployment automation
• Infrastructure-as-code templates, Helm charts, and Terraform modules describing production architecture
• Vulnerability reports and patches still in pre-disclosure embargo
• **Internal API specifications and gRPC contracts **that are not part of the public docs
• Comments, design docs, and runbooks that describe how engineers actually operate the service
• Embedded secrets — keys, tokens, and credentials that should not be in source control but historically often are

InfoWorld's analysis pointed out that even read-only access to internal source code at this scale gives an attacker something more valuable than any single credential: a map of the target organization's attack surface. Future intrusion attempts against GitHub — by TeamPCP, by buyers of the stolen archive, or by anyone who reads the eventual leak — will be informed by that map.

That is why GitHub's overnight credential rotation matters so much. The company moved quickly to assume that every secret that could have lived in those** 3,800 repos was compromised,** and to revoke and re-mint accordingly. It is also why the most important guidance for every other engineering organization is to assume the same of any developer endpoint touched by a poisoned extension during the May 18 window.

A Practical Hardening Playbook for Engineering Leaders

The good news is that the controls that would have blunted this attack are well understood. The bad news is that most engineering organizations still have not implemented them rigorously. Here is the playbook the incident hands you on a silver platter.

Extension Hygiene

• Inventory every IDE extension installed across your engineering fleet — VS Code, Cursor, JetBrains, Neovim plugins, anything that runs third-party code in the editor process. You cannot govern what you have not catalogued.
• Move to an allowlist model, not a blocklist. Only pre-approved, security-reviewed extensions can install. VS Code's enterprise extension controls, shipped in November 2024, give you the technical primitives — use them.
• Pin extension versions. Auto-update is convenient and exactly the property that lets an 11-minute compromise window propagate globally. Pinning means you choose when to take a new version, after reviewing the diff.
• Treat the "verified" badge as a hint, not a guarantee. Independent reviews still matter.

Credential Hardening

• Get long-lived secrets off developer machines. Use short-lived, scoped credentials issued through OIDC or AWS STS / GCP Workload Identity Federation, not static keys in dotfiles.
• Use hardware-backed authentication for GitHub, npm, and cloud accounts. Phishing-resistant FIDO2 or passkey MFA materially raises the cost of attacker reuse of stolen tokens.
• Vault all credentials, and lock the vault when not actively in use. The Nx Console payload could only pull 1Password secrets that were already unlocked at the moment of harvest.
• Rotate on a risk-weighted basis after any suspected exposure, exactly the way GitHub did. Highest-blast-radius secrets first.

Detection and Response

• Deploy EDR to developer endpoints with rules that flag unusual processes spawned by IDEs — including, specifically, Bun, Deno, or any runtime suddenly executed from a VS Code extension's directory.
• Egress filter developer networks. The malware exfiltrates over the network. If unexpected outbound destinations are blocked or alerted on, you catch it.
• Use containerized or remote development environments (Codespaces, Dev Containers, JetBrains Gateway) so that even if a developer's host is compromised, blast radius is contained.
• Pre-write a 72-hour incident-response runbook for "suspected developer endpoint compromise," covering token revocation, repo audit, branch protection review, and customer notification thresholds. The time to write it is before you need it.

Sophos' incident analysis and Varonis' breakdown both reach a similar conclusion: the controls are not exotic, but they require treating the developer endpoint with the same seriousness as a production server.

How Ruh AI Is Adapting Secure Developer Workflows After the Breach

At Ruh AI, we build agentic AI systems that work alongside developers — and that means our security thinking has to start at the developer's endpoint, not just at the model. The Nx Console / GitHub incident validated several decisions we had already been moving toward and accelerated a few we had not.

We have always taken the view that an AI agent embedded in a developer workflow inherits every secret that workflow can reach. That principle now shapes how we build, how we deploy, and how we recommend our customers run our agents.

Concretely, our response to the breach is shaping three workstreams:

• Zero-standing-credential agent runtimes. Ruh AI's agentic workflows execute in ephemeral, sandboxed environments with just-in-time, scoped credentials issued for the duration of a single task. There are no long-lived tokens cached on the developer machine for an attacker to harvest.
• Extension-aware posture checks. When a developer connects a Ruh AI agent to their IDE, we surface a posture summary that flags unsigned extensions, extensions with elevated permissions, and extensions whose maintainer accounts have been linked to recent supply-chain incidents — drawing on the same threat-intel feeds that powered the Mini Shai-Hulud disclosures.
• AI-config secret isolation. We treat Anthropic Claude Code configurations, OpenAI keys, and Hugging Face tokens as first-class secrets that belong in a vault, not in dotfiles. Our recommended workflow stores model-provider credentials in a hardware-backed keychain and brokers requests through a local proxy that never writes the secret to disk in a form a credential stealer can scrape.

The lesson the Mini Shai-Hulud campaign keeps repeating is that AI-developer tools concentrate value, and concentrated value attracts patient, well-funded attackers. Our job is to make that concentration safer to live with, not to pretend it does not exist.

Final Word: Trust Your IDE the Way You Trust Your Browser

For two decades, security teams have hardened browsers, audited browser extensions, and built sophisticated content-security frameworks around them — because browsers became the primary interface between users and the internet. The IDE is now the primary interface between developers and every system they can reach, and it has none of the same hardening culture. The GitHub breach is not an aberration. It is the inevitable consequence of treating developer workstations as trusted just because the people sitting at them are.

The fix is not exotic. It is the discipline of inventory, allowlisting, short-lived credentials, EDR, egress filtering, and a written runbook. Ruh AI is building the agentic workflows that assume this discipline as a baseline — not as a constraint, but as the foundation for shipping software safely in a world where one extension can cost you 3,800 repositories.

If you want to see how Ruh AI's agentic workflows isolate secrets and harden developer endpoints by default, book a 20-minute walkthrough with our team — and bring your hardest developer-security question.

Frequently Asked Questions

What exactly was breached in the GitHub incident?

Ans: Approximately 3,800 of GitHub's internal repositories were cloned by an external attacker. GitHub has stated that the compromise was confined to its own corporate estate and that customer repositories, enterprise accounts, and user data were not affected.

How did the attacker get in?

Ans: A GitHub employee installed the Nx Console VS Code extension (or had it auto-update) during an 11- to 18-minute window on May 18, 2026 when a trojanized build, nrwl.angular-console v18.95.0, was live on the Visual Studio Marketplace. The malicious extension ran a credential stealer that exfiltrated the employee's GitHub authentication tokens, which the attacker then used to clone internal repositories.

Who is TeamPCP?

Ans: TeamPCP, also tracked as UNC6780, is a financially motivated cybercriminal group that emerged in late 2025. They specialize in supply-chain attacks against open-source developer tools and AI middleware, and are responsible for the broader Mini Shai-Hulud campaign that has previously hit Aqua's Trivy, the Bitwarden CLI, TanStack, Mistral AI, OpenAI developer credentials, and many others.

Is my company at risk if we use Nx Console?

Ans: If your developers installed or auto-updated to Nx Console v18.95.0 between approximately 12:30 p.m. and 12:48 p.m. UTC on May 18, 2026, assume the endpoint was compromised. Rotate every credential that may have been reachable from that machine — including 1Password, AWS, GitHub, npm, Anthropic Claude Code configs, and any other developer tokens — and review repository access logs for the affected accounts.

Was the Nx Console maintainer at fault?

Ans: The malicious build was published using legitimately stolen maintainer credentials, traced in turn back to an earlier TanStack-related supply-chain compromise. The Nx team responded quickly to remove the malicious version once notified. The deeper issue is structural: the Visual Studio Marketplace's trust model assumes maintainer accounts are uncompromised, and that assumption no longer holds in a world where TeamPCP-style operations exist.

Will GitHub's source code leak publicly?

Ans: The dataset is currently being offered for sale on cybercrime forums for upwards of $50,000. Whether it leaks publicly depends on whether any buyer is willing to release it. Historically, datasets of this kind have often appeared on free-access forums within 6 to 18 months of initial sale.

Did GitHub handle the response well?

Ans: By the standards of large-platform incident response, the answer is yes: GitHub disclosed within roughly 48 hours of the initial compromise, rotated critical credentials overnight, isolated the affected device, and was transparent about scope and limitations. There is no evidence the company tried to minimize impact, and its statement that customer data was unaffected has been corroborated by independent researchers.

What is the single most important takeaway?

Ans: Treat your IDE the same way you treat your browser: assume every third-party extension is a potential adversary, run with the smallest possible set of installed extensions, pin versions, and keep your secrets out of any process that does not absolutely need them.