CVE-2026-120309

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.

W frameworku Nuxt przed wersją 4.6.0 niekompletna poprawka CVE-2026-53722 pozwala aplikacji z wyłączonymi stronami renderować URL zdolny do wykonania skryptu przez NuxtLink, gdy dane kontrolowane przez atakującego przekazane do atrybutu to są poprzedzone znakiem kontrolnym ASCII C0. Router bez stron klasyfikuje wartość jako trasę wewnętrzną przed wcześniejszym sprawdzeniem protokołu i przekazuje ją do href; przeglądarki usuwają wiodący znak kontrolny i interpretują pozostały URL javascript:. Problem naprawiono w wersji 4.6.0.

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.