Notifications
Clear all
Topic starter
09/07/2026 9:34 am
TL;DR: A malicious VS Code extension was discovered that silently reads an undeclared configuration key, fetches base64-encoded commands from a remote URL, and executes them on every startup, according to Knostic. The pattern shows how developer workstation trust can be broken by source and compiled artifact drift, not just by obvious malware.
NHIMG editorial — based on content published by Knostic: malicious VS Code extension startup execution analysis
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- Block startup activation with remote fetch plus exec Treat onStartupFinished handlers that call outbound HTTP and then child_process.exec as high-risk patterns.
- 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.
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.
👉 Read Knostic's analysis of the malicious VS Code extension startup execution chain →
VS Code extension startup execution: what IAM and security teams miss?
Explore further
09/07/2026 9:35 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Malicious VS Code extensions can execute commands at startup
