CVE-2026-114130

Nuxt od wersji 4.6.0 przed 4.6.2 zawiera podatność mylenia parametrów trasy w getRouterParam i getRouterParams. Atakujący może zwrócić wartość parametru inną niż dopasowana przez h3, wysyłając ścieżki z zakodowanym znakiem zapytania (%3F), przez co kontrole autoryzacji używają wartości z helpera Nuxt, a wybór zasobu opiera się na event.context.params.

Nuxt przed wersją 3.3.1 w trybie deweloperskim udostępnia nieuwierzytelniony kanał RPC przez WebSocket Vite HMR. Atakujący, który może połączyć się z portem HMR, może wywołać metody takie jak updateOptions() i openInEditor(), co pozwala na wykonanie dowolnego programu na maszynie dewelopera.

W Nuxt w wersjach od 4.6.0 do 4.6.3 serwer deweloperski zapisuje wygenerowany appSecret w pliku <buildDir>/app-secret (domyślnie .nuxt/app-secret) w katalogu dostępnym przez konfigurację Vite server.fs. Klient z bezpośrednim dostępem HTTP do wystawionego serwera deweloperskiego może pobrać ten plik, użyć deriveSecret() do wyliczenia pochodnych sekretów (np. domyślnego hasła useSession) i sfałszować ciasteczka sesji akceptowane przez ten serwer. Domyślne wiązanie do localhost ogranicza ekspozycję zdalną, a buildy produkcyjne i serwery z jawnie skonfigurowanym appSecret nie są podatne. Problem naprawiono w wersji 4.6.3.

W Nuxt w wersjach od 4.6.0 do 4.6.3 framework rozwiązuje literalne lub procentowo zakodowane segmenty kropkowe przed wyrenderowaniem strony, podczas gdy routing Nitro, sprawdzenia server/middleware i reguły tras serwera oceniają ścieżkę nierozwiązaną. Żądanie takie jak /%2e/admin może wyrenderować app/pages/admin.vue wraz z danymi renderowanymi po stronie serwera, podczas gdy sprawdzenia kluczowane na /admin, przekierowania i nagłówki bezpieczeństwa per trasa nie zadziałają. Handlery API, appMiddleware, Nuxt 3 oraz Nuxt 4.0.0–4.5.x nie są podatne, a wykorzystanie wymaga klienta wysyłającego segmenty kropkowe bez normalizacji przeglądarki. Problem naprawiono w wersji 4.6.3.

W Nuxt w wersjach od 3.0.0 do 4.6.3 serwer deweloperski może ujawnić pakiet deweloperski Nitro 2 pod <buildDir>/dev/index.mjs poprzez serwowanie plików Vite, gdy serwer jest osiągalny przez HTTP. Nitro wstawia do tego pakietu prywatne wartości runtimeConfig rozwiązywane w czasie budowania, w tym sekrety skonfigurowane w nuxt.config, a Nuxt 4.6.0 i nowsze wstawiają także wygenerowany deweloperski appSecret. Domyślne wiązanie do localhost ogranicza ekspozycję zdalną, buildy produkcyjne i Nitro 3 nie są podatne, a konfiguracja dostarczana wyłącznie przez zmienne środowiskowe NUXT_* przy starcie serwera nie jest wstawiana. Problem naprawiono w wersji 4.6.3.

W Nuxt w wersjach od 4.6.0 do 4.6.3 klient z dostępem TCP do wystawionego serwera deweloperskiego może wysłać zdarzenie nuxt:dev:client-error przez gniazdo HMR z bezwzględną ścieżką pliku na końcu komunikatu. Serwer deweloperski odczytuje ten plik podczas budowania raportu błędu klienta i zwraca jego zawartość przez nakładkę błędu, kanał błędów deweloperskich i raport terminala, omijając listę dozwolonych Vite server.fs. Domyślne wiązanie do localhost ogranicza ekspozycję zdalną, żądania cross-origin z przeglądarki są odrzucane, buildy produkcyjne i Nuxt 3 nie są podatne, a interakcja z przeglądarką nie jest wymagana. Problem naprawiono w wersji 4.6.3.

Framework Nuxt w wersjach od 3.13.0 do 4.6.2 zawiera podatność polegającą na tym, że renderer server-island serializuje surowe dane wejściowe useHeadSafe bez zachowania znacznika bezpiecznego wejścia, a NuxtIsland wstawia je do nagłówka strony jako zwykły wpis. Aplikacja przekazująca dane kontrolowane przez atakującego do useHeadSafe w komponencie .server.vue lub renderowanym przez NuxtIsland może wyświetlić wartości normalnie usuwane przez listę dozwolonych, w tym atrybuty obsługi zdarzeń lub wykonywalną treść skryptu, co prowadzi do przechowywanego XSS w domenie aplikacji. Problem naprawiono w wersji 4.6.2.

W Nuxt przed wersją 4.6.2 strony są domyślnie rozwiązywane bez rozróżniania wielkości liter, podczas gdy Nitro dopasowuje klucze reguł tras po stronie serwera z rozróżnianiem wielkości liter. Żądanie różniące się tylko wielkością liter może zostać wyrenderowane bez zamierzonej reguły serwera, pomijając przekierowania, nagłówki, proxy, ssr: false i noScripts. Aplikacje ustawiające router.options.sensitive: true w nuxt.config nie są dotknięte.

Nuxt, framework do tworzenia aplikacji Vue.js, w wersjach od 3.11.0 do 3.21.4 i 4.4.4 porównuje klucze reguł tras z surową ścieżką żądania, podczas gdy rozwiązywanie tras dekoduje parametry dynamiczne i catch-all. Pozwala to segmentowi zakodowanemu procentowo na rozwiązanie do chronionej strony bez dopasowania wpisu routeRules przeznaczonego dla tej ścieżki, w wyniku czego appMiddleware może zostać pominięty podczas renderowania po stronie serwera, a nieuwierzytelniony żądający może otrzymać chronioną stronę i jej dane SSR.

Podatność ujawniania informacji w Nuxt w wersjach od 4.4.7 do 4.5.1 oraz od 3.21.7 do 3.21.10. Punkt końcowy workspace Chrome DevTools w serwerze deweloperskim ufa nagłówkowi Host zamiast adresowi połączenia, co pozwala nieuwierzytelnionemu atakującemu w sieci LAN na odczyt ścieżki katalogu głównego projektu i identyfikatora UUID workspace.