Malicious VS Code extensions can execute commands at startup

At a glance

What this is: This is an analysis of a malicious VS Code extension that executes remote shell commands at startup by reading a hidden config key and decoding commands from a C2 URL.

Why it matters: It matters because developer workstations and extension ecosystems can turn into execution paths for compromised or malicious non-human identities, and IAM teams need visibility into artifact drift, workspace trust, and startup-time execution.

Context

A malicious VS Code extension can become an execution path even when the marketplace listing appears empty of payloads. In this case, the extension activates on startup, reads a configuration value that is not declared in its manifest, and uses it to fetch remote commands for local execution.

The identity governance problem is not just code review, it is trust in what an extension can do at runtime compared with what it declares at publish time. For developer environments, that means the control boundary sits at startup, workspace settings, and binary artefact integrity, not only at the marketplace listing.

This is a developer tool abuse pattern, but it is also an NHI-adjacent governance issue because the extension behaves as a hidden execution principal with unreviewed runtime authority. The gap is typical of modern extension ecosystems, where declared settings and compiled behaviour can diverge.

Key questions

Q: What breaks when a VS Code extension can execute startup commands without user interaction?

A: The control that breaks is the assumption that installed developer tooling remains passive until a user invokes it. If an extension activates on startup, reads hidden configuration, and executes shell commands, then installation itself becomes an execution decision. Teams should treat startup-capable extensions as privileged runtime components, not ordinary plugins.

Q: Why do undeclared configuration keys in extensions create security risk?

A: They create risk because declared settings no longer describe the real control surface. Reviewers may trust the manifest and miss a hidden namespace that can be pre-seeded by workspace files or other local inputs. That mismatch lets an extension behave differently at runtime from what users and policy checks believe it can do.

Q: How should teams evaluate whether an IDE extension is safe to deploy?

A: They should test the compiled artefact, not just the marketplace listing or source repository. The important questions are whether the extension activates automatically, reaches out to the network, reads hidden configuration, or hands remote content to a shell executor. If any of those are true, the extension deserves higher-risk handling.

Q: What should security teams do when extension behaviour differs from its published manifest?

A: Treat that difference as a control failure, not a documentation issue. Behavioural drift means the extension may be using a different trust path than the one exposed to users. Teams should quarantine the package, inspect the built artefact, review workspace-scoped inputs, and determine whether the extension can initiate local commands.

Technical breakdown

How startup activation turns a VS Code extension into an execution path

The extension uses an activation event of onStartupFinished, which means its code runs automatically when VS Code opens rather than when a user explicitly requests a function. That is a high-trust execution moment because startup code can inspect local settings, reach out to the network, and initiate commands before the user understands what is happening. In this case, the extension does not need a visible UI action or prompt. The practical risk is that startup activation effectively converts a developer extension into a persistent execution trigger.

Practical implication: treat startup activation as a privileged runtime boundary and review every extension that runs before user interaction.

Why undeclared configuration namespaces are a runtime trust failure

The published manifest declared one configuration key, but the shipped JavaScript read a different namespace. That mismatch matters because reviewers, users, and policy tooling may inspect package.json and believe they understand the extension’s settings surface, while the compiled artefact uses a hidden value that can be seeded through workspace files. This is source-versus-binary drift, not merely a bad default. It breaks the assumption that declared configuration is the full control surface. For security teams, hidden configuration reads are a strong sign that a plugin can be steered outside its documented behaviour.

Practical implication: compare declared extension settings with compiled artefact behaviour, not just the marketplace metadata or source tree.

How remote command fetching and child_process.exec create arbitrary code execution

The extension issues an HTTP GET to the configured URL, base64-decodes each returned line, and passes the result directly to child_process.exec. That pattern combines remote control, local decoding, and shell execution without any meaningful validation. Because the commands are served externally, the VSIX itself contains no fixed payload, which makes static signatures less useful and shifts detection toward runtime behaviour. The silent error handling also reduces visibility, because failed fetches or decode attempts do not create obvious user-facing friction. The technical problem is command injection by design, not accidental misuse.

Practical implication: block extensions that translate network responses directly into shell execution, even when no payload is embedded in the package.

Threat narrative

Attacker objective: The attacker aims to gain repeatable shell execution on developer endpoints and use the IDE as a persistent execution foothold.

1. Entry occurs when a developer installs the VS Code extension or inherits it through a repository workspace that seeds the hidden configuration value.
2. Credential or control access is gained when the extension reads the undeclared agentService.url namespace and uses that value to reach the attacker-controlled URL.
3. Escalation happens when decoded commands are passed to child_process.exec, giving the remote operator shell execution on the developer workstation.
4. Impact is achieved when the command runner repeats on every startup, creating persistent workstation-level execution without user interaction.

