Wire Fire — Episode 02

On 18 May 2026 an attacker published a poisoned version of a popular Visual Studio Code extension. It was live for roughly eleven minutes. That was long enough to reach a GitHub employee's laptop, and from there to exfiltrate around 3,800 of GitHub's own internal source-code repositories. GitHub confirmed the breach on 20 May. This is the situation, what it means, and what to do about it.

The Breach

The timeline is short and worth stating precisely.

On 18 May, a trojanised build of Nx Console (the VS Code extension for the Nx build system, published under the identifier nrwl.angular-console) appeared on the Visual Studio Code Marketplace as version 18.95.0. It was live for approximately eleven minutes before being pulled. Eleven minutes is the number to sit with: it is the same lesson as the axios incident in Wire Fire Episode 01, where three hours of a poisoned package tagged "latest" was more than enough. A short window is not a small window when the install is automatic and the reach is global.

On 19 May, GitHub detected the intrusion. On 20 May, GitHub confirmed publicly that an employee's device had been compromised through the extension, and that the attacker had used that access to clone internal repositories. GitHub stated it had isolated the device, removed the extension, and rotated credentials within hours of detection.

The attacker is TeamPCP, tracked by Google Threat Intelligence as UNC6780, a group that specialises in supply-chain attacks against open-source security utilities and developer tooling, and that has been active across npm, PyPI and PHP package ecosystems earlier in 2026. They have claimed responsibility on underground forums and are reportedly asking more than 50,000 US dollars for the stolen material.

The Scope

Around 3,800 internal repositories were exfiltrated. GitHub reports, as of the confirmation, no evidence that customer data, enterprise accounts or user repositories were affected. That assessment may change as the investigation continues; treat it as the current state, not the final word.

The exposure surface is wider than GitHub, and that is the part worth attention. The Visual Studio Code Marketplace serves the most widely used code editor in the world. Installation is one click. There is no enforced provenance: the Marketplace does not require that the publisher prove control of the upstream project, and a name collision or a compromised publisher account can place a poisoned build in front of millions of developers in the time it takes to click "Install".

The Mechanism

Here is the part that should change behaviour, stated in plain terms.

A VS Code extension runs with the full privileges of the developer who installed it. There is no sandbox between the extension and the rest of your machine. When you open a workspace (a folder, a project) the extension's activation code runs immediately and automatically. From that moment the extension can read any file your user account can read, run any command your user account can run, and reach any credential, token or SSH key sitting on your machine.

The poisoned Nx Console build did precisely this. On activation it fetched an obfuscated payload from an external server and executed it. The payload harvested credentials and environment secrets. On an ordinary developer's machine that is bad. On a GitHub employee's machine, the harvested access was enough to clone internal repositories that the employee could legitimately reach.

Note what did not happen. No firewall was breached from outside. No server was exploited. No password was brute-forced. The attacker did not break in; the attacker was invited in, by an automatic activation of code the developer chose to trust with a single click. The front door was never touched.

The Exposure

If you installed Nx Console (nrwl.angular-console) around 18 May 2026, and specifically version 18.95.0, you should assume the machine is compromised. Rotate every credential reachable from that machine: cloud tokens, registry tokens, SSH keys, API keys, anything in your environment or your credential store. Revoke and reissue, do not merely change. Check for unexpected outbound network connections and review recent repository access.

For everyone, whether or not you touched this specific extension, the operative steps are the same and they generalise:

• Pin extension versions where your editor allows it, and disable automatic updates for extensions. Auto-update is the mechanism that turns one poisoned build into thousands of compromised machines before anyone notices.
• Audit your installed extensions and their publishers. Remove the ones you do not use. Every extension is attack surface that runs as you.
• Treat a new editor extension with the same suspicion you would give a new dependency in your code. You would (one hopes) read about a new npm package before adding it to production. The extension has more privilege and runs sooner.

On FreeBSD, the structural fix has a name. Capsicum is a capability-mode sandboxing framework: a process can drop into capability mode and then operate only on the file descriptors and resources it was explicitly handed, with no ambient authority to open new files, make new connections, or reach the wider system. An editor built on that model could run an extension in a box that holds only what the extension actually needs. Editors are not built that way yet, on any platform. The capability is in the kernel; the application has not asked for it.

The Pattern

The editor is now part of the supply chain, and that is the structural news under the GitHub headline.

For two years the industry has been learning, expensively, that npm install runs arbitrary code with your privileges, that the registry is an attack surface, that a dependency you did not write and cannot read is running on your machine. Wire Fire Episode 01 covered the npm side of this in detail. The lesson is now well established for package registries.

It is exactly as true for editor extensions, and almost nobody treats it that way. The extension marketplace is a package registry by another name: arbitrary code, published by parties you have not vetted, installed with one click, activated automatically, running with your full privileges. It has all the supply-chain risk of npm and less of the scrutiny, because the install does not feel like adding a dependency. It feels like configuring your editor.

For a decision-maker, the translation is direct: editor extensions are production dependencies and belong in your software-supply-chain policy. If your organisation reviews and pins npm packages but lets developers install any VS Code extension with one click, you have secured the front door and left every window open. GitHub, of all organisations, demonstrated the cost this week. The marketplace is a registry now. It is not being watched like one.

The home of the world's source code was read through a plugin to the world's most popular editor. Both, as it happens, belong to the same company. The call came from inside the toolchain.

Read the full article on vivianvoss.net →

---

By Vivian Voss, System Architect and Software Developer. Follow me on LinkedIn for daily technical writing.