CVE-2026-47429

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 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 4.1.11 do 4.1.12 i 5.0.3 funkcje isFileLoadingAllowed i odczyt systemu plików interpretują backslashe inaczej w systemie Windows w pliku packages/mocker/src/node/interceptorPlugin.ts. Gdy klient może dotrzeć do serwera deweloperskiego Vite w systemie Windows i zarejestrować mock przekierowania zawierający traversal z backslashem, łączenie POSIX zachowuje traversal z backslashem Windows, który późniejszy odczyt systemu plików interpretuje jako separator ścieżki, więc klient może odczytać plik poza server.fs.allow, do którego proces Vitest ma dostęp.

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.