CVE-2026-112949 in Vitest
Summary
by MITRE • 10/20/2026
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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/20/2026
Vitest serves as a modern testing framework designed for Vite-native projects involving JavaScript and TypeScript codebases. While primarily intended to facilitate unit and integration testing, the underlying architecture relies on a development server that handles module resolution and source transformation dynamically during runtime. This dynamic nature introduces specific attack surfaces when interacting with external clients or plugins that can influence how modules are generated and served to the browser environment where tests execute.
A critical vulnerability exists within the interceptorPlugin component of Vitest versions ranging from 2.1.0-beta.7 through 4.1.12, as well as version 5.0.3 prior to its patching release. The flaw stems from an insufficient input validation mechanism when handling manual mock registrations initiated by unauthenticated non-browser WebSocket clients capable of reaching the development server. Specifically, the createManualModuleSource function accepts a url parameter provided by these external connections and inserts it directly into the generated module source code without proper escaping or sanitization. This lack of encoding allows for arbitrary data injection into the JavaScript context that will be executed in the developer's browser.
The operational impact of this vulnerability is significant because it leads to Cross-Site Scripting within the development environment. When a developer loads an affected module, the attacker-controlled payload embedded via the unescaped url executes on the origin of the Vitest development server. Although this occurs during local development and typically involves trusted developers, the execution context retains full privileges associated with that domain. This can result in session hijacking if cookies or authentication tokens are stored locally for the dev server, data exfiltration from other tabs sharing the same origin, or further exploitation of internal tools accessible via localhost. The attack vector is classified as a client-side injection resulting from improper neutralization of special elements used in an output web page context.
From a classification perspective, this vulnerability aligns with CWE-79, which describes Improper Neutralization of Input During Web Page Generation commonly known as Cross-site Scripting. Furthermore, the exploitation technique maps to MITRE ATT&CK techniques related to Client-side Injection and potentially Command and Control if used for persistent access within local networks during development workflows. The vulnerability highlights risks associated with allowing unauthenticated network connections to influence code generation in tools that operate at high privilege levels relative to user data.
Mitigation strategies primarily involve upgrading the Vitest framework to patched versions 4.1.12 or 5.0.3, where this input validation flaw has been resolved by properly escaping or validating inputs before insertion into module sources. For environments unable to upgrade immediately, restricting network access to the Vite development server is recommended. This can be achieved by binding the server strictly to localhost and ensuring no firewall rules permit external non-browser WebSocket connections. Additionally, developers should avoid running Vitest with plugins that expose unauthenticated endpoints or enable manual mock registration from remote sources until patches are applied. Implementing strict Content Security Policy headers even in development environments can also mitigate some impacts of script execution by restricting source loading origins.