VS Code Security Risk from Malicious Extensions and Remote Code Execution

Modern software engineering teams increasingly rely on Visual Studio (VS) Code as the primary development environment for cloud-native engineering, DevSecOps workflows, infrastructure-as-code (IaC), and AI-assisted development. Its widespread adoption has also made the platform an increasingly attractive target for threat actors. As organizations adopt AI coding assistants, remote development containers, and ephemeral cloud workspaces, the attack surface around developer tooling continues to expand significantly. This article explores how VS Code extensions can enable attacks such as remote code execution (RCE), credential theft, and broader supply chain compromise.

Key Takeaways

• Enterprises evaluating overall VS Code security posture must always treat extensions as executable third-party software operating inside privileged engineering environments.
• VS Code extensions often execute with extensive local privileges and frequently bypass traditional endpoint trust assumptions.
• Malicious or compromised extensions can facilitate RCE, credential theft, persistence, and lateral movement across enterprise environments.
• Developer workstations are high-value targets because they often maintain privileged access to CI/CD pipelines, Git repositories, and cloud infrastructure.
• Remote development features, including Dev Containers and SSH sessions, may shift an enterprise’s execution boundaries, but do not completely eliminate the attack exposure.

What makes VS Code Extensions an Appealing Target for Attackers

The following are some of the factors that contribute to VS Code extensions ultimately having a larger attack surface:

• Runtime environments: VS Code extensions are fundamentally JavaScript or TypeScript applications. This means they operate within the Electron and Node.js runtime environments, inheriting their capabilities. Unlike browser extensions constrained by strict sandboxing, VS Code extensions often inherit direct, unhindered access to local file systems, shell execution, and security features such as Git credentials and SSH keys. From a security architecture perspective, this effectively transforms VS Code extensions into privileged local applications, blurring the distinction between development tooling and locally trusted software.
• The enterprise blind spot: Many organizations maintain a variety of mature security controls for their production workloads, cloud infrastructure, endpoint hardening and identity governance. However, most developer tooling ecosystems remain comparatively under-governed in most environments. This creates a risky asymmetry within the development environment, as shown below:

Threat actors increasingly understand that compromising a single senior or platform engineer may provide access to a host of GitHub resources, including organization tokens, artifact registries, production Kubernetes credentials, and CI/CD secrets. This phenomenon explains why recent VS Code security vulnerabilities have attracted substantial attention from both offensive security researchers and enterprise defenders.

How Malicious VS Code Extensions Actually Execute Code on Your Machine

The execution model employed by VS extensions typically relies on activation events across an enterprise’s development environment. Once activated, most extensions can invoke Node.js APIs that can run shell commands, read and write files, exfiltrate data, and inject scripts. VS extensions can also establish outbound connections, extending the attack. Common execution techniques include the following;

• Post-install execution: Some malicious VS Code extensions execute payloads immediately after their installation. They achieve this using lifecycle hooks. Typical objectives of post-installation execution include credential harvesting, persistence establishment, and beaconing to command-and-control infrastructure.
• Workspace trust abuse: VS Code’s Workspace Trust model is generally designed to limit execution of untrusted projects. However, skilled attackers frequently exploit developer habituation and trust fatigue to gain unauthorized access. For example, many engineers and developers routinely approve trust prompts without performing proper validation, especially when operating within internal repositories. This enables attackers to weaponize tasks, launch configurations, and sometimes debug profiles.
  Enterprises evaluating the broader security implications of AI-assisted software development should also review Pluto Security’s article on vibe coding security:  https://pluto.security/blog/vibe-coding-security/. It examines how AI-generated code and autonomous development workflows introduce new security risks across modern development environments.
• Dependency chain injection: Because VS extensions frequently rely on npm packages, any compromise within the dependency chain can sometimes introduce malicious functionality indirectly. This phenomenon creates a layered supply chain exposure as depicted in the diagram below:

VS Code Extension

└── npm Dependency

└── Transitive Dependency

└── Malicious Package

A critical challenge here is that attack paths are often difficult to detect with traditional software inventory and asset management approaches.

Security teams concerned about AI-generated code and dependency-related risks should also review this article from Pluto Security: https://pluto.security/blog/ai-code-security-defenders/.

• Remote session abuse: Extensions operating within remote SSH sessions and Dev Containers may interact directly with Linux build servers, cloud workloads, Kubernetes nodes, and internal networks. As a result, an attacker no longer needs to compromise the production environment directly when the developer environment already maintains authenticated connectivity. In practice, this can lead to a successful attack.

Real-World VS Code Security Vulnerabilities and What They Exposed

Several recent incidents can help security teams understand how developer tooling can become an enterprise attack vector:

