Next.js 16.4.5: aktualizacja bezpieczeństwa, kogo dotyczy

Next.js 16.4.5 i 15.5.29, czyli listopadowa aktualizacja bezpieczeństwa z 2026 roku, łatają siedem luk, z czego cztery w use cache i Cache Components. Obie wersje trafiły do npm 3 listopada 2026, o 18:01 i 18:36 UTC, a tag latest wskazuje teraz 16.4.5. Na Next.js 16 uruchom npm install next@16.4.5, na 15 – npm install next@15.5.29. Dotyczy to także Next.js 16.4.4, wydania z poprawkami błędów z poprzedniego dnia, które żadnej z tych luk nie naprawia. 15.5.29 ma trzy poprawki: wstrzykiwanie odpowiedzi za proxy, obejście blokady SVG w optymalizacji obrazów i nagłówek z ciasteczkami w trasach Edge. Pozostałe cztery dotyczą tylko aplikacji 16.x z Cache Components lub use cache. Jeśli używasz Cache Components z root params, hostujesz sam przez next start, ustawiasz ciasteczka w trasach Edge albo optymalizujesz zdalne obrazy, zaktualizuj dziś, a my wyczyścilibyśmy też każdy cache, który przeżywa deploy. Każde twierdzenie poniżej sprawdziliśmy 4 listopada 2026 w advisories, wydaniach na GitHubie, rejestrze npm i na blogu Next.js. Żadnej z luk nie odtwarzaliśmy.

Co się zmieniło w Next.js 16.4.5 i 15.5.29

Noty wydania 16.4.5 (otwiera się w nowej karcie) wymieniają siedem advisories, a noty wydania 15.5.29 (otwiera się w nowej karcie) trzy z nich. W porównaniu 16.4.4 i 16.4.5 (otwiera się w nowej karcie) wydanie to osiem commitów: po jednej poprawce na advisory i podbicie wersji, bez innych zmian. Porównanie 15.5.28 i 15.5.29 (otwiera się w nowej karcie) dokłada do trzech poprawek trzy commity, które dotyczą tylko procesu wydań i CI samego Next.js. W rejestrze npm (otwiera się w nowej karcie) obie wersje mają te same zależności zewnętrzne, zakres peer dla Reacta i zakres Node.js co poprzednia łatka (>=20.9.0 w 16.4.5), a jedyną inną zmianą jest @next/env, przypięty do dokładnej wersji next, który przesuwa się razem z nim w lockfile.

Każde advisory ma na GitHubie poziom zagrożenia, wynik CVSS 4.0 i identyfikator CVE; odczytaliśmy je 4 listopada przez API advisories GitHuba (otwiera się w nowej karcie). Wpis Next.js (otwiera się w nowej karcie) podaje własną ocenę i żadnego CVE:

Root param to parametr trasy w root layoucie, na przykład [locale] albo [tenant] w app/[tenant]/layout.tsx, odczytywany przez next/root-params. Według advisories wpis use cache powinien zależeć od każdego root param, który odczytuje jego funkcja, obok argumentów, z których use cache buduje klucz wpisu. Dwa z czterech błędów cache gubią root param z klucza, więc aplikacja, która rozdziela najemców, serwisy albo języki przez root param, może podać zbuforowane dane jednego najemcy drugiemu.

Czy listopadowe luki są wysokie czy średnie?

Jedno i drugie, zależnie od źródła. Zapowiedź z 27 października (otwiera się w nowej karcie) mówiła o „seven medium vulnerabilities”. Wpis z 3 listopada nazywa wyciek przez unstable_cache lukę High, a pozostałe sześć Medium. Advisories na GitHubie i obie noty wydania dają wszystkim siedmiu Moderate. Wyniki leżą blisko siebie: sześć advisories ma od 6,0 do 6,3, a obejście SVG ma 6,9, najwięcej, jako jedyne z wektorem CVSS bez wymagań ataku (AT:N) przy niskiej złożoności i bez udziału użytkownika. Jeśli śledzisz wyciek przez unstable_cache, zapisz ocenę High, bo wyciek między najemcami to poważna sprawa dla aplikacji multi-tenant, niezależnie od wyniku.

