Malicious VS Code extensions can execute commands at startup

At a glance

What this is: This is a security analysis of a malicious VS Code extension that turns an undeclared configuration value into remote command execution on developer machines.

Why it matters: It matters because developer tooling now sits on the identity and access boundary, and hidden extension behaviour can create unmanaged execution paths that traditional endpoint and app control reviews miss.

👉 Read Knostic's analysis of the malicious VS Code extension startup execution chain

Context

Malicious extensions in developer IDEs matter because the workstation is no longer just a code editor, it is an execution environment with access to source, secrets, and build-time trust. In this case, the primary issue is not ordinary software supply chain risk alone, but hidden runtime behaviour that activates on startup and uses a configuration key the user is unlikely to inspect.

For identity and access teams, the important question is how much implicit trust is granted to software running inside the developer workflow. A package can appear benign in the marketplace, yet still create a durable execution path that bypasses normal review expectations through undeclared settings, remote fetches, and silent command execution.

Key questions

Q: How should teams assess risky VS Code extensions before allowing them on developer machines?

A: Teams should review the packaged extension, not just the repository, and look for startup activation, outbound network calls, hidden configuration reads, and any path to shell execution. Extensions that can fetch remote content and run it automatically should be treated as execution software, not simple tooling. Approval should require artifact parity, code inspection, and behavioural testing.

Q: Why do hidden extension settings create more risk than declared configuration?

A: Hidden settings create a control path that users, auditors, and reviewers are unlikely to see. If a shipped extension reads an undeclared namespace, an attacker can steer behaviour through workspace files or other seeded values without changing the visible settings model. That bypasses ordinary review and makes the runtime behaviour easier to hide.

Q: What breaks when an IDE extension can fetch commands and execute them on startup?

A: The boundary between a local productivity tool and a remote execution channel disappears. A startup-triggered fetch-and-exec pattern lets an operator change commands after installation, so trust in the original code no longer protects the workstation. In practice, that means the extension can act as a persistent foothold instead of a fixed application.

Q: What should security teams do when source code and the shipped extension do not match?

A: Teams should fail the approval and investigate the packaged binary, because the compiled artifact is what actually runs. A mismatch between source, metadata, and shipped code indicates that the repository history cannot be trusted as the only source of truth. That gap is especially dangerous in developer tooling that can touch credentials, source, and build systems.

Technical breakdown

Undeclared configuration namespaces create hidden control paths

The extension declares one settings key in package.json but reads a different, undeclared namespace at runtime. That mismatch matters because users and reviewers inspect declared configuration, not hidden keys embedded in compiled code. In practice, this creates a control plane the extension author can steer without exposing it in the settings UI or documentation. The real risk is not merely obfuscation. It is that the runtime behaviour is governed by a value that the normal extension review path is unlikely to surface.

Practical implication: review compiled artifacts for undeclared configuration reads, not just source manifests.

Startup activation plus remote fetch turns an extension into a command runner

The extension activates on startup, fetches content over HTTP, base64-decodes each line, and passes the result to child_process.exec. That is a direct remote execution chain, not a benign update check or content retrieval routine. Because the command source is external, the payload can change at any time without altering the shipped VSIX. This makes runtime behaviour dependent on a live operator-controlled endpoint rather than on static code review alone.

Practical implication: treat startup-triggered network calls followed by exec as a high-risk execution pattern requiring containment.

Source and compiled artifact drift is a supply chain control failure

The article shows that the TypeScript source was sanitized after publication, but the compiled VSIX was not rebuilt. That means the marketplace artifact preserved the malicious agentService namespace even though the visible repository history looked cleaner later. This is a classic source-compiled divergence problem. Security controls that validate only source code or only marketplace metadata can miss the binary reality that users actually install.

Practical implication: compare published source, compiled packages, and repository history before approving developer extensions.

Threat narrative

Attacker objective: The attacker aims to gain persistent command execution on developer endpoints so they can steal credentials, modify code, or extend access into build and source environments.

1. Entry occurs when a developer installs the VS Code extension or opens a workspace that pre-seeds the hidden configuration value through a malicious .vscode/settings.json file.
2. Escalation occurs when startup activation causes the extension to fetch operator-controlled commands, decode them, and execute them through child_process.exec without user interaction.
3. Impact occurs when arbitrary shell commands run repeatedly on every IDE startup, giving the attacker durable control over the developer workstation.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

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 tooling is now part of the identity perimeter. The extension is not just software, it is an execution surface with access to source, secrets, and workstation trust. That shifts review from basic marketplace hygiene to identity-aware control of what software can do at runtime. Practitioner conclusion: IDE extensions need the same scepticism teams already apply to privileged scripts and build agents.

