CVE-2025-24964

What it actually does

The flaw allows arbitrary remote code execution through cross-site WebSocket hijacking when the Vitest API server is running. A malicious web page opened in a developer's browser can initiate WebSocket connections to the locally or network-accessible Vitest API server and issue API actions that should only be available to trusted tooling. Because the vulnerable server does not adequately validate the WebSocket origin or otherwise prevent cross-site browser access, attacker-controlled requests can reach privileged test-runner functionality and execute code with the privileges of the user running Vitest.

Why it matters to the business

Successful exploitation can compromise developer workstations or CI-like development environments, exposing source code, secrets, package publishing credentials, cloud credentials, SSH keys, and internal access tokens. Although EPSS is currently low and the issue is not listed in CISA KEV, the CVSS score is critical because exploitation can lead directly to code execution when a developer browses to a malicious site while the Vitest API server is listening. The operational risk is highest for engineering teams that run Vitest API/UI workflows on developer machines or shared development hosts.

How an attack unfolds

An attacker first prepares a malicious website containing JavaScript that attempts to open WebSocket connections to common local or reachable Vitest API server addresses and ports. The attacker then convinces a developer or build engineer to visit the page while a vulnerable Vitest API server is running. The browser is permitted to initiate the WebSocket request, and the vulnerable Vitest server accepts the cross-site connection instead of rejecting it based on the Origin header. The malicious page sends crafted API messages that trigger Vitest functionality capable of running attacker-influenced code or commands in the context of the local project. Code then executes as the operating-system user running Vitest, allowing the attacker to read project files, exfiltrate secrets, alter dependencies or tests, and potentially pivot using credentials available on the host.

How to fix it

Upgrade Vitest to a version that includes the upstream fix commit 017e1ee6c66179568b758b4d1e1796f551dc1366. Regenerate lockfiles and rebuild containers or developer images so transitive and pinned installations are updated. Where immediate upgrade is not possible, disable the Vitest API server/UI when not required, avoid browsing untrusted websites while the server is running, restrict access with local firewall rules, run Vitest in an isolated container or VM with minimal secrets, and avoid exposing the API server on shared, public, or routable interfaces. Treat binding to localhost as a risk reduction only, not a complete mitigation, because the attack is browser-mediated and can target local services.

How to confirm the fix worked

Confirm that installed Vitest code contains the fix commit 017e1ee6c66179568b758b4d1e1796f551dc1366 or a released package version incorporating that commit. Check package-lock.json, pnpm-lock.yaml, yarn.lock, bun.lockb, container images, and developer bootstrap scripts for vulnerable pinned Vitest versions or Git references. Start the Vitest API server in a controlled test environment and verify that WebSocket upgrade attempts with an untrusted Origin are rejected. Confirm the service is not listening on external interfaces unless explicitly required. Use dependency scanning and software composition analysis to detect remaining vulnerable Vitest installations across repositories and development images.

Typical attack path

1. Identify organizations or developers likely to use Vitest in JavaScript or TypeScript projects.
2. Host a malicious web page that attempts WebSocket connections to local or LAN-accessible Vitest API endpoints.
3. Lure a developer into opening the malicious page while the Vitest API server is listening.
4. Abuse missing or insufficient WebSocket Origin validation to establish a cross-site connection from the victim's browser to the Vitest API server.
5. Send crafted Vitest API messages that cause attacker-controlled code or commands to run in the local project context.
6. Use the resulting execution to access source code, environment variables, developer credentials, SSH keys, npm tokens, or cloud credentials.
7. Persist or pivot by modifying project files, package scripts, developer shell configuration, or using stolen credentials.

How to detect it

Look for evidence on developer workstations and shared development hosts where Vitest was running. Useful sources include EDR process telemetry, shell history, terminal scrollback, Node.js process ancestry, browser history, local firewall logs, Vitest/Vite debug logs if enabled, repository file modification history, package-manager logs, and credential-access audit logs. Focus on time windows where a Vitest API server process was active and a browser visited an untrusted or newly observed domain. Indicators include WebSocket upgrade attempts to local Vitest services with unexpected Origin headers, Node.js or Vitest spawning shells or network utilities, unexpected modifications to package.json or test files, new scripts added to project files, suspicious outbound connections shortly after Vitest activity, and access to credential files such as SSH keys, npm configuration, cloud credential files, or environment files. Because exploitation is initiated through the victim browser to a local service, perimeter proxy logs may not capture the WebSocket traffic; endpoint telemetry is usually more valuable.

• vitest
• node_modules/vitest
• vitest --api
• vitest --ui
• Upgrade: websocket
• Origin: http://
• Origin: https://
• Sec-WebSocket-Key:
• package.json
• package-lock.json
• pnpm-lock.yaml
• yarn.lock
• .npmrc
• .env
• ~/.ssh/id_rsa
• ~/.ssh/id_ed25519
• ~/.aws/credentials
• ~/.config/gcloud
• az login
• npm token
• node .*vitest
• vitest.*--api
• vitest.*--ui
• node.*sh -c
• node.*bash -c
• node.*powershell
• node.*curl
• node.*wget

What your security team should do

• Prioritize remediation for engineering workstations, shared development hosts, and CI environments where Vitest API/UI features are enabled.
• Upgrade Vitest everywhere to a build containing commit 017e1ee6c66179568b758b4d1e1796f551dc1366 and refresh all lockfiles and base images.
• Search source repositories and developer environment definitions for Vitest API/UI usage and network exposure patterns.
• Add controls that prevent development servers from listening on routable interfaces by default.
• Run developer tooling with reduced privileges and without long-lived cloud, source-control, package-registry, or production credentials in the environment.
• Hunt for suspicious child processes spawned by Node.js or Vitest, especially shell, network download, credential-access, or archive commands.
• Review developer credential use after suspected exposure and rotate tokens that may have been present in affected sessions.
• Educate developers not to browse untrusted websites while local development servers with privileged APIs are running.