Nx Console compromise exposed the developer workstation trust gap

At a glance

What this is: This is a breach analysis of a malicious Nx Console extension release that used auto-update and editor activation to steal developer credentials from workstations.

Why it matters: It matters because developer IDEs now sit inside the identity attack surface, where NHI secrets, cloud tokens, and AI tool credentials can be harvested before traditional controls notice.

By the numbers:

• The malicious version was exposed in the Visual Studio Marketplace for roughly 18 minutes, from 12:30 to 12:48 UTC.
• The same advisory says internal Nx telemetry later showed approximately 6,000 extension activations from VS Code after the attack.
• The GitHub CNA scored CVE-2026-48027 at 9.8 critical under CVSS 3.1 and mapped it to CWE-506.

👉 Read Corgea's analysis of the malicious Nx Console 18.95.0 compromise

Context

CVE-2026-48027 is a developer-workstation compromise, not a production-server exploit. The malicious Nx Console release used a trusted extension channel to reach editors where source control tokens, package credentials, cloud CLIs, Vault sessions, and AI tooling secrets are often already present, which makes the identity boundary on the workstation the real target.

That matters for IAM and NHI governance because the compromise collapses the usual separation between endpoint security and identity risk. When an IDE can execute attacker-controlled code during auto-update and then harvest tokens from local files, memory, and CLI state, the workstation becomes a high-value credential container rather than a simple user device.

The subject is atypical only in its delivery path. The underlying pattern, credential theft from a trusted developer environment followed by lateral use of those secrets, is now a familiar enterprise failure mode.

Key questions

Q: What breaks when a trusted developer extension can auto-update into malware?

A: The trust model breaks at the point where an editor can execute code before review or containment. A malicious extension can use the same user session that developers rely on for source control, cloud access, and package publishing, turning convenience into credential exposure. Security teams need version gating, staged rollout, and host-level monitoring for extension behaviour.

Q: Why do developer workstations create NHI risk as well as human identity risk?

A: Developer workstations often store or reach cloud keys, API tokens, SaaS sessions, and service-account paths used by automation. If malicious code runs in that context, the attacker can move from a human session into non-human identities and production controls without needing a separate breach.

Q: How do security teams know if extension compromise has turned into wider identity abuse?

A: Look for impossible combinations of signals, such as unexpected secret reads, new package publishes, unfamiliar GitHub API use, cloud token reuse from developer hosts, and access from endpoints that should never touch production identities. The key signal is not one alert but a sequence that shows stolen credentials being reused across systems.

Q: Who is accountable when a poisoned extension steals publishing or cloud credentials?

A: Accountability sits with the teams that own endpoint control, developer tooling governance, and identity lifecycle management for the affected secrets. If an extension publisher account, developer session, or build identity was not segmented and monitored, the control gap is organisational, not just technical. Recovery must include revocation, audit, and governance review.

Technical breakdown

How a trusted extension becomes an execution path

The malicious release did not rely on a classic installer prompt. It executed from the extension activation path after auto-update, then created a hidden VS Code task that ran npx against a hardcoded orphan Git commit. That design matters because the editor itself becomes the launch point for code retrieval and execution, bypassing checks that only inspect package install hooks. The use of -y suppresses interaction, while the stored state key prevents repeated execution. In practice, the compromise rides normal editor behaviour, not a suspicious one-off binary download.

Practical implication: Treat extension auto-update and activation as execution pathways that require allowlisting, staging, or delay controls.

Why credential harvesters target the IDE and local runtime