Source and compiled artifact divergence is a governance gap, not a packaging detail. The article shows a visible repository state can differ from the shipped VSIX, leaving the malicious runtime path intact after source sanitisation. That means code review alone is insufficient when the distributed artifact is what executes. Practitioner conclusion: the approval decision must be based on the packaged binary, not the repository narrative.

Undeclared settings namespaces are a hidden policy bypass. A configuration value that is not declared in package.json is effectively outside normal user oversight, yet still drives execution. This is especially dangerous in developer environments where hidden settings can be pre-seeded by workspace content. Practitioner conclusion: policy controls must account for undeclared runtime inputs, not only declared extension capabilities.

Startup-triggered fetch-and-exec is a command-and-control pattern disguised as convenience. Fetching commands on every IDE startup creates a durable operator channel that changes the payload without changing the installed extension. That makes static trust decisions brittle and pushes governance toward runtime inspection. Practitioner conclusion: classify these extensions as execution-capable software, not productivity add-ons.

Remote command execution in the IDE collapses least-privilege assumptions at the workstation layer. Least privilege was designed for software whose behaviour is bounded by declared permissions and visible call paths. That assumption fails when an extension can read hidden config, retrieve remote instructions, and execute them on startup. The implication is that developer identity governance must rethink trust boundaries around tools that can self-direct execution inside the session.

From our research:

• From our research: The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
• For a broader control lens, review Top 10 NHI Issues to map hidden execution paths back to identity governance.

What this signals

Developer tooling is becoming a governance boundary in its own right, because an IDE extension can now blend configuration, network access, and shell execution into one hidden path. With 43% of security professionals already concerned about AI systems learning and reproducing sensitive information patterns from codebases, the wider lesson is that code-adjacent software must be reviewed as identity-bearing infrastructure, not just as productivity tooling.

Extension runtime trust debt: when users approve a package name but the binary reads different settings at runtime, the approval model itself becomes stale. That kind of drift is hard to detect with static review and should push programmes toward artifact-level verification and behavioural controls.

This is also where identity and secrets governance converge with developer experience. If a tool can consume hidden workspace settings and execute commands before a user notices, then secrets exposure and workstation compromise are no longer separate problems, they are the same operating condition.

For practitioners

• Inspect compiled extension artefacts before approval Compare the published VSIX, source repository, and package metadata to confirm that declared settings, runtime reads, and compiled output all match. Flag any extension that reads configuration keys not declared in package.json.
• Block startup activation with remote fetch plus exec Treat onStartupFinished handlers that call outbound HTTP and then child_process.exec as high-risk patterns. Quarantine extensions that fetch operator-controlled content before the user takes an explicit action.
• Hunt for undeclared workspace settings Search developer workspaces for hidden keys such as undeclared config namespaces and audit cloned repositories for settings files that can seed execution behaviour. Focus on values that influence extensions without appearing in the settings UI.
• Reclassify developer IDEs as controlled execution environments Apply allowlisting, behavioural monitoring, and tighter review to IDE extensions that can reach the network, decode content, or spawn shells. Do not treat the marketplace label as sufficient evidence of benign behaviour.

Key takeaways

• A VS Code extension can become a remote command runner when undeclared settings and startup activation are combined.
• The exposed risk is not just malware, but governance drift between the repository, the compiled artifact, and the runtime behaviour users actually inherit.
• Developer tooling should be treated as execution-capable infrastructure, with artifact inspection and behavioural controls to match.

Key terms

• Undeclared Configuration Namespace: A configuration key that influences runtime behaviour but is not defined in the public settings model. In developer tooling, this is a governance problem because reviewers and users inspect declared options, while hidden namespaces can still steer network access, command execution, or data flow.
• Source Compiled Artifact Divergence: A mismatch between visible source code and the packaged binary or shipped extension. This matters because security teams often trust repository review, but the artifact users install is the system that actually runs. Divergence can preserve malicious behaviour even after the source looks cleaned up.
• Startup Activation: An extension behaviour that runs automatically when the host application finishes starting. In security terms, startup activation is risky when it is paired with network access or shell execution because the user does not need to trigger the action and may not realise the extension is active.

What's in the full article

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

• Static indicators of compromise for the Remote Text Fetcher VS Code extension, including hashes and marketplace identifiers.
• The full commit timeline that shows how the malicious config namespace survived into the shipped VSIX.
• Behavioural detection cues for identifying hidden command-fetch-and-exec extension patterns in other developer tools.
• A comparison between the clean and malicious extension histories that helps reviewers distinguish cosmetic source sanitisation from real remediation.

👉 The full Knostic article covers the extension hashes, commit timeline, and runtime indicators.

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.