• Marketplace malware campaigns: Security researchers have identified malicious extensions disguised as AI coding assistants, productivity tools, and developer utilities.¹ Some of these campaigns included Clipboard theft, credential harvesting, and crypto-wallet targeting. One notable example involved malicious extensions that could capture screenshots and exfiltrate developer activity. Such incidents have underscored that the Integrated Development Environment (IDE) itself can serve as an endpoint surveillance platform.²
• Live server vulnerability and RCE Exposure: A recently disclosed vulnerability (CVE-2025-65717) in the widely used Live Server extension (more than 72 million installs) has demonstrated how insecure local services can expose RCE opportunities.³ The issue highlighted a broader systemic problem characterized by the following:
• • Extensions frequently embed lightweight web servers
  • Localhost trust assumptions are weak
  • Browser-to-localhost interactions can become exploitable
  • Developers frequently expose ports unintentionally during development in remote workflows

For security leaders and their teams, the above scenarios underscore that extension risk is not isolated to malicious intent. Oftentimes, even some legitimate extensions with insecure implementation patterns can create severe exposures across development environments. Recent Visual Studio Code vulnerabilities have shown that even trusted components of the ecosystem can unintentionally expand enterprise attack surfaces.

Remote Code Execution in Practice

Remote Code Execution (RCE) remains one of the highest impact risk scenarios associated with extension compromise in enterprise environments. In practice, RCE through VS Code environments typically follows one of several operational paths as explained below.

Scenario 1: Malicious Extension Installation

• Developer installs extension.
• Extension activates silently.
• Payload downloads secondary malware.
• Attacker establishes persistence.
• Credentials and repositories are exfiltrated.

Scenario 2: Repository-Based Triggering

• Engineer clones attacker-controlled repository.
• Workspace includes malicious tasks or recommendations.
• Developer approves trust prompt.
• Arbitrary shell commands execute locally.

Scenario 3: CI/CD Pivoting

• Developer workstation compromised.
• GitHub or GitLab tokens extracted.
• Attacker modifies pipelines.
• Malicious packages are distributed downstream.

The above scenarios enable attackers to transition from isolated endpoint compromise to broader supply chain compromise with relative ease. This is one of the critical aspects that elevates developer tooling threats into board-level risk territory and therefore requires urgent attention from security leadership teams.

Frequently Asked Questions (FAQs)

1. Can a compromised extension spread to other machines on the same network?

Yes. A compromised extension can easily facilitate lateral movement across the entire enterprise environment if the affected workstation has access to shared credentials, SSH trust relationships, or mounted filesystems. This can also happen through orchestration tooling. Attackers frequently pivot through developer environments into CI/CD systems, Git repositories, Kubernetes clusters, and remote infrastructure using harvested authentication artifacts.

2. How do Visual Studio Code vulnerabilities affect CI/CD pipelines and build servers?

VS Code vulnerabilities affect CI/CD pipelines and build servers because developer environments commonly store pipeline tokens, deployment secrets, and repository credentials. This means that if attackers compromise a particular workstation through extension abuse or remote execution, they can modify build definitions, inject malicious dependencies, and tamper with artifacts. They can also establish persistence within CI/CD infrastructure and software supply chains.

3. Is VS Code security different inside a Dev Container or a remote SSH session?

Yes. In many developer environments, remote development models shift execution boundaries but do not eliminate risk. This means that extensions may continue to interact with remote hosts, containers, forwarded ports, credentials, and mounted volumes. As a result, a malicious extension operating within an SSH session or Dev Container can directly compromise all connected infrastructure environments.

4. Can a malicious VS Code extension steal data while the editor is idle?

Absolutely. VS Code extensions can run background processes independently of active coding sessions. This allows any malicious functionality to monitor filesystem activity, capture clipboard contents, exfiltrate environment variables, and harvest tokens. In this way, VS Code extensions establish periodic outbound communication even when the editor appears inactive to the user, leading to data theft incidents.

Conclusion

VS Code’s extensibility model provides exceptional productivity benefits but also introduces substantial trust and execution risks. Many enterprises still underestimate the risks involved. For CISOs, platform engineering leaders, and security architects, the conversation is no longer about whether extensions are useful but about how much implicit trust the organization currently grants to executable third-party code in privileged engineering environments. Addressing these requires moving beyond endpoint-centric thinking to a developer-infrastructure security model that treats IDE ecosystems as critical enterprise attack surfaces, as explained in this article.

Useful References

1. Koi Security. (2025). The VS Code malware that captures your screen.
   https://www.koi.ai/blog/the-vs-code-malware-that-captures-your-screen
2. National Institute of Standards and Technology. (2025). CVE-2025-65717 detail. National Vulnerability Database.
   https://nvd.nist.gov/vuln/detail/CVE-2025-65717
3. OX Security. (2025). Live Server VS Code extension allows remote exfiltration of local files.
   https://www.ox.security/blog/cve-2025-65717-live-server-vscode-vulnerability/
4. The Hacker News. (2026). Critical flaws found in VS Code extensions expose developers to attacks.
   https://thehackernews.com/2026/02/critical-flaws-found-in-four-vs-code.html
5. Vigliarolo, B. (2025). Flaws in popular VS Code extensions expose developers to attacks. BleepingComputer.
   https://www.bleepingcomputer.com/news/security/flaws-in-popular-vscode-extensions-expose-developers-to-attacks/