The payload was built to collect secrets from wherever developers actually use them: GitHub tokens, npm auth, cloud credentials, Vault sessions, Kubernetes material, SSH keys, 1Password sessions, and Claude Code or MCP configuration. It also tried to read process memory under /proc/*/mem, which means secrets already loaded into terminals, local servers, and IDE sessions can be exposed even when they are not on disk. This is a broader compromise model than simple file theft, because runtime access expands the harvest surface beyond static secret scanning.

Practical implication: Assume IDE compromise can expose live credentials in memory, not only secrets stored in files.

Signed provenance is not proof of trust after identity compromise

The post-compromise chain included encrypted exfiltration, GitHub API abuse, and logic for leveraging OIDC and registry paths that can support republishing with apparent provenance. That means signatures, transparency logs, and trusted-publishing workflows still depend on the integrity of the identity used to invoke them. If the publishing identity, developer session, or token is stolen, provenance becomes a record of compromise rather than a guarantee of legitimacy. This is where supply-chain security and identity governance meet directly.

Practical implication: Verify the identity behind publishing and signing actions, not just the presence of signatures or attestations.

Threat narrative

Attacker objective: The attacker aimed to turn a trusted developer extension into a scalable secret-harvest platform that unlocked downstream access across code, cloud, and publishing systems.

1. Entry occurred through a malicious auto-updated Nx Console extension that ran when a developer opened a workspace.
2. Credential access followed as the payload harvested GitHub, cloud, Vault, Kubernetes, SSH, npm, and AI-tool secrets from files, APIs, and process memory.
3. Impact came from stolen tokens and sessions that could be reused for repository access, package publishing, cloud access, and CI/CD lateral movement.

Breaches seen in the wild

• Gladinet Hard-Coded Keys RCE Exploitation — Actively exploited hard-coded keys in Gladinet CentreStack and Triofox enable remote code execution.
• Hard-Coded Secrets in VSCode Extensions — 500+ VSCode extensions expose hardcoded tokens and credentials creating massive developer supply chain risk.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Developer workstations are now identity systems. When an IDE can harvest cloud tokens, Vault sessions, npm credentials, and AI-tool secrets, workstation governance becomes part of IAM and NHI control design. The boundary between endpoint security and identity governance is no longer clean, because the workstation itself stores and executes high-value non-human identities. Practitioners should treat developer endpoints as managed identity runtimes, not ordinary user laptops.

Auto-update creates a credential exposure window that policy teams often ignore. A trusted extension can become malicious long before a maintainer can react, which means publisher trust alone is too weak for modern software supply chains. This is the same structural problem that weakly governed service accounts create in other domains: a standing trust relationship becomes a standing opportunity for abuse. The practical conclusion is to control version age and update timing, not just publisher reputation.

Signed provenance can amplify risk when the publishing identity is already compromised. The presence of Sigstore, SLSA, or OIDC-based publishing metadata does not help if the attacker stole the token or session behind the signing action. That is a governance problem, not a cryptography problem. For identity teams, this is a direct reminder that NHI lifecycle controls must cover publisher accounts, build identities, and developer sessions as first-class assets.

Secret sprawl is the attacker’s real multiplier. One compromised workstation can expose GitHub, cloud, Kubernetes, SSH, and AI coding credentials in a single execution window, which is exactly why secret concentration without strong containment is dangerous. Credential fan-out: the same stolen session can propagate across code, infrastructure, and AI workflows faster than teams can manually revoke it. Practitioners should design for blast-radius reduction, not just secret storage hygiene.

This incident validates the need for identity-aware endpoint containment. Endpoint controls that do not understand credential movement miss the actual failure mode, which is secret theft from a trusted runtime. The identity security programme has to include developer tools, build systems, and signing workflows as governed subjects, because they are now part of the enterprise identity graph.

From our research:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• Compromised secrets move fast because dwell time is measured in minutes, not hours, which is why revocation delay becomes a security control rather than an administrative detail.
• Forward look: The Guide to the Secret Sprawl Challenge shows why secret concentration and discovery gaps keep widening the blast radius of a single workstation compromise.

What this signals

Credential fan-out is the practical risk signal here: one developer endpoint can expose enough identities to move from local compromise into source control, cloud, and release pipelines. The programme implication is straightforward. If your controls do not detect secret movement from IDEs and terminals, they are already behind the attack path.

Identity teams should treat developer-tool authentication, extension governance, and publishing accounts as part of the same control plane. The useful standard here is OWASP Non-Human Identity Top 10, because the failure mode is persistent trust in credentials that were never meant to survive compromise.

Version age is a measurable control: if a trusted extension can remain installable for minutes without review, your approval model is too loose for modern supply-chain abuse. Endpoint governance now needs revocation speed, not only prevention logic.

For practitioners

• Pin and stage extension updates Require a review delay before newly published VS Code-compatible extensions can install on managed developer devices, and block immediate auto-update for high-trust extensions.
• Treat developer endpoints as credential-bearing assets Inventory GitHub PATs, npm tokens, cloud CLI sessions, Vault tokens, Kubernetes service accounts, SSH keys, and AI-tool credentials on every developer workstation.
• Rotate secrets from a known-clean machine Revoke and reissue credentials from a clean device, including package publishing identities, cloud sessions, Vault access, and any 1Password or MCP-related secrets.
• Audit downstream publishing and access logs Review GitHub audit logs, Actions secret reads, npm publish history, Sigstore entries, Vault audit trails, and unexpected DNS or GitHub API activity from developer hosts.

Key takeaways

• This breach shows that a malicious developer extension can turn an IDE into an identity-harvesting platform.
• The evidence points to a broad secret-exposure blast radius, with GitHub, cloud, Vault, Kubernetes, SSH, and AI-tool credentials all at risk.
• The control that matters most is faster containment of trusted software updates, paired with immediate secret rotation from a clean device.

Key terms

• Shared Workstation Identity: A shared workstation identity is the practical relationship between a person, a device, and a session when multiple users access the same endpoint. In manufacturing, it must preserve attribution across handoffs, idle periods, and privileged actions, or the audit trail becomes ambiguous and hard to defend.
• Credential Fan-Out: The process by which one stolen secret or session opens access to many downstream systems. In developer environments, a single compromised workstation can fan out into source control, cloud, package publishing, and AI tooling access if secrets are not tightly segmented.
• Extension Auto-Update Risk: The security exposure created when trusted software updates install without review delay. For code editors and plugins, auto-update can turn a signed and familiar extension channel into an execution path for malicious code before administrators can intervene.
• Signed Provenance Abuse: A failure mode where attacker-controlled or stolen identities produce artifacts that appear legitimate because the signing workflow itself was compromised. The presence of signatures or attestations does not guarantee safety if the underlying publishing identity was already stolen.

What's in the full report

Corgea's full analysis covers the operational detail this post intentionally leaves for the source:

• Compiled indicators of compromise for the malicious Nx Console 18.95.0 release and the related orphan commit.
• Step-by-step remediation actions for VS Code, Cursor, Windsurf, and other VS Code-compatible editors.
• Detailed payload analysis of the secret collectors, exfiltration paths, and persistence artefacts.
• Source references for the GitHub, CISA KEV, StepSecurity, and NVD tracking updates.

👉 The full Corgea post covers indicators of compromise, payload behaviour, and remediation steps for affected developer fleets.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management for practitioners who need operational clarity. It helps security and identity teams build the control language required to govern modern credential sprawl.