Malicious VS Code Projects Enable One-Click Persistent Access via Command URIs
A vulnerability in Visual Studio Code allows attackers to trick developers into installing malicious extensions with a single click, bypassing Workspace Trust protections and granting persistent system access.
A critical security flaw discovered in Visual Studio Code (VS Code) enables attackers to gain persistent access to developer workstations by embedding malicious links within project files. This vulnerability bypasses the Workspace Trust feature, which is designed to protect users from untrusted code sources.
Workspace Trust normally restricts VS Code's functionality when an unknown or untrusted folder is opened, entering a 'Restricted Mode' that prevents risky actions like running tasks or terminal commands. The intention is to ensure that simply opening a repository does not lead to the execution of malicious code. However, researchers from Remedio have identified a method where a crafted command: URI within a source file can trigger internal VS Code commands, circumventing these protections.
VS Code automatically detects URLs in various file types, including READMEs and comments, allowing users to open them with a simple Ctrl+click. While typically used for web links, VS Code also supports special command: URIs. These URIs, instead of opening a browser, can invoke specific internal editor commands and pass arguments. The vulnerability lies in the workbench.extensions.installExtension command, which can install extensions using an identifier or a VSIX package URI.
Attackers can disguise these malicious links behind seemingly innocuous text, such as "Install project dependencies" or "Set up this project." When a developer Ctrl+clicks such a link within a malicious project file, VS Code can be instructed to install a malicious VSIX extension package that is hosted locally within the project folder. This malicious extension, once installed, can execute arbitrary JavaScript or TypeScript code with the logged-in user's privileges.
The implications of a compromised developer workstation are severe. Such an extension can access sensitive data like source code, private repositories, SSH keys, cloud credentials, and development tools. Furthermore, the malicious extension can persist on the system, continuing to run in the background even after the user closes the malicious project or reboots their machine, posing a significant risk for supply-chain attacks.
Microsoft's Workspace Trust documentation suggests that users might be prompted before installing extensions in Restricted Mode. However, the Remedio research indicates that a crafted local VSIX extension can potentially claim support for untrusted workspaces without triggering a meaningful security warning, allowing installation even when the workspace remains untrusted.
To mitigate this risk, developers are advised to exercise extreme caution when clicking links within unfamiliar code repositories, particularly those related to project setup or dependency installation. Enabling Workspace Trust and regularly reviewing installed extensions are crucial steps. A practical workaround is to disable clickable links in the editor by setting "editor.links": false in the VS Code user settings, which prevents the editor from automatically detecting and opening links from source files.
Organizations should also enforce policies to restrict extension installations, allowing only approved publishers or extensions. Until Microsoft fully addresses the handling of command: URIs across all editor surfaces, developers must treat any links within untrusted code repositories as potentially hostile, recognizing that a single click can lead to persistent system compromise.