An Nx Console Version With 2.2 Million Installs Was on the VS Code Marketplace for Exactly 11 Minutes—Long Enough to Reach 1Password Vaults, Claude Code Configs, and SSH Keys

What Happened

On May 19, 2026, The Hacker News reported that an attacker had pushed a malicious version of the Nx Console VS Code extension—officially listed as rwl.angular-console, with more than 2.2 million installs—to the Visual Studio Code Marketplace. Version 18.95.0 went live at 2:36 PM CEST on May 18 and was removed eleven minutes later at 2:47 PM.

Eleven minutes does not sound like long. For a marketplace extension that auto updates by default on millions of developer machines, eleven minutes is forever. The Open VSX registry, which is what VS Code forks like Cursor and Codium use, was not affected. Anyone running stock VS Code with auto update enabled was exposed.

How the Bad Version Got In

The attacker did not breach the VS Code Marketplace. They did not exploit a vulnerability in the publishing pipeline. They used a stolen GitHub credential that had leaked from an Nx maintainer's machine in a prior security incident, then pushed a malicious commit to the nrwl/nx repository. The repository's own automation handles publishing to the marketplace, so the commit cascaded forward into a real release with the right author identity attached.

This is the same playbook as the TanStack Mini Shai-Hulud campaign earlier this month and the Checkmarx Jenkins backdoor from May 12. The end target is the developer machine. The vector is whatever credential happens to still be valid in the maintainer's environment.

The Multi Stage Payload

The extension itself was small. The first thing it did when VS Code activated it for a workspace was reach out to a dangling orphan commit in the nrwl/nx GitHub repo and download a 498 kilobyte obfuscated payload. Orphan commits are commits not reachable from any branch—you can push them, reference them by hash, and have them sit in the repo's object store without ever showing up in the commit history. They are the perfect hiding place for second stage code.

To run the second stage, the payload installed Bun—the JavaScript runtime—locally and used it to execute the obfuscated code. Bun is fast enough to make the staging invisible to most behavioral monitoring, and it does not rely on Node's standard library, so detection rules tuned for malicious Node modules tend to miss it.

Once the second stage was running, it went hunting for everything that looked like a credential. The list of targets:

• 1Password vaults. The local data files for the 1Password desktop client.
• Anthropic Claude Code configurations. The settings and authentication state for Anthropic's coding assistant, which holds an API token that can run arbitrary code in the user's environment.
• npm authentication tokens. The ones in .npmrc and the keychain.
• GitHub credentials. Personal access tokens, SSH keys, and stored OAuth refresh tokens.
• AWS secrets. The contents of ~/.aws/credentials, including session tokens for federated logins.
• SSH keys. Everything in ~/.ssh/.

The exfiltration was layered: HTTPS for the bulk of the data, the GitHub API for material that could be disguised as legitimate API traffic, and DNS tunneling as a fallback when corporate proxies blocked the other channels.

The Sigstore Twist

The most novel part of the payload is the part that signals where supply chain attacks are headed. The malicious code included full Sigstore integration: Fulcio certificate issuance, SLSA provenance generation, and the supporting trust roots needed to make signed releases.

Sigstore is the industry's answer to "how do we prove this package was built from the source we think it was built from." A package signed with Sigstore and accompanied by valid SLSA provenance is supposed to be more trustworthy than an unsigned one, because the signature ties the artifact back to the build environment that produced it. Several enterprises have started using Sigstore signatures as a gating criterion for what their pipelines will install.

A credential stealer that can produce its own valid Sigstore signatures and SLSA attestations can publish trojaned packages that look legitimate to every automated verification check downstream of npm. Once the stealer harvests an npm token from a victim, it can use that token to publish a malicious release, signed with a real Sigstore certificate issued in the user's name, with provenance pointing at a real source repository. Every link in the chain reads as authentic.

This is the maturation of the supply chain category. The 2022 attackers ran scripts that posted secrets to Pastebin. The 2026 attackers are integrating with the trust infrastructure itself.

If You Installed It

If your VS Code auto updated extensions on May 18 between 2:36 and roughly 3:00 PM CEST, treat your machine as compromised until proven otherwise.

Indicators of compromise published by the Nx team:

• The file ~/.local/share/kitty/cat.py on Linux or macOS.
• The launch agent ~/Library/LaunchAgents/com.user.kitty-monitor.plist on macOS.
• The state file /var/tmp/.gh_update_state.
• Anything matching /tmp/kitty-*.
• Running Python processes named cat.py.
• Any process running with the environment variable __DAEMONIZED=1.

The remediation:

• Update Nx Console to 18.100.0 or later.
• Kill the listed processes and remove the listed artifacts.
• Rotate every credential that was reachable from the affected machine. That means npm tokens, GitHub PATs, SSH keys, AWS keys, Anthropic API keys, and the master password on 1Password.
• Audit recent activity on every service whose credentials might have been stolen. Look for new SSH keys added to your GitHub account, unexpected npm publish events, AWS IAM access from unfamiliar addresses, and Anthropic API usage you did not initiate.

The AI Coding Assistant Surface

One detail in the target list deserves more attention than it has gotten so far: Anthropic Claude Code configurations. Claude Code, Cursor, Aider, and the other AI coding tools that have become standard in 2026 all store an API token on disk. That token typically has permission to read the user's code, run shell commands inside the user's repos, and call out to the model provider's API.

For an attacker, an AI coding assistant token is the closest thing to an interactive remote shell that does not look like a remote shell. You can use it to run code on the victim's behalf, you can use it to read whatever the victim's code can read, and the activity logs at the model provider will record it as a legitimate developer session. We have already seen this surface targeted in the mini Shai-Hulud npm worm earlier this month and again in the TanStack OIDC cache poisoning attack. The Nx Console hit makes it three in three weeks.

If you use any AI coding assistant, the token in its config directory is now a first class credential. Treat it like an SSH key. Rotate it on a schedule. Do not let extensions you barely use read the directory it lives in.

The VS Code Marketplace Problem

VS Code's extension model gives every extension full access to the user's environment by default. There is no permission prompt for a fresh install. There is no review process for new versions. There is no signature requirement that ties an update to a known maintainer chain. If an attacker can push a release, the release reaches every machine.

The Open VSX registry, which the open source VS Code forks use, escaped this incident because its publishing pipeline is decoupled from the upstream Marketplace. That is a useful data point: a different distribution chain meant a different blast radius. But for the 80 percent of developers who run stock VS Code with auto updates on, the Marketplace is the single point of failure, and an eleven minute window in a single afternoon was enough to set off a credential rotation across an estimated population of compromised machines that nobody has fully counted yet.

The fix is not going to come from a Microsoft policy change. The fix is going to come from developers treating their editor extension permissions the way they treat their browser extension permissions—skeptically, sparingly, and with the assumption that the next compromised maintainer is one credential leak away from running on your machine.