Here's what actually happened, step by step: On May 18, threat actors compromised the publishing account of Nrwl (the company behind Nx Console) on the VS Code marketplace. Between 12:36 and 12:47 UTC that day, they pushed version 18.3.4 of Nx Console containing malicious code to the marketplace using the legitimate publisher's credentials. The compromised version was cryptographically signed with Nrwl's valid publisher certificate, which is why VS Code's built-in verification accepted it without warning. When any developer's VS Code instance checked for extension updates during that 11-minute window (or when they manually installed Nx Console during that period), they pulled down the poisoned version directly from Microsoft's official marketplace. The extension wasn't hacked in the sense of someone modifying files on a server, it was published through the front door using stolen publisher credentials. How did the attackers get Nrwl's marketplace publishing credentials in the first place? That's the part most coverage is missing. VS Code marketplace publishing requires either a Personal Access Token (PAT) from Azure DevOps or OAuth credentials tied to a Microsoft account. Those credentials were almost certainly harvested from a previous supply chain compromise, possibly from an earlier wave of the same campaign. This creates a cascading failure pattern: compromise one developer tool to steal credentials, use those credentials to publish malicious versions of another developer tool, use that tool to steal more credentials, repeat. Each iteration increases the attacker's access to publisher accounts across the ecosystem. The Nx Console compromise wasn't patient zero, it was already deep in the chain. Once the poisoned extension was installed on a developer's machine (including the GitHub employee at the center of this story), it immediately executed code that scanned the entire machine for credentials. VS Code extensions are written in JavaScript and TypeScript, and they run inside Node.js, the same JavaScript runtime that powers VS Code itself. When you install an extension, VS Code loads its JavaScript code directly into the editor's process space with full access to Node.js APIs. The malicious code in Nx Console 18.3.4 used Node.js filesystem APIs (specifically fs.readFile, fs.readdir, and path traversal functions) to recursively scan the user's home directory and common credential storage locations. It searched for files matching patterns like.npmrc,.aws/credentials,.kube/config,.ssh/,.gitconfig,.netrc, and configuration files for 1Password CLI, HashiCorp Vault, and Claude Code. The extension also called Node.js child process APIs (child_process.exec and child_process.spawn) to execute system commands that dump environment variables, query the system keychain on macOS (using the security command-line tool), and extract credentials from Windows Credential Manager (using cmdkey). All of this happens in pure JavaScript running with the same privileges as the user who launched VS Code. There's no sandboxing, no permission prompts, no OS-level isolation. VS Code extensions are trusted code by design. The harvested credentials were then exfiltrated using Node.js's built-in https module to POST the data to attacker-controlled domains. The malicious code obfuscated the exfiltration endpoint using base64 encoding and string concatenation to evade static analysis, but once the extension executed, it made direct HTTPS requests to send compressed JSON payloads containing every credential it found. The extension's package.json declared activation events that caused it to run immediately on VS Code startup (using the "*" activation event, which triggers on any workspace open), meaning developers didn't need to explicitly invoke Nx Console features for the malicious code to execute. Just having VS Code running with the extension installed was enough. The JavaScript payload also injected hooks into VS Code's own credential storage APIs (using vscode.authentication and vscode.workspace APIs) to intercept any credentials the user accessed during their work session, including GitHub OAuth tokens VS Code uses for its own Git integration. From there, the attacker used those stolen credentials to install a second poisoned extension on the same employee's machine (GitHub has not yet disclosed which extension this was). That second extension exfiltrated approximately 3,800 internal GitHub repositories over the following hours or days. By May 20, the threat group TeamPCP was advertising the stolen repositories for sale on a hacking forum for $50,000 and up, hours before GitHub publicly confirmed the breach. Internal repositories are not customer data, they're something worse for infrastructure security. These repositories contain deployment scripts, staging credentials, internal API schemas, and infrastructure configurations. Source code access at that level hands attackers a blueprint of how GitHub's systems connect, authenticate, and fail. Every secret that reaches a buyer shortens the reconnaissance phase for whatever attack that buyer was already planning. Binance co-founder CZ immediately warned anyone with private repos containing plain text secrets to rotate everything. Mike Riemer, CTO of Ivanti, told me that Azure's honeypot network now shows known vulnerabilities exploited in under 90 seconds, and stolen credentials collapse the timeline even further. The GitHub breach did not arrive in a vacuum. On May 19, Endor Labs detected 42 malicious npm packages (Socket's broader tracking found 639 malicious versions across 323 packages) published inside Alibaba's @antv data visualization ecosystem, which sees roughly 16 million weekly downloads. This wave introduced provenance forgery: the Mini Shai-Hulud worm now calls Fulcio and Rekor at runtime to generate valid Sigstore signing certificates for every package it propagates. The provenance tooling shows a green badge. The build chain belongs to the attacker. Peyton Kennedy, senior security researcher at Endor Labs, told me that "TanStack had the right setup on paper: OIDC trusted publishing, signed provenance, 2FA on every maintainer account. The attack worked anyway." Also on May 19, threat actors compromised the GitHub Actions workflow actions-cool/issues-helper by redirecting every existing tag to an imposter commit containing malicious code that exfiltrates credentials from CI/CD (Continuous Integration/Continuous Deployment) pipelines. The exfiltration domain matched the @antv Mini Shai-Hulud wave, tying the clusters together. Hours later, Wiz detected that TeamPCP had compromised durabletask, Microsoft's official Python client for the Durable Task workflow execution framework. Three malicious versions were published to PyPI (Python Package Index) within a 35-minute window using a GitHub account compromised in a previous TeamPCP operation. The payload steals credentials from AWS (Amazon Web Services), Azure, GCP (Google Cloud Platform), Kubernetes, and over 90 developer tool configurations, then spreads laterally through cloud infrastructure. The package averages over 400,000 monthly downloads. The entire pattern repeats: compromise a popular tool, exfiltrate credentials from every machine that runs it, use those credentials to compromise the next tool. TeamPCP is building a credential database that spans the entire developer ecosystem, and they're selling access to anyone who'll pay.