Kogo dotyczą luki Next.js z listopada 2026

Każde advisory wymaga konkretnej konfiguracji. Znajdź swoją w lewej kolumnie; warunki pochodzą z advisories i wpisu Next.js.

Wpis Next.js zawęża dwie z nich. Wyciek ciasteczek w Edge nie odtworzył się w route handlerach Node.js ani przy cookies().set(). Wymaga też, by na twoim originie działał już JavaScript atakującego, więc nie jest sposobem na uruchomienie skryptu. Wstrzykiwanie odpowiedzi wymaga opisanego zachowania proxy z pipeliningiem i nie dotyczy każdego reverse proxy. Trzy advisories (zatrucie powłoki, wstrzykiwanie odpowiedzi i obejście SVG) opisują wyłącznie self-hosting. Wpis w changelogu Netlify o lukach Next.js (otwiera się w nowej karcie), zaktualizowany 4 listopada, wymienia cztery z siedmiu jako dotyczące stron na Netlify i wydaje adapter @netlify/plugin-nextjs 5.16.6 na przypadek ciasteczek w Middleware.

Jak sprawdzić, czy twoja aplikacja używa podatnych wzorców

Z katalogu głównego projektu te polecenia znajdą konfiguracje z tabeli:

npx next --version                                      # poniżej 16.4.5 lub 15.5.29: aktualizuj
grep -rn "cacheComponents\|partialPrefetching" next.config.*
grep -rln "next/root-params" app src lib 2>/dev/null    # root params w kodzie z cache
grep -rln "unstable_cache" app src lib 2>/dev/null      # razem z "use cache": GHSA-mfr8
grep -rln "runtime = \"edge\"" app src pages 2>/dev/null # trasy Edge: szukaj cookies.set()

Przy ciasteczkach w Edge wyślij żądanie do trasy, która ustawia ciasteczko, i poszukaj wewnętrznego nagłówka w odpowiedzi. Po aktualizacji commit z poprawką (otwiera się w nowej karcie) usuwa go z odpowiedzi Edge:

curl -s -D - -o /dev/null https://your-app.example/api/login | grep -i x-middleware-set-cookie

Które wersje Next.js dostają poprawkę?

Tylko dwie linie LTS. Polityka wsparcia Next.js (otwiera się w nowej karcie) stawia 16.x w Active LTS, a 15.x w Maintenance LTS z aktualizacjami bezpieczeństwa do 31 stycznia 2027; 14.x i starsze nie są wspierane. W npm 3 listopada nie pojawiło się żadne wydanie 16.2.x ani 16.3.x: najnowsze to wciąż 16.2.12 (25 lipca) i 16.3.8 (30 września).

• Od 16.0 do 16.4.4: przejdź na 16.4.5. Nie ma backportu dla 16.2 ani 16.3, więc razem z łatką dostajesz aktualizację wersji minor. Przed przejściem przeczytaj noty wydania 16.4.4 (otwiera się w nowej karcie) i zmiany w 16.4.
• Od 15.0 do 15.5.28: przejdź na 15.5.29. Luki w cache nie dotyczą 15.x.
• 14.x i starsze: advisory o wstrzykiwaniu odpowiedzi ma w polu wersji jednocześnie >= 16.0.0 i < 16.0.0, co czytamy jako każdą wersję, a najnowsze 14.x w npm to wciąż 14.2.35 z grudnia 2025. Pozostałe sześć nie wymienia żadnej wersji poniżej 15.0.0. Advisory nie podaje obejścia, a 14.x nie dostaje łatki, więc wyjściem jest 15.5.29 albo 16.4.5. Pola z wersjami w samych advisories czytaj ostrożnie. 4 listopada większość z nich nie podawała żadnej wersji z poprawką. Advisory o zagnieżdżonym use cache wskazywało 16.4.2, czemu przeczą noty wydania 16.4.5, a trzy podawały 16.4.2 jako ostatnią podatną wersję, choć 16.4.3 i 16.4.4 nie mają żadnej poprawki bezpieczeństwa. Żadnego z siedmiu nie było jeszcze w globalnej GitHub Advisory Database (jej API zwracało 404 dla każdego), a Dependabot alarmuje tylko o advisories zweryfikowanych przez GitHuba (otwiera się w nowej karcie). Brak alertu Dependabota nie znaczy więc dziś, że masz łatkę. Kieruj się notami wydania: 16.4.5 i 15.5.29.

