VS Code extension flaws turn a Markdown preview into supply-chain risk

At a glance

What this is: NHI Mgmt Group's analysis, drawing on ProjectDiscovery's report: A 9.5 million-install VS Code extension turned preview content, workspace files, and webview messaging into a chain that could reach arbitrary file write and OS command execution.

Why it matters: Security and IAM teams should treat developer extensions as part of the software supply chain, because a trusted editor context can become a path to source, keys, signing material, and publishing credentials.

By the numbers:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.

Context

A code editor extension is software that runs inside the developer's workflow and inherits access to local files, secrets, and publishing paths. When that extension previews untrusted content, every parse, renderer, and message bridge becomes part of the trust boundary, especially in environments where source code and deployment credentials sit on the same machine.

This case sits squarely in software supply-chain risk because the vulnerable component was not a library buried in a build pipeline but an extension installed into the development environment itself. A single workspace file, preview interaction, or injected HTML fragment could reach host-level capabilities, which is atypical for a preview feature and highly relevant to teams that govern developer tooling.

Key questions

Q: How should teams govern VS Code extensions that render untrusted content?

A: Treat extension webviews as untrusted rendering surfaces and make all inbound messages pass through allowlisted message handling. The extension host should validate message type, origin, and parameters before any command, file write, or state change, and the webview should use strict content sanitisation, a tight Content Security Policy, and no direct access to privileged APIs.

Q: Why can a workspace configuration file lead to code execution?

A: A workspace configuration file can trigger code execution when the extension host reads settings and uses them to launch commands, load tasks, or alter runtime behaviour. If those settings are not tightly parsed and restricted, attacker-controlled values can reach the host process and turn configuration into an execution path.

Q: What is the difference between webview XSS and host command execution?

A: Webview XSS is script execution inside the embedded page, while host command execution is privileged code running in the extension host process. The message bridge is the channel between them, so any unsafe bridge that trusts webview input can turn a browser-side injection into file access, command dispatch, or other host actions.

Q: What should teams do first when an extension can write arbitrary files?

A: First, stop the extension from writing outside a narrow, pre-approved path set and review every file-write primitive that reaches arbitrary files. Then constrain filename, extension, and destination checks, because arbitrary writes can overwrite settings, scripts, or other executable content and become a code execution route.

Technical breakdown

How webview preview execution becomes host access

VS Code webviews are meant to isolate rendered content from the extension host, but that isolation only holds if message handling stays untrusted end to end. In this case, attacker-controlled content executed inside the preview and then used the extension's message bridge to reach command dispatch on the host. Once the host treated the message as trusted, the webview stopped being a display layer and became an execution path. That pattern matters because many editor extensions combine preview rendering, command routing, and file sync in one process.

Practical implication: Treat every webview message as hostile input and constrain it to an explicit allowlist.

Why workspace config files can become code execution

The extension loaded workspace-local configuration files and evaluated them inside the host process. That is dangerous because in-process JavaScript evaluators share prototype chains and runtime objects with the host, so sandboxing claims collapse if the evaluator can reach host constructors. A config file is not just settings data when it is parsed with a real JavaScript engine. In developer tooling, that turns a convenient customization mechanism into an executable trust boundary.

Practical implication: Run untrusted workspace code in a separate engine or process that cannot reach host objects.

How arbitrary file write turns a preview bug into persistence

Arbitrary file write is often dismissed as less severe than direct code execution, but on a developer workstation it is frequently enough to gain durable access. If a preview channel can write to shell startup files, Git hooks, SSH configuration, or build metadata, the attacker can pivot into code execution the next time the system trusts those files. That is why file-write primitives in editor extensions are supply-chain issues, not just local integrity issues. See the SaaS-to-SaaS and OAuth App Governance Guide.

Practical implication: Restrict file writes to known workspace targets and validate the exact file type before saving.

Threat narrative

Attacker objective: The attacker aims to gain durable code execution on a developer machine and pivot into source repositories, secrets, and software publishing paths.

1. Entry began when a crafted Markdown file or workspace-supplied HTML reached the preview path and executed inside the webview.
2. Credentialed access expanded when webview messaging and in-process evaluation exposed host capabilities that should have remained isolated.
3. Escalation followed when attacker-controlled commands or config execution reached the extension host and host filesystem.
4. Impact was arbitrary file write and OS command execution under the developer's privileges, creating a path to source control and publishing compromise.

Breaches seen in the wild

• 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.
• Amazon Q Developer extension compromise 2025: An over-scoped CI token let an attacker ship a prompt telling Amazon Q's AI coding agent to wipe files and AWS resources (CVE-2025-8217).

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

Editor extensions now belong in the software supply chain threat model: a popular preview extension was able to translate untrusted content into host actions because it sat inside the same environment that holds source code and credentials. That is a governance problem, not just a product bug, because developer tooling has become part of the production trust boundary. Teams that ignore extension risk leave a blind spot between code review and build output.

