@osbytesVercel shipped Turborepo v2.9.14 today. Under the CI and docs churn sits a blunt security note worth catching even if your monorepo never touches turbo on the CLI: the VS Code Turborepo / LSP extension carries fixes for multiple advisories, and the headline item is GHSA-5xc8-49mv-x4mm (CVE-2026-46508, rated High).
Where the hole actually lived
Upstream’s wording is sober. Older extension builds routed some daemon and task-runner work through string-shaped shell commands. Values that a repo can steer (workspace configuration, names of tasks surfaced from the codebase) fed into those strings. Activate the extension against a hostile clone, or run a task through the extension UI after those values loaded, and the host shell could interpret the payload as arbitrary commands running with whatever rights the VS Code process already has.
This is classic “IDE extension meets untrusted workspace” territory. The precondition is simpler than chasing a zero-day broker: convincing someone to open your repo locally plus enough interaction that the extension does its job.
What changed in practical terms
GitHub lists the patched band as >= 2.9.14000 for the Turborepo LSP package and summarizes the remediation as ditching brittle shell interpolation (execFile with explicit argv for daemon hooks, structured terminal launches for tasks), marking Turborepo executable knobs so machines, not workspaces, decide where binaries live, and shutting the extension down inside VS Code’s untrusted-workspace mode until the user explicitly trusts the folder.
If you cannot update yet, the advisory’s fallback is also simple: do not run the extension against repositories you do not trust, and avoid driving Turborepo tasks from the extension until you are on a fixed build.
The rest of the tag (fast)
The same release line also documents two Low issues: a login-callback hardening pass (GHSA-hcf7-66rw-9f5r) and a cleanup so Yarn Berry detection does not execute surprise project-local binaries (GHSA-3qcw-2rhx-2726). Worth skimming if you manage developer laptops, but the extension command path is the one that should interrupt dinner.
What to do on a team laptop
Update the Turborepo VS Code extension to the build that ships with >= 2.9.14000 (per the advisory's patched-versions field), then verify the Marketplace / Open VSX sidebar shows that version lineage. If you cannot update yet, the advisory's fallback is VS Code's untrusted-workspace mode — the patched extension now exits inside it; on older builds, treat any extension activation against an unfamiliar clone as the precondition the CVE needs.
Malicious repo input that reaches a shell inside VS Code predates Turborepo; this extension is catching up to the execution style hardened tools adopted after earlier wake-up calls in the same class of bug.
Sources
- Turborepo
v2.9.14release notes (GitHub, 2026-05-14) - GHSA-5xc8-49mv-x4mm / CVE-2026-46508 — Turborepo VSCode Extension command injection (published 2026-05-14)
- GHSA-hcf7-66rw-9f5r — Turborepo login callback CSRF/session fixation
- GHSA-3qcw-2rhx-2726 — Unexpected local code execution during Yarn Berry detection