The vulnerability resides in Vitest’s interceptorPlugin during manual mock registration. An unauthenticated non‑browser WebSocket client that can connect to the development server may supply an arbitrary URL to createManualModuleSource. The framework fails to escape this URL before inserting it into a generated module source. Consequently, when the developer’s browser loads the affected module, the attacker’s JavaScript runs in the context of the development‑server origin. This code injection flaw corresponds to CWE‑94, is compounded by improper encoding (CWE‑116), lack of authentication (CWE‑306), and also represents a cross‑site scripting vulnerability (CWE‑79), allowing an attacker to execute arbitrary code within the browser environment that has the same privileges as the developer user.

Affected vendors are @vitest:mocker and vitest-dev:vitest. The security issue exists in all releases from 2.1.0‑beta.7 up through 4.1.12 and 5.0.3, inclusive. The vulnerability is fixed starting with Vitest version 4.1.12 and 5.0.3. Projects using older or unpatched versions of Vitest in a development environment are susceptible.

The CVSS v3.1 score of 4.7 indicates a moderate severity when viewed in isolation. The EPSS is not available, and the vulnerability is not currently listed in the CISA KEV catalog, suggesting no known exploit kits but not dismissing the risk. Likely exploitation requires the development server to be reachable over a WebSocket interface that permits unauthenticated clients. An attacker could craft a malicious URL, connect through a WebSocket, trigger the mock registration, and cause arbitrary JavaScript to execute when a developer loads the module in the browser. While this does not affect the production runtime, it presents a significant risk during development, especially if the dev server is exposed to untrusted networks.