Security researchers are increasingly citing Visual Studio Code as part of supply chain attacks on developers. Researchers at Jamf recently identified repositories that exploit the tasks.json configuration file.
By automatically executing tasks when opening a project folder, attackers can activate malicious code without being noticed, reports DevClass.
This is not a vulnerability in Visual Studio Code itself, but rather functionality that works as intended. The tasks.json file is designed to launch command line tools from within the editor and can automatically execute tasks as soon as a folder is opened. These configurations are usually located in the hidden .vscode folder and are easily shared when code is shared via platforms such as GitHub.
Microsoft has built in several protective measures. Folders are marked as untrusted by default, and tasks are only executed after a user explicitly grants trust. A warning also appears when code is started automatically. In practice, however, this protection appears to be of limited effectiveness. The dialog box visually emphasizes continuing after granting trust, while the warning text points out the risks. In addition, previously set trust rules can cause new subfolders to be automatically accepted.
Ease of use conflicts with security awareness
Researchers question these design choices. In daily practice, users often opt for speed, especially when the interface facilitates that behavior. In such a situation, it is difficult to place full responsibility on the user, as simply opening a project can be enough to activate hidden code.
The findings of Jamf Threat Labs illustrate how far this abuse can go. In the case investigated, a backdoor was installed via tasks.json that enabled remote code execution, mapped systems, and maintained a persistent connection to a command and control server. The tasks contained commands for macOS, Windows, and Linux and retrieved external JavaScript via curl. Because the payload was hosted externally, detection by security tools was more difficult.
Although the repository in question has since been removed, the risk remains. Malicious repositories are regularly distributed under the guise of job applications or technical assignments. Even without automatically executed tasks, opening such code can lead to problems.
Protection therefore remains complex. Thoroughly screening a repository is often unfeasible, especially for larger projects. Caution when working with third-party code therefore remains necessary. Increasingly, it is recommended to develop in isolated environments such as containers or temporary virtual machines, so that the impact of abuse is limited.