Message bridges are the new privilege boundary in rich previews: the risky moment was not the rendering alone, but the point where webview messages were forwarded into command dispatch without a hard allowlist. That pattern should be treated as a distinct control failure, because an attacker who reaches the message bus can often move from UI compromise to host privilege without any separate exploit chain. The right lens here is least privilege for internal extension commands.

Workspace-local files can act as executable policy when they are parsed as code: configuration and header files under the workspace were enough to trigger execution and webview compromise. That makes the governance assumption obvious: “user-editable” does not mean “safe to evaluate.” For developer platforms, the safer concept is workspace execution leakage: innocuous project files that unexpectedly cross into trusted runtime paths and inherit host privileges.

Arbitrary file write is a persistence primitive, not a minor follow-on: once an attacker can overwrite shell startup files, hooks, or build config, the machine becomes a launch point for later compromise. The extension's five CVEs show that preview bugs can cascade into software delivery risk even when the initial weakness looks like ordinary content handling. Practitioners should treat file-write containment as a core supply-chain control, not a cleanup task.

Supply-chain exposure in developer tools is broader than package integrity: the real issue is not only whether a dependency is signed or scanned, but whether a tool can be coerced into executing attacker-controlled state from the workspace. That widens the scope of control ownership across endpoint, engineering, and platform teams. The practical conclusion is to govern extensions, previews, and workspace inputs as one attack surface.

From our research library:

• Breaches involving third parties rose to 48% of all breaches, a 60% increase on the previous year, according to Verizon's 2026 Data Breach Investigations Report.
• Read next: AI Coding Agents Security Guide

What this signals

Developer tooling needs a new trust model: extensions that render untrusted workspace content should be governed like supply-chain components, because preview logic can become an execution path before the build even starts. The control question is no longer whether the editor is convenient, but whether its runtime can touch source, signing material, or publishing credentials without containment.

Workspace execution leakage: project-local files that look like configuration or header customisation can cross into trusted runtime if the extension evaluates them as code or injects them into the preview template. That means engineering teams need to treat workspace content as potentially executable state, not just user content, especially where the editor has access to repository secrets and automation tokens. Use CI/CD pipeline identity controls to keep those paths separate.

Preview file write and host command dispatch should be watched as a paired risk, because one creates persistence and the other creates immediate execution. When a developer tool can reach both, the likely impact is not just a broken preview but a compromised workstation that can alter source, credentials, or build artifacts.

For practitioners

• Harden webview message handling Allow only explicitly named commands from the webview bridge and reject all other message shapes, argument types, and URI schemes.
• Isolate workspace-supplied code Move any parser or config evaluator that accepts workspace content into a separate runtime that cannot reach host constructors or filesystem APIs.
• Contain preview file writes Pin write operations to the previewed workspace file, validate extensions, and block writes to shell, hook, and SSH paths.
• Sanitise workspace HTML before injection Strip script tags and event handlers from any workspace-local HTML that can reach the preview template before it enters the webview.
• Review extension risk in software intake Classify editor extensions that can render untrusted content or handle publishing credentials as supply-chain dependencies subject to explicit approval.

Key takeaways

• A high-install editor extension can become a supply-chain risk when preview content reaches host-level privileges through weak trust boundaries.
• The audit exposed five flaws across preview execution, workspace configuration, HTML injection, command dispatch, and file write.
• Containment around webview messages, workspace evaluation, and arbitrary file writes is what separates a preview bug from developer-machine compromise.

Related NHI Mgmt Group resources: AI Coding Agents Security Guide · CI/CD Pipeline Identity Security Guide · SaaS-to-SaaS and OAuth App Governance Guide · Secrets in VS Code extensions 2025

Key terms

• Supply Chain Risk: Supply chain risk is the chance that a weakness, failure, or compromise in an external supplier, partner, or upstream dependency will affect your organization. It includes software, hardware, cloud, data, and service dependencies, where trust, integrity, availability, or confidentiality can be disrupted through third-party access, updates, or operational failure.
• Vs Code Webview: A VS Code webview is an embedded browser panel inside Visual Studio Code used to display custom HTML, CSS and JavaScript. It is isolated from the editor UI and extension host, but it can exchange messages with the host and therefore needs strict content and message validation.
• Webview Message Bridge: A webview message bridge is the communication path between a VS Code webview and the extension host. It passes structured messages in both directions, so the bridge must validate message types, parameters and sender context before the host performs privileged actions.
• Workspace Configuration File: A workspace configuration file is a project-scoped settings file that tells an editor or IDE how to behave for that folder or repository. It can define tasks, tooling and other workspace-level options, so untrusted values may influence commands, paths or runtime behaviour.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security and platform teams align identity controls with the software delivery paths that depend on them.