Jak zaktualizować Next.js do 16.4.5 lub 15.5.29

1. Sprawdź, którą wersję masz

   Uruchom npx next --version albo npm ls next. W monorepo sprawdź każdą aplikację: każda, która rozwiązuje się do wersji poniżej 16.4.5 na 16.x albo poniżej 15.5.29 na 15.x, wymaga aktualizacji.

2. Zainstaluj wersję z poprawkami

   Uruchom npm install next@16.4.5 na 16.x albo npm install next@15.5.29 na 15.x (pnpm add i yarn add działają tak samo). Node.js i zakres peer dla Reacta się nie zmieniają, więc react i react-dom zostają bez zmian.

3. Sprawdź, co rozwiązał lockfile

   Uruchom ponownie npm ls next i wdrażaj z czystej instalacji. Zakres z daszkiem, np. ^16.4.4 w package.json, bierze 16.4.5 dopiero po aktualizacji lockfile.

4. Wyczyść cache, który przeżywa deploy

   Wpisy zapisane przed poprawką zostają błędne także po niej: wyciek przez unstable_cache trwa, dopóki wpis nie zostanie zrewalidowany lub usunięty, a zatruta powłoka zachowuje swój błąd 404 po restartach. Advisories nie każą niczego czyścić; to nasza własna rada: jeśli używasz współdzielonego cache handlera albo trwałego wolumenu na cache, wyczyść go po aktualizacji. Na Netlify postępuj według jego changelogu: wyczyść branch deploys i Deploy Previews, których deploy produkcyjny nie czyści.

5. Obejścia stosuj tylko, dopóki nie możesz zaktualizować

   Advisory o unstable_cache podaje, że niewywoływanie funkcji use cache wewnątrz unstable_cache jest pełnym obejściem. Obejście dla powłoki to partialPrefetching: true w next.config. Pozostałe pięć nie podaje żadnego, więc zaktualizuj, gdy tylko możesz.

Na co uważać

• 16.4.4 nie ma łatki. Ukazało się dzień wcześniej i to wydanie z poprawkami błędów. Zgłoszenie bezpieczeństwa zamykaj dopiero na 16.4.5 albo 15.5.29.
• Komentarz przy instalacji mówi „16.5”. We wpisie Next.js linia npm install next@16.4.5 ma komentarz # for 16.5. Polecenie jest poprawne. 16.5 jest wciąż w canary (16.5.0-canary.40 w npm 4 listopada), więc nie szukaj wydania 16.5.
• Wpis o wydaniu nie linkuje advisory o powłoce. Opisuje zatrucie współdzielonej powłoki bez linku. GHSA-vvgp-ww4w-46vf jest w notach wydania 16.4.5.
• Brak doniesień o atakach. Żadne ze źródeł nie wspomina o wykorzystaniu luk w praktyce ani o publicznym proof of concept. Advisories są publiczne od 3 listopada, więc to nie powód, by czekać.
• Kiedy czytaliśmy źródła. Wpisy Next.js, oba wydania na GitHubie, siedem advisories, rejestr npm, politykę wsparcia i changelog Netlify – wszystko 4 listopada 2026. Nie uruchamialiśmy 16.4.5 na demo i nie odtwarzaliśmy żadnej luki.

Więcej informacji