Breaches seen in the wild

• GlassWorm campaign 2025: GlassWorm hid in VS Code extensions with invisible Unicode and stole npm, GitHub and Open VSX publishing tokens to spread.
• Secrets in VS Code extensions 2025: Wiz found 550+ secrets in VS Code extensions, including publishing tokens able to push malicious updates to about 150,000 installs.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Source and compiled artefact drift is the governance failure this case exposes: the manifest said one thing, while the shipped binary read a different configuration namespace and executed a different control path. That breaks the assumption that extension review of declared settings is enough to understand runtime authority. Practitioners need to treat compiled artefacts as the real policy boundary, not the source tree alone.

Startup-triggered extension code is effectively a hidden execution principal: once a plugin can run on onStartupFinished, it behaves like a trusted runtime actor with local file, network, and shell reach. That authority is structurally different from a normal UI-bound extension because it can act before human review, which means developer tooling must be governed as an execution surface, not just an application catalog.

Hidden configuration namespaces create identity blind spots in developer ecosystems: the declared key in package.json and the read key in the binary were not the same, so policy controls that key off advertised configuration would miss the true control channel. The practical conclusion is that runtime inspection and artefact integrity need to sit alongside marketplace hygiene when governing extension-based execution.

Commanding a workstation through a remote response is a trust model collapse: the extension accepted remote text, decoded it, and executed it as shell commands with no user gate or command allowlist. That is not merely malicious code, it is a broken assurance model for what an extension may do after installation. Security teams should read this as a warning that extension trust must be scoped by runtime behaviour, not by store presence.

Runtime policy for developer tools now belongs in identity governance conversations: extension publishers, internal package mirrors, and workspace settings all create delegated authority paths that look operational but act like access decisions. The field needs a named concept here: extension execution drift, meaning the gap between a plugin’s declared function and its compiled ability to initiate privileged runtime actions. Practitioners should govern that drift explicitly.

From our research library:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
• Read next: AI Agent Observability, Audit and Incident Response Guide

What this signals

Extension execution drift: security teams need a name for the gap between what an extension declares and what its compiled binary can actually do. When runtime behaviour includes startup activation, remote fetches, and shell execution, store review alone is no longer sufficient for governance.

Developer tooling belongs in the same control conversation as other delegated execution surfaces. If a repository can seed extension settings and a binary can silently honour them, then workspace trust, artefact integrity, and runtime inspection become part of identity and access governance for engineering environments.

For practitioners

• Audit extension startup execution paths Inventory which IDE extensions activate on startup, then flag any that can fetch remote content or execute shell commands before user interaction.
• Compare manifests to compiled artefacts Review package.json declarations against the shipped VSIX or built extension.js to find hidden configuration namespaces and behaviour drift.
• Block network-to-shell command flows Reject extensions that take HTTP responses, decode them, and pass the result into child_process.exec or equivalent shell runners.
• Harden workspace settings ingestion Treat repository .vscode/settings.json files as potential control inputs and restrict extension behaviour that can be influenced by workspace-scoped values.
• Quarantine unsigned or unverified extension publishers Require additional scrutiny for newly published marketplace extensions whose declared settings, changelog, or internal naming do not align with shipped code.

Key takeaways

• A VS Code extension can become an execution channel when startup activation, hidden configuration reads, and shell execution are combined.
• The core evidence in this case is source and compiled artefact drift, which lets published settings obscure the real runtime control path.
• The practical control gap is behavioural review of packaged extensions, not just manifest review or marketplace trust.

Key terms

• Extension Execution Drift: The gap between what a developer extension declares in its manifest and what the shipped binary can actually do at runtime. In practice, this is a trust failure that lets hidden behaviours, undeclared settings, or startup hooks create privileged execution paths outside normal review.
• Startup Activation: Startup activation means code begins running automatically when the host application starts, before a user explicitly opens or invokes the extension. That makes the extension’s behaviour closer to an always-on workload than to a passive add-on, which changes governance and containment requirements.
• Declared Configuration Surface: The set of settings and inputs an application or extension says it supports. When the declared surface does not match the compiled artefact, policy checks and reviewers may miss the real control channel, which is especially dangerous in developer tooling and workspace-scoped inputs.
• Remote Command Execution: Remote command execution is the ability to run scripts or commands on managed systems from a central console. It is useful for administration and troubleshooting, but it also creates privileged access risk, so it should be paired with strong authentication, least privilege, logging, and clear accountability for every action.

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.