Vitest UI API Path Traversal via Improper URL Normalization on Windows

Vulnerability Description

This is a path traversal vulnerability stemming from improper URL normalization in Vitest's API handlers. The root cause is the use of deprecated isFileServingAllowed() function that performs security validation on unsanitized URLs. Specifically, the function checks file paths before calling cleanUrl(), which means specially crafted URLs with backslash-prefixed query strings (e.g., \\?\\..\\) bypass the intended access controls. The vulnerability is Windows-specific because Windows path semantics treat \?\ as a special device path prefix that Linux systems reject outright as invalid directory names.

Proof-of-Concept Significance

The disclosed PoC is significant because it demonstrates a systematic validation-bypass pattern across multiple API endpoints in Vitest's codebase. The vulnerability requires one of two preconditions: (1) explicit network exposure via --api.host configuration, or (2) running Vitest UI/Browser Mode on Windows. The PoC proves that the isFileServingAllowed() function is fundamentally misused in five separate code locations, indicating a design-level issue rather than isolated bugs. This affects all versions prior to patching and is reliable on vulnerable Windows instances.

Detection Guidance

Defenders should monitor for:

• HTTP requests to Vitest API endpoints (/__vitest_attachment__, /api/) containing URL-encoded or literal backslash sequences (%5C, %3F, \?)
• Access logs showing requests with query parameters containing dot-dot-backslash patterns (..\, ..%5C)
• File access patterns on Vitest server hosts showing reads of files outside the project directory
• Process monitoring for Vitest processes with --api.host binding to non-localhost addresses
• EDR/SIEM rules targeting Windows path traversal indicators: (\?\|%5c%3f%5c) in HTTP request URIs

Mitigation Steps

Immediate actions:

1. Update Vitest to the patched version when available (monitor GitHub releases)
2. Network isolation: Do not expose Vitest UI servers to untrusted networks; bind api.host to 127.0.0.1 only
3. Windows users: Disable Vitest UI/Browser Mode if not actively used during development
4. Temporary workaround: Use Vitest in headless mode without UI server activation
5. Code review: Audit any custom Vitest plugins or extensions that implement file-serving APIs

Long-term: Adopt centralized URL normalization before all security checks; replace deprecated isFileServingAllowed() with secure implementations that normalize paths first, then validate against allowlists.

Risk Assessment

Likelihood: Moderate-to-high exploitation risk. This requires active network exposure or local access, limiting opportunistic attacks. However, Vitest is widely used in Node.js development workflows, and developers frequently run tests on Windows. Threat actor interest: Low-to-moderate. The vulnerability is useful for insider threats, supply chain attacks on CI/CD systems that run Vitest with network APIs, or local lateral movement scenarios. Detection is straightforward, reducing appeal for sophisticated attackers. In-the-wild exploitation: Unlikely at scale due to the specific preconditions, but targeted exploitation against development teams is plausible.