A Trusted VS Code Extension Helped Breach GitHub. That Should Worry Every Developer.

Photo by Markus Winkler on Unsplash

I install editor extensions without thinking too much about them. Most developers do. We check whether the publisher looks legitimate, whether the tool is widely used, and whether it solves the problem in front of us. Then we click install and get back to work.

That habit suddenly looks much less harmless.

In May 2026, GitHub confirmed that an employee device was compromised through a malicious version of Nx Console, a popular Visual Studio Code extension. The attacker went on to exfiltrate roughly 3,800 of GitHub’s internal repositories.

Around the same time, researchers uncovered another campaign, called Megalodon, which pushed malicious commits into more than 5,500 GitHub repositories in a matter of hours. Those commits targeted CI/CD workflows, the machinery developers trust to test, package, and deploy software.

The two incidents are not proven to be the same operation. But they point to the same uncomfortable reality: the tools developers trust every day have become one of the easiest ways to reach valuable code and credentials.

For years, we have been told to avoid suspicious downloads and shady links. That advice still matters. But it does not fully prepare us for a compromised update to a tool we already trust.

What Happened in the GitHub Internal Repository Breach?

The GitHub breach began upstream, before GitHub itself was directly affected.

According to the Nx postmortem, an Nx contributor’s machine installed a malicious version of a compromised *@tanstack/** npm package on May 11, 2026. That malware stole the contributor’s GitHub authentication token.

Seven days later, on May 18, attackers used the stolen access to publish a malicious version of the official Nx Console VS Code extension, version 18.95.0, through legitimate extension marketplaces.

Nx Console was not an obscure tool from an unknown developer. It was a trusted extension with millions of installs, used by developers to work with Nx projects inside VS Code and compatible editors.

The malicious extension behaved normally, but it also executed a credential-stealing payload when activated. That payload attempted to collect:

• GitHub tokens
• npm credentials
• AWS and cloud credentials
• SSH keys
• .env files
• Vault tokens
• Docker and Kubernetes configuration
• Other secrets available on the developer machine

One affected device belonged to a GitHub employee. GitHub said the incident resulted in the exfiltration of roughly 3,800 GitHub-internal repositories. GitHub stated that it found no evidence of access to customer repositories outside information that may have existed inside its internal systems.

This is important: GitHub was not necessarily breached through a vulnerability in GitHub.com. It was breached because a trusted development tool became malicious and reached a developer workstation with valuable access.

What Was the Megalodon Attack?

At almost the same time, researchers identified another large-scale GitHub supply-chain campaign called Megalodon.

According to SafeDep research reported by The Register, attackers pushed 5,718 malicious commits into 5,561 repositories during a six-hour period on May 18, 2026.

The attack was designed to look ordinary. Malicious commits appeared to come from identities such as build-bot, with messages like:

ci: add build optimization step

That is exactly the kind of change many developers might skim past, especially in a busy repository.

The malicious code targeted GitHub Actions and CI/CD workflows. If executed, it could attempt to steal:

• GitHub repository tokens
• AWS access keys
• Google Cloud tokens
• Azure or cloud instance credentials
• SSH private keys
• Docker and Kubernetes credentials
• Vault and Terraform secrets
• Environment variables used during builds and deployments

In other words, the attackers were not simply trying to vandalize code. They were trying to compromise the machinery that builds, publishes, and deploys software.

One repository compromise can become much larger when a poisoned project is later published as an npm package, container image, release artifact, or deployment.

Why Did These Attacks Work?

The simplest explanation is not that developers are careless. The problem is that modern development depends on layers of trust that are difficult for any individual to fully verify.

1. Trusted tools can become malicious overnight

Developers are trained to avoid suspicious packages and unknown extensions. But what happens when the malicious update comes from a popular, verified, legitimate extension?

Nx Console had the trust signals developers usually rely on: an official publisher, large adoption, and presence in an approved marketplace. That is exactly why compromising it was so powerful.

The attacker did not need to persuade people to install an obviously suspicious tool. They only needed an existing trusted tool to auto-update.

2. Developer machines hold valuable credentials

A developer laptop is no longer just a machine for writing code. It may contain tokens for GitHub, npm, cloud infrastructure, package registries, deployment tools, databases, SSH servers, or secrets managers.

Compromise the workstation, and the attacker may inherit the developer’s reach.

In the GitHub incident, compromising a single device reportedly opened access to thousands of internal repositories.

3. CI/CD workflows are executable code

Many developers carefully review changes to application code but pay less attention to files inside .github/workflows/.

That is dangerous. A GitHub Actions workflow can access secrets, publish packages, deploy infrastructure, or execute shell commands. A malicious workflow change is not merely a configuration edit; it can be a production compromise.

Megalodon exploited this blind spot by making workflow-related commits appear routine.

4. Automation gives attackers speed

Both incidents show how quickly a modern software supply-chain attack can move.

A malicious extension may only need to remain online for minutes if automatic updates deliver it to high-value targets. A compromised token can be used to inject changes into thousands of repositories faster than human reviewers can reasonably inspect them.

Security that depends entirely on someone noticing quickly is no longer enough.

What Can Individual Developers Do?

Organizations must improve marketplace security, publishing controls, token management, and incident response. But individual developers are not powerless. A few habits can meaningfully reduce personal exposure.

Be cautious with fresh package and extension updates

The newest release is also the release with the least scrutiny.

Where practical, avoid installing packages or privileged editor extensions immediately after publication, especially on machines that can access production systems or private repositories. A delay of even 24 to 48 hours can give the security community time to detect a compromised release.

For critical workstations, consider disabling automatic updates for powerful extensions and updating them deliberately after checking release information.

Treat editor extensions like installed software

A VS Code extension can run code on your machine. It should not be treated like a harmless theme or formatting preference.

Keep only the extensions you genuinely need. Remove unused extensions. Pay particular attention to extensions that can execute commands, access repositories, manage cloud tools, or integrate with AI and development agents.

A verified publisher badge is useful, but it is not a guarantee that every future version is safe.

Use minimal, short-lived credentials — very important

Avoid storing broad, long-lived tokens on your workstation unless absolutely necessary.

Use fine-grained GitHub tokens with minimal repository access. Prefer short-lived credentials and OpenID Connect-based publishing or deployment where supported. Do not give a local token permission to access every repository or publish every package when it only needs one limited task.

When one credential is stolen, its permissions determine how bad the breach becomes.

Review workflow changes as seriously as source code

Any change to .github/workflows/, deployment scripts, release automation, package publishing configuration, or secret-handling code deserves close review.

Do not approve a pull request simply because the commit looks like routine automation. Check who authored it, what changed, whether encoded scripts were introduced, and whether the workflow now reads secrets or communicates with unfamiliar endpoints.

For personal repositories, enable branch protection and require review before workflow changes are merged whenever possible.

Lock dependencies and inspect unexpected changes

Use lockfiles and keep them committed. When updating dependencies, inspect unexpected additions, lifecycle scripts, or large version jumps.

Avoid running install commands in unfamiliar repositories while authenticated to sensitive services. A package installation can execute code locally, and a compromised dependency may attempt to harvest whatever credentials are already present on your machine.

Separate sensitive work from everyday experimentation

If you regularly test new packages, extensions, AI development tools, or open-source projects, consider doing so in a separate environment, container, virtual machine, or low-privilege user profile.

Your experimental development environment should not automatically have access to production cloud credentials, package publishing tokens, or sensitive organization repositories.

Know how to respond if you may be affected — an action item for everyone

If you installed Nx Console version 18.95.0, or had it auto-update during the exposure window on May 18, 2026, Nx recommends treating the device as potentially compromised.

That means removing the affected extension, rotating accessible credentials, inspecting GitHub activity and repository workflows, reviewing local persistence indicators, and checking any cloud or package registry accounts accessible from that machine.

Likewise, maintainers should examine repositories for unexplained workflow changes or bot-like commits around May 18, 2026, particularly changes affecting GitHub Actions.

The Bigger Lesson

The most important lesson from these attacks is that the software supply chain now reaches all the way to the developer’s keyboard.

An official extension can become malware. A normal dependency update can steal a token. A harmless-looking CI commit can become a credential-exfiltration mechanism. A single workstation can provide access to thousands of repositories.

Developers cannot personally eliminate every supply-chain risk. But we can stop assuming that trusted tools remain trustworthy forever.

Security today is not only about protecting production servers. It is also about protecting the editor, the terminal, the dependency install, the workflow file, and the credentials sitting quietly on a developer machine.

Because increasingly, that is where the attack begins.

Sources

• Nx: Postmortem for the Nx Console v18.95.0 supply-chain compromise
• BleepingComputer: GitHub confirms breach of 3,800 repositories via malicious VS Code extension
• Aikido Security: GitHub breached via a malicious VS Code extension
• The Register: Megalodon attack poisoned more than 5,500 GitHub repositories