CVE-2026-112949

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 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.

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.