Cloudanix VulnDB

CVE-2026-112949

Medium · 4.7

CVSS

4.7

EPSS

0.3%

Published

Oct 20, 2026

CISA due date

—

Cloudanix analysis

Monitor only SSVC: Track

A problem in a popular JavaScript testing tool could let someone run harmful code inside a developer's browser while the developer is testing their own project.

Exploitation
Requires User Interaction
Attacker needs
User Interaction
Complexity
Moderate
Impact
Data Exposure
Component
Application
Class
XSS
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

An unauthenticated WebSocket client can register a manual mock with an attacker-controlled URL that is inserted unescaped into generated module source, resulting in cross-site scripting execution within the development server origin when the module is loaded in the browser.

Why it matters to the business

Developers using affected versions for JavaScript or TypeScript projects face risk of code execution in their testing environment, potentially exposing source code, credentials, or local resources during routine development work six days after disclosure with a modest rise in exploitation probability.

How an attack unfolds

An attacker reaches the development server WebSocket endpoint and uses interceptorPlugin to register a manual mock containing a malicious URL; when a developer browser loads the affected module the unescaped payload executes JavaScript on the server origin.

How to fix it

Upgrade Vitest to version 4.1.12 or 5.0.3. If immediate upgrade is not possible, restrict WebSocket access to trusted clients and avoid exposing development servers to untrusted networks.

How to confirm the fix worked

Verify the installed Vitest version is 4.1.12 or newer; test that manual mocks containing URLs with special characters are properly escaped in generated module source.

Typical attack path

  1. Locate an exposed Vitest development server WebSocket endpoint
  2. Connect as a non-browser client and invoke interceptorPlugin
  3. Register a manual mock whose URL contains attacker-controlled JavaScript
  4. Wait for a developer to load the mocked module in the browser
  5. Execute payload on the development server origin

How to detect it

Review development server logs for unexpected WebSocket connections from non-browser clients and inspect manual mock registration events for URLs containing script tags or encoded payloads.

What your security team should do

  • Prioritize upgrade to 4.1.12 or 5.0.3 within the next sprint
  • Audit exposed development servers and apply network controls to limit WebSocket access
  • Monitor EPSS trend and re-evaluate risk if exploitation maturity increases

The record

Vitest is a Vite-native testing framework for JavaScript and TypeScript projects. From 2.1.0-beta.7 until 4.1.12 and 5.0.3, an unauthenticated non-browser WebSocket client that can reach a development server using interceptorPlugin can register a manual mock whose attacker-controlled url createManualModuleSource inserts unescaped into generated module source. When the developer browser loads the affected module, attacker-controlled JavaScript executes on the development-server origin. This issue is fixed in versions 4.1.12 and 5.0.3.

Affected packages

Ecosystem Package Introduced Fixed

Related vulnerabilities