CVE-2026-112950

Vitest w wersjach od 5.0.0-beta.6 do 5.0.5 nieprawidłowo stosuje ustawienie server.fs.deny, ponieważ serwery projektowe zastępują domyślne ustawienia Vite, a serwer główny dodaje plik .vitest-secret-token po skompilowaniu matchera przez Vite. Atakujący z dostępem do interfejsu UI, trybu Browser Mode lub serwera API może odczytać zablokowane pliki projektu lub token API w node_modules/.vitest/.vitest-secret-token, a tryb Browser Mode z test.projects może ujawnić wartości .env przez złośliwą stronę.

Vitest w trybie przeglądarki (Browser Mode) przed wersjami 3.2.7, 4.1.10 i 5.0.0-beta.6 nie egzekwuje uprawnień zapisu (allowWrite) ani nie ogranicza ścieżek do katalogu projektu dla komend takich jak upload, takeScreenshot, screenshotMatcher, stopChunkTrace, deleteTracing i annotateTraces. Klient mający dostęp do API trybu przeglądarki może odczytać dowolne pliki lokalne, tworzyć lub nadpisywać pliki obrazów i śladów, a także usuwać pliki dostępne dla procesu Vitest, nawet gdy allowWrite jest ustawione na false. Problem został naprawiony w wersjach 3.2.7, 4.1.10 i 5.0.0-beta.6.

Podatność w Vitest w trybie przeglądarki (Browser Mode) pozwala zdalnemu atakującemu na ominięcie mechanizmów kontroli dostępu i wykonanie dowolnego kodu Node.js. Problem dotyczy interfejsu cdp(), który nie weryfikuje uprawnień allowWrite ani allowExec, umożliwiając manipulację plikiem konfiguracyjnym vite.config.ts.

Podatność w frameworku testowym Vitest na Windows pozwala na odczyt plików poza projektem przez path traversal w ścieżce /__vitest_attachment__ oraz na zdalne wykonanie kodu przez funkcje API saveTestFile i rerun. Problem został naprawiony w wersjach 3.2.5 i 4.1.0.

Podatność w Vitest w trybie przeglądarkowym pozwala na wstrzyknięcie kodu JavaScript poprzez parametr zapytania otelCarrier w ścieżce /__vitest_test__/. Atakujący może wykorzystać spreparowany adres URL do wykonania dowolnego kodu w kontekście serwera Vitest i odzyskać token API VITEST_API_TOKEN.

W Vitest od wersji 2.1.0-beta.7 do 4.1.12 i 5.0.3 nieuwierzytelniony klient WebSocket inny niż przeglądarka, który może dotrzeć do serwera deweloperskiego używającego interceptorPlugin, może zarejestrować ręczny mock, którego kontrolowany przez atakującego adres URL createManualModuleSource wstawia bez escapowania do wygenerowanego źródła modułu. Gdy przeglądarka dewelopera ładuje zaatakowany moduł, kontrolowany przez atakującego JavaScript wykonuje się w origin serwera deweloperskiego.

Vitest (framework testowy oparty na Vite) w wersjach od 2.1.0 do 4.1.11 oraz 5.0.0-rc.2 zawiera podatność w publicznych eksportach mockerPlugin i interceptorPlugin, które rejestrują procedurę vitest:interceptor:register na nieuwierzytelnionym WebSocket HMR Vite bez walidacji celów przekierowania względem listy dozwolonych plików. Zdalny klient, który może dotrzeć do wystawionego serwera deweloperskiego, może przesłać adres URL z zachowaniem segmentów .., co powoduje rozwiązanie ścieżki poza katalogiem projektu. Podatność umożliwia ujawnienie lokalnych plików czytelnych przez proces serwera deweloperskiego. Problem naprawiono w wersjach 4.1.11 i 5.0.0-rc.2.