Nx Console supply-chain malware exposes the agentic trust gap

At a glance

What this is: A malicious VSIX posed as Nx Console and executed a pinned external GitHub commit on startup, showing how developer extensions can become a supply-chain and identity-risk path.

Why it matters: IAM, NHI, and endpoint teams need to treat editor extensions as execution-capable software identities because they can introduce unprompted code execution, persistence, and token exposure into the workstation trust boundary.

By the numbers:

• VirusTotal returned 21 / 66 detections on the exact file.

👉 Read Knostic's analysis of the malicious Nx Console VSIX and supply-chain execution path

Context

A VS Code extension is not just a convenience layer. When it can auto-activate, run a shell task, and fetch code from an external repository, it becomes part of the workstation's execution trust chain and can affect both human identity sessions and non-human credentials present in the environment. In this case, the primary risk is not only malware delivery but identity-bound code execution without a consent step.

That matters because the security assumption behind many IDE controls is still that signed or familiar extensions behave like static tools. Once an extension can bootstrap remote code at activation time, the relevant question shifts to who or what is authorised to execute in the developer environment, what tokens are available to that process, and how quickly the blast radius extends into source control, package registries, and cloud access.

Key questions

Q: What breaks when a developer extension can run remote code on startup?

A: The control assumption that an extension is a passive tool breaks immediately. Startup activation plus shell execution turns the editor into a code runner with access to whatever credentials and sessions exist on the workstation. That can expose source-control tokens, cloud credentials, and SSH keys before any user prompt or review step occurs.

Q: Why do malicious IDE extensions matter to IAM and NHI teams?

A: They matter because the endpoint often contains the identities that attackers actually want. Once remote code executes in a developer session, it can reach non-human credentials, authenticated browser sessions, and repo access that IAM has already issued. The problem is governance across the workstation trust boundary, not just extension removal.

Q: How can security teams tell whether an extension has crossed the trust boundary?

A: Look for automatic activation, external fetches at runtime, shell task creation, and persistence markers in local state. Those signals show the extension is not just rendering UI but making execution decisions. If those behaviours exist, the extension should be treated as an execution-capable identity on the endpoint.

Q: What should teams do after a malicious extension is detected?

A: Contain the endpoint, remove the extension, and rotate any secrets that were available in the user session when activation occurred. Then review repository access, package registries, and cloud control planes for follow-on activity. The key question is not only whether the machine is clean, but whether reachable identities have already been abused.

Technical breakdown

How malicious VSIX activation becomes code execution

VS Code extensions can declare activation events such as onStartupFinished or onUri, which means code runs automatically when the editor opens or a URI is handled. In this sample, activation triggered an install path that spawned a shell task using npx -y github:nrwl/nx#. Because npx resolves and executes package content on demand, the extension effectively converted extension activation into remote code execution on the user's machine. The persistence gate in globalState reduced repeated prompts, which made the behavior quieter after a successful run.

Practical implication: Treat extension activation as an execution path and restrict which editors, marketplaces, and publishers are allowed to place code in that path.

Why pinned GitHub commits still create supply-chain risk

A pinned Git commit is not the same as a trusted local binary. It only fixes the reference point, not the provenance, review state, or runtime behavior of the code at that commit. If the referenced commit has been compromised, or if the extension intentionally points to attacker-controlled content, the pin simply makes the malicious payload more repeatable. This is the same structural weakness that appears in developer supply-chain attacks where the fetch source is remote but the trust decision is local and silent.

Practical implication: Validate remote code sources as execution sources, not just dependency coordinates, and review any extension that shells out to external repositories.

Why workstation tokens and developer secrets are the real prize

Developer workstations often hold authenticated browser sessions, SSH keys, npm tokens, cloud credentials, and GitHub access. A malicious extension that can run code at startup can enumerate that environment long before defenders notice any network anomaly. That makes the identity problem broader than malware removal. The attacker objective is usually to convert a single trusted desktop session into durable access to repositories, CI systems, and cloud control planes through exposed secrets and authorised tooling.

Practical implication: Assume every extension-driven code execution event can expose non-human credentials and require containment steps that include token rotation and session review.

Threat narrative

Attacker objective: The attacker objective is to turn a trusted developer extension into a repeatable execution foothold that can expose credentials and seed broader supply-chain compromise.

1. Entry occurred when the user installed a VSIX that claimed to be nrwl.angular-console and auto-activated on editor startup.
2. Escalation occurred when the extension ran npx against a pinned external GitHub commit, turning editor activation into remote code execution with no user prompt.
3. Impact occurred when the same logic wrote a persistence key in globalState, enabling repeat execution and creating a path for token exposure and developer-environment compromise.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.

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

NHI Mgmt Group analysis

Extension activation is now an execution boundary, not a UX event: A VSIX that can auto-run shell tasks on startup sits inside the same trust model as other non-human identities that can execute code on behalf of a user. That means the security question is no longer whether the extension looks legitimate, but whether it can cause action before a human makes a decision. Practitioners should treat activation as a privileged event.

