GitHub internal repositories breached after poisoned VS Code extension hit employee device

GitHub confirmed that attackers accessed and exfiltrated internal repositories after a poisoned Visual Studio Code extension compromised an employee device. The incident was detected and contained on May 18, 2026, and GitHub said its current assessment points to GitHub-internal repositories, not customer repositories, as the affected area.

The attack has been linked to a malicious version of the Nx Console extension, a popular tool used by developers working with Nx monorepos. The compromised build reached the Visual Studio Marketplace for a short period, but that window gave attackers enough time to turn a trusted developer tool into an entry point for a broader supply chain breach.

The attacker claimed to have taken about 3,800 internal repositories. In the GitHub breach report, the company described that figure as directionally consistent with its investigation, while stressing that it found no evidence of impact to customer enterprises, organizations, or repositories stored outside GitHub’s internal repositories.

What GitHub says was affected

GitHub said the incident involved internal repositories and not the public-facing hosting platform used by customers. That distinction matters because a breach of internal source code does not automatically mean private customer repositories were accessed.

Still, GitHub acknowledged a secondary risk. Some internal repositories can contain customer-derived information, such as excerpts from support interactions. The company said it will notify affected customers through established channels if it confirms any impact to customer data.

GitHub also started rotating critical secrets after the incident was discovered. The response focused first on credentials with the highest possible blast radius, while teams continued checking logs, validating rotated secrets, and watching for persistence or follow-on activity.

Key detail	Current information
Incident type	Internal repository exfiltration through a compromised employee device
Initial vector	Poisoned Nx Console VS Code extension
Detection date	May 18, 2026
Repository count	Attacker claim of about 3,800 repositories, described as directionally consistent
Customer repository impact	No evidence reported so far
Immediate response	Endpoint isolation, malicious extension removal, secret rotation, and log analysis

How the Nx Console extension was weaponized

Nx Console is a legitimate VS Code extension used to work with Nx projects from inside the editor. It helps developers run Nx tasks, use generators, inspect project graphs, and manage monorepo workflows without leaving the development environment.

The malicious version was Nx Console 18.95.0. The Nx Console advisory says the version was published at 12:30 UTC on May 18 and removed from the Visual Studio Marketplace at 12:48 UTC, leaving it available there for about 18 minutes.

That short window still mattered because many editors install extension updates automatically. A developer did not need to search for malware or install an unknown tool. A trusted extension update could run in a normal coding environment.

The payload targeted developer secrets

The malicious extension did not need to behave visibly suspiciously to cause damage. Researchers said it could act as a trigger that fetched and executed a hidden package from a planted commit, while appearing to perform normal extension activity.

The StepSecurity analysis says the compromised extension fetched a 498 KB obfuscated payload from a hidden commit in the official nrwl/nx GitHub repository. The payload targeted developer credentials, cloud infrastructure tokens, and CI/CD secrets.

Those targets included GitHub tokens, npm tokens, AWS credentials, HashiCorp Vault tokens, Kubernetes credentials, 1Password data, private keys, connection strings, and other files or environment data reachable from the machine.

Why a VS Code extension can create serious risk

VS Code extensions often run close to the developer’s daily workflow. They can read workspace files, launch commands, interact with terminals, and connect with build tools. That access makes them useful, but it also makes them dangerous when attackers compromise a publisher or release pipeline.

The OX Security analysis said the compromised extension kept the normal Nx Console surface while adding a hidden credential-theft chain. It also said the extension disguised its command as routine Model Context Protocol setup activity, which reduced the chance of immediate suspicion.

2/ 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.

— GitHub (@github) May 20, 2026

This type of attack targets the developer workstation instead of only the production server. Once attackers steal tokens from a trusted device, they may gain access to repositories, registries, cloud accounts, CI systems, and internal tooling.

TeamPCP claim adds pressure to the investigation

A threat actor known as TeamPCP claimed responsibility for the breach and said it had obtained around 3,800 GitHub internal repositories. The group reportedly tried to sell the stolen data, adding an extortion and data-leak risk to the incident.

The GitHub internal repository breach is especially sensitive because developer platforms sit at the center of modern software delivery. Internal repositories can include build scripts, deployment tooling, automation logic, security workflows, and operational documentation.

GitHub said it will publish a fuller post-incident report after the investigation concludes. Until then, the company’s key message remains that the known activity involved internal repositories and that no customer repository impact has been found so far.

Nx has hardened its publishing process

The Nx team also changed its own release process after the compromise. The official Nx advisory says a single organization member previously could release a new Nx Console version without manual approval.

Nx says it has now hardened the publishing pipeline so two admins must manually approve a release. That change reduces the chance that one compromised account can push a malicious extension update through the same path.

The advisory also lists Nx Console 18.100.0 as the patched version and urges affected users to rotate every credential reachable from the machine. That includes tokens, secrets, SSH keys, and credentials tied to cloud services or developer tools.

What developers and companies should check

Any developer who installed Nx Console 18.95.0 during the exposure window should treat the workstation as compromised. Teams should not stop at uninstalling the extension because the payload may have reached credentials, local files, or connected services before removal.

• Check whether Nx Console 18.95.0 was installed on any developer machine.
• Update Nx Console to version 18.100.0 or later.
• Remove persistence artifacts and suspicious processes linked to the incident.
• Rotate GitHub, npm, AWS, Vault, Kubernetes, SSH, 1Password, and CI/CD credentials reachable from affected machines.
• Review repository, package registry, and cloud audit logs for unusual access.
• Restrict extension auto-updates for high-risk developer environments.
• Create an approved extension list for developers with access to sensitive systems.

StepSecurity also notes that OpenVSX was not affected in the same way as the Visual Studio Marketplace version. However, organizations should still review all editor extension sources because attackers increasingly look for trusted software distribution channels.

The bigger supply chain lesson

This breach shows how quickly trust can become a weakness in developer tooling. Modern software teams rely on extensions, package registries, cloud CLIs, AI coding tools, build scripts, and automated updates. Attackers only need to compromise one trusted link to reach much deeper systems.

The OX Security report says the VSIX itself mainly acted as a trigger and did not need to contain the full stealer. That design made the attack harder to judge by inspecting only the extension package.

For enterprises, the practical lesson is clear. Developer machines need the same level of monitoring, policy control, and credential hygiene as production systems. That includes extension governance, short-lived tokens, least-privilege access, and fast secret rotation when a trusted tool gets compromised.

The GitHub incident will likely push more companies to review their developer workstation policies. The next supply chain breach may not start with a public package or a server exploit. It may start with a tool that developers already trust.

FAQ