Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
2 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact Turborepo's self-hosted login and SSO browser flows did not validate a CSRF state value on the localhost callback. While the CLI was waiting for authentication, a malicious web page could send a request to the local callback server with an attacker-controlled token. If accepted before the legitimate callback, the CLI could complete login with the wrong credentials. This affects users authenticating the turbo CLI against self-hosted remote cache/auth endpoints. Vercel-hosted login flows using device authorization are not affected. Fix The login and SSO redirect flows now generate a random state value, include it in the browser authentication URL, and require the same value on the localhost callback before accepting a token. Callbacks with a missing or mismatched state are rejected. Workarounds If you cannot upgrade immediately, avoid browser-based self-hosted turbo login or SSO flows on machines that may load untrusted web content during authentication. Use a pre-provisioned…
Recommended action: Upgrade to 2.9.14 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Turborepo can be vulnerable to arbitrary code execution when run in untrusted repositories that contain malicious Yarn configuration. In affected versions, package manager detection executed yarn --version from the project directory, which could cause Yarn to load and execute a project-controlled yarnPath from .yarnrc.yml. An attacker who controls repository contents could cause code execution when a user or CI system runs affected turbo, @turbo/codemod, or @turbo/workspace conversion commands. Fix Turbo now avoids executing project-local Yarn during package manager detection. Yarn versions and paths are inferred from metadata such as package.json, parsing the value of yarnPath in .yarnrc.yml rather than executing it, and yarn.lock, and unrecognized Yarn lockfile formats are rejected instead of falling back to executing yarn. Workarounds If you cannot upgrade immediately, do not run Turborepo commands in untrusted repositories. Review or remove .yarnrc.yml files that define…
Recommended action: Upgrade to 2.9.14 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.