Developer workstation trust now depends on non-human credential containment: A malicious extension does not need to steal a password to become dangerous. It only needs access to the tokens, SSH keys, and cloud sessions already present on the endpoint. That makes endpoint software a governance problem for IAM, PAM, and NHI teams, not just endpoint security. The practical conclusion is that workstation identity and credential exposure must be managed as a shared control plane.

Remote code from pinned commits creates a provenance illusion: Pinned references feel controlled, but they do not guarantee safe behavior, clean history, or appropriate review. The named concept here is extension-driven identity blast radius, the way a single editor extension can expand access from a local session into source control, CI, and cloud systems. The implication is that provenance checks must be tied to execution rights, not just artifact metadata.

Supply-chain malware turns human sessions into non-human identity exposure: Once code runs in a developer shell, the immediate target is often not the device but the machine identities and service credentials reachable from it. That is why this pattern belongs in NHI governance as much as in malware response. The implication is that teams need joint control ownership across endpoint, IAM, and software supply-chain programmes.

Persistence keys in local application state are a governance signal: A one-time persistence flag may look harmless, but it can encode durable trust in a process that should remain reviewable. In a malicious extension, that design choice turns a single startup event into repeated unattended execution. Practitioners should recognise local-state persistence as an identity continuity issue, not a minor implementation detail.

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.
• DeepSeek accidentally embedded over 11,000 secrets in its training data and left a database exposed online, revealing more than one million sensitive records including chat histories, backend credentials, and API keys.
• Forward signal: The 52 NHI breaches Report shows how quickly exposed machine credentials can turn into repeatable access paths across developer, cloud, and AI environments, according to 52 NHI Breaches Analysis.

What this signals

Extension-driven identity blast radius: The next control gap in developer security is not just code signing but execution authority. A tool that can auto-activate, call out to remote code, and persist a success flag is already behaving like a privileged runtime identity, which means endpoint policy has to be written with IAM and NHI semantics in mind.

The practical signal for programmes is that secret rotation, repository monitoring, and endpoint hardening now need to be correlated. If the same machine can hold source-control tokens, cloud sessions, and package-manager access, then one malicious extension can bridge all three in a single user session.

Teams that already track exposed secrets should connect those efforts to supply-chain response and developer-workstation containment. The strongest posture is one that treats editor extensions as part of the software trust chain, not as harmless productivity add-ons.

For practitioners

• Constrain extension execution paths Allow only approved publishers and marketplace sources in developer environments, and block extensions that shell out to remote repositories or use startup activation for code retrieval.
• Inventory developer machine credentials Assume an activated malicious extension may have seen SSH keys, npm tokens, cloud credentials, and browser sessions. Rotate exposed secrets and review GitHub repositories, package registries, and cloud console access for unusual activity.
• Review local persistence markers Check for application-state keys such as nxConsole.mcpExtensionInstalledSha or similar one-time gates that indicate an extension executed unattended code and then suppressed future prompts.
• Separate editor trust from production identity trust Treat a compromised developer workstation as a potential source of non-human identity compromise, because local tokens and repo credentials can be enough to move from endpoint risk into CI and cloud control planes.

Key takeaways

• A malicious developer extension can convert editor startup into unattended code execution, which collapses the normal trust model around local tools.
• The scale of the risk is the reachable identity set on the workstation, including SSH keys, cloud tokens, and authenticated sessions, not just the extension binary itself.
• Containment has to include extension removal, secret rotation, and review of downstream repository and cloud access because endpoint compromise can become identity compromise.

Key terms

• Malicious VSIX: A malicious VSIX is a Visual Studio Code extension package that contains harmful behaviour rather than only productivity features. In identity terms, it is an execution-capable software component that can reach the user's session, local state, and accessible credentials once installed and activated.
• Extension-driven identity blast radius: Extension-driven identity blast radius is the set of identities and systems reachable when an editor extension can execute code on a workstation. For developer environments, that often includes source-control tokens, SSH keys, cloud sessions, and package-manager credentials, making local compromise a broader identity event.
• Local persistence gate: A local persistence gate is a state value that prevents repeated behaviour after an action has succeeded once. In malicious software, this can suppress prompts and make execution quieter on later runs, which is why local application state matters during containment and forensic review.
• Supply-chain execution path: A supply-chain execution path is the route by which remote code enters a trusted environment through dependency resolution, package fetching, or extension activation. It matters because the code is executed inside a legitimate workflow, which can hide the origin of the compromise until after identity assets have been exposed.

What's in the full article

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

• The exact static-analysis workflow used to confirm the VSIX behaviour without executing the package.
• The file-level indicators, activation events, and globalState persistence pattern that operators can hunt for in similar extensions.
• The full IoC list and VirusTotal context for defenders validating whether a suspicious extension has already run.
• The recommended user-side response steps for checking workstation state and identifying whether remote code likely executed.

👉 Knostic's full post covers the static-validation details, IoCs, and response guidance for this extension sample.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.