A serious Visual Studio Code security issue could let attackers gain persistent access to a developer’s workstation with a single click inside a malicious project folder.

The attack abuses clickable links in VS Code’s source editor to bypass the protection expected from Workspace Trust. Workspace Trust is designed to protect users when they open code from an unknown source. When a folder is untrusted, VS Code enters Restricted Mode.

It should prevent risky actions, such as running tasks, debuggers, or terminal commands. The main idea is simple: merely opening an unknown repository should not execute attacker-controlled code.

However, Remedio researchers found a path that may allow a malicious project to trigger internal VS Code commands through a crafted command: link.

VS Code automatically detects URLs in files such as READMEs, comments, and Markdown documents. Users can often open those links with Ctrl+click. Normally, developers expect such links to open websites or documentation pages.

But VS Code also supports a special command: URLs. Instead of opening a browser, these links can invoke an internal editor command and pass arguments to it. VS Code has hundreds of built-in commands, while installed extensions can add more commands.

Malicious VS Code Project Enables One-Click Persistent Access

One command of concern is workbench.extensions.installExtension. According to VS Code’s command reference, the command can install an extension by using an extension identifier or a VSIX extension package URI.

The Workspace Trust prompt , the one question the whole feature rests on (source : remedio ) — The Workspace Trust prompt , the one question the whole feature rests on (source: Remedio)

An attacker could hide a command link behind harmless text such as “Install project dependencies” or “Set up this project.” If the victim Ctrl+clicks the link in a source file, the editor could be instructed to install a malicious VSIX package placed inside the project folder.

A VS Code extension is more than a configuration file. It can run JavaScript or TypeScript code with the permissions of the logged-in user. That means a malicious extension could access local files, source code, SSH keys, cloud credentials, browser-accessible tokens, or development tools.

The danger also extends beyond the initial click. Once installed, an extension can remain on the system and activate during future VS Code sessions.

A victim might close the malicious project, reboot the computer, and later open a trusted repository. Meanwhile, the attacker’s extension still loads in the background.

Result: calc.exe launched and a marker file written, while the workspace is still Restricted (source : remedio ) — Result: calc.exe launched and a marker file written, while the workspace is still Restricted (source: Remedio )

This makes the issue especially serious for developer workstations. Developers often hold access to private repositories, CI/CD systems, signing infrastructure, cloud accounts, and production secrets. Compromising one developer device can become the starting point for a larger software supply-chain incident.

Microsoft’s Workspace Trust documentation states that users may be prompted to trust the workspace or install the extension when installing extensions in Restricted Mode. Extensions that do not support Workspace Trust may be installed with limited functionality or disabled.

According to Remedio Research, the concern is that a crafted local VSIX extension can claim support for untrusted workspaces. If VS Code accepts this declaration without displaying a meaningful security warning, an attacker may be able to install the extension while the workspace remains untrusted.

The broader lesson is to apply a security boundary consistently. Blocking dangerous command links in a rendered Markdown preview is not enough if the same link can still execute through the raw source editor.

The attacker's extension now sits in the Installed list, looking ordinary (source : remedio ) — The attacker’s extension now sits in the Installed list, looking ordinary (source : Remedio )

Developers should avoid clicking links inside unfamiliar repositories, especially links that claim to install dependencies, configure environments, or launch project setup actions. Users should also keep Workspace Trust enabled and review installed extensions regularly.

A practical mitigation is to turn off clickable links in the editor through the following user setting: json "editor.links": false.

This setting prevents VS Code from automatically detecting and opening links directly from the source editor, removing the click path used by the reported technique. The setting is documented in VS Code’s default configuration as controlling whether the editor detects links and makes them clickable.

Organizations should also restrict extension installation through centralized policy and allow only approved publishers or extensions. Until Microsoft fully addresses command-link handling across all editor surfaces, developers should treat links in untrusted code repositories as potentially hostile.

Cut every SOC alert investigation by 21 min. Power your SOC with instant IOC context for immediate response: Integrate TI Lookup in your SOC

The post One Click in a Malicious VS Code Project Can Give Attackers Persistent Access to Your PC appeared first on Cyber Security News.