Next.js 16.4.4: aktualizacja bez poprawek bezpieczeństwa

Next.js 16.4.4, wydany 2 listopada 2026 i 3 listopada oznaczony w npm jako latest, to aktualizacja z poprawkami błędów, a nie wydanie bezpieczeństwa. Jego informacje o wydaniu (otwiera się w nowej karcie) wymieniają siedem zmian przeniesionych z canary, żadnej poprawki bezpieczeństwa, i zapowiadają listopadowe wydanie bezpieczeństwa na następny dzień. Na produkcji liczą się dwie poprawki: buildy Turbopacka z linii 16.4 mogły uruchamiać zminifikowany kod serwera bez trybu strict, a skrypt Turbopacka wstawiany do HTML gubił nonce CSP przy wznowieniu Partial Prerendering. Informacje o wydaniu nie wymieniają żadnej zmiany niekompatybilnej, a wpis w npm ma te same zależności, zakres React i zakres Node.js co 16.4.3. Co zrobić: weź 16.4.4 jak zwykłą łatkę, jeśli budujesz Turbopackiem albo wysyłasz nonce CSP razem z PPR, a potem zaktualizuj jeszcze raz, do wersji wskazanej w listopadowych advisories. Jeśli wciąż masz wersję poniżej 16.4.1, zaktualizuj dziś ze względu na krytyczne poprawki RCE z października. Każde twierdzenie poniżej sprawdziliśmy 3 listopada 2026 w GitHubie, rejestrze npm i na blogu Next.js; nie uruchamialiśmy 16.4.4 na demo.

Co się zmieniło w Next.js 16.4.4

To przeniesienie poprawek z canary do aktywnej gałęzi LTS, tak jak 16.4.3 z lżejszym proxy.ts dziesięć dni wcześniej. Każda pozycja prowadzi do pull requesta do releases/lts/active; 3 listopada otworzyliśmy każdy z nich:

Zmiana w 16.4.4	Co naprawia	Kto to zauważy
Revert "Optimize strict module factory chunks" (otwiera się w nowej karcie)	Zminifikowany kod serwera w buildzie produkcyjnym działał bez trybu strict	Buildy produkcyjne z Turbopackiem
Skrypt startowy shared runtime przy wznowieniu PPR (otwiera się w nowej karcie)	Skrypt startowy Turbopacka dostaje nonce CSP, gdy prerenderowana strona się wznawia	Turbopack, Partial Prerendering i CSP z nonce
Przeładowanie po przegapionej zmianie CSS przy starcie (otwiera się w nowej karcie)	Zmiana CSS sprzed połączenia przeglądarki z HMR nie zostawia starych stylów: strona się przeładowuje	next dev z Turbopackiem
Podsumowania tras jako indeks tras analizatora (otwiera się w nowej karcie)	Generowane trasy metadanych eksportują się w analizatorze poprawnie	Zespoły, które używają analizatora paczek z 16.4
fast-jwt zamiast jsonwebtoken (otwiera się w nowej karcie)	jsonwebtoken wciąż używa SlowBuffer, którego Node.js 26 już nie ma	Preview Mode w Pages Routerze
Testy wdrożeń przypięte do Node.js 22.x (otwiera się w nowej karcie)	CI samego Next.js	Nikt poza repozytorium Next.js
Wyłączony jeden test wdrożeniowy (otwiera się w nowej karcie)	Testy samego Next.js	Nikt poza repozytorium Next.js

Tryb strict w buildach produkcyjnych Turbopacka

To poprawka, na której warto się skupić. Pull request z revertem wyjaśnia, że pierwotna optymalizacja przeniosła "use strict" z każdej fabryki modułu do jednego wrappera na cały chunk, co odsłoniło błąd minifikatora SWC: funkcja mogła po cichu stracić tryb strict w buildzie produkcyjnym. Canary naprawił to nowszym SWC; gałąź LTS zamiast tego wycofuje optymalizację, więc każda fabryka znów dostaje własne "use strict". Zgłoszenie #100617 (otwiera się w nowej karcie), opisane na 16.4.2 i zatytułowane „since 16.4”, pokazuje skutek: po next build i next start this w zwykłym wywołaniu funkcji było globalThis zamiast undefined, a next dev i 16.3.1 działały poprawnie. Biblioteka, która na tej różnicy polega, przestała działać; u zgłaszającego był to klient AMQP rhea, który padał z this.container.get_option is not a function. Zgłaszający obchodził problem, wyłączając experimental.serverMinification albo dopisując pakiet do serverExternalPackages. Na 16.4.4 oba obejścia możesz usunąć.

Nonce CSP przy wznowieniu PPR

Przy Partial Prerendering (PPR) Next.js wysyła prerenderowaną statyczną powłokę strony, a potem wznawia renderowanie jej dynamicznych części. Content Security Policy oparta na nonce daje każdej odpowiedzi losową wartość, którą musi nieść każdy skrypt osadzony w HTML, inaczej przeglądarka go blokuje. Pull request, czysty cherry-pick #100102 z canary, włącza skrypt startowy shared runtime Turbopacka do wznowienia, więc dostaje on nonce. Jeśli wysyłasz nonce z proxy.ts i widziałeś zablokowane skrypty na stronach z PPR zbudowanych Turbopackiem, to jest ta poprawka.

fast-jwt dla ciasteczek Preview Mode

Pierwotny pull request (otwiera się w nowej karcie) podaje powód: jsonwebtoken wciąż używa SlowBuffer, a Node.js 26 go usunął. W Next.js ta biblioteka podpisuje i weryfikuje ciasteczko Preview Mode w Pages Routerze (res.setPreviewData). W diffie nowy kod podpisuje i weryfikuje je algorytmem HS256 i twoim kluczem podpisu podglądu, a maxAge przelicza z sekund na milisekundy, których oczekuje fast-jwt. Biblioteka jest wkompilowana w paczkę: rejestr npm (otwiera się w nowej karcie) podaje te same sześć zależności dla 16.4.3 i 16.4.4, więc w lockfile nic nowego się nie pojawi.

Czy Next.js 16.4.4 to aktualizacja bezpieczeństwa?

Nie i to najważniejsza informacja przy planowaniu tygodnia. Informacje o wydaniu zaczynają się od notki, że wydanie przenosi poprawki błędów, a zapowiedziane listopadowe wydanie bezpieczeństwa ukaże się następnego dnia. Żaden z dziesięciu advisories na pierwszej stronie listy advisories Next.js (otwiera się w nowej karcie) nie wskazuje 16.4.4; najnowsze są z 14 października 2026. Tak 16.4.4 wypada na tle linii 16.4, z czasami publikacji w npm:

Wersja	W npm (UTC)	Co to jest	Poprawki bezpieczeństwa
16.4.0	6 paź 2026, 18:35	Wydanie minor	Brak; podatna na advisories z października
16.4.1	14 paź 2026, 17:43	Nadzwyczajna aktualizacja bezpieczeństwa	Trzy advisories, dwa krytyczne
16.4.2	15 paź 2026, 20:57	Łatka z przeniesionymi poprawkami	Brak
16.4.3	23 paź 2026, 13:40	Łatka z przeniesionymi poprawkami	Brak
16.4.4	2 lis 2026, 10:49	Łatka z przeniesionymi poprawkami, latest 3 lis	Brak
Listopadowe wydanie bezpieczeństwa	Zaplanowane na 3 lis 2026	Siedem podatności o średniej wadze	Wersje nieogłoszone w chwili sprawdzenia

Zapowiedź z 27 października (otwiera się w nowej karcie) podaje datę i liczbę podatności, mówi, że pełne advisories ukażą się razem z wydaniem, z opisem wpływu, wersjami podatnymi i instrukcją aktualizacji, i zaleca przejście na wersję z poprawkami, gdy tylko będzie dostępna. Nie podaje żadnych wersji. Radar, który wyłapał 16.4.4, oznaczył je jako zmianę niekompatybilną; informacje o wydaniu żadnej takiej zmiany nie wymieniają, a wpis w npm zostawia zakres React na ^18.2.0 || ^19.0.0, a Node.js na >=20.9.0, dokładnie jak w 16.4.3.

Jeden szczegół czasowy: npm miał 16.4.4 o 10:49 UTC, a wydanie na GitHubie (otwiera się w nowej karcie) powstało jako szkic o 10:14 UTC i zostało opublikowane o 16:41 UTC. Jeśli twoje narzędzia śledzą wydania na GitHubie, zobaczyły tę wersję mniej więcej sześć godzin po tym, jak dało się ją zainstalować przez npm install.

Kogo to dotyczy i jak to sprawdzić

Każda aplikacja na 16.4.x może wziąć 16.4.4, ale różnicę zauważysz tylko w tych konfiguracjach:

Twoja konfiguracja	Co zmienia dla ciebie 16.4.4	Jak to sprawdzić
Build produkcyjny Turbopackiem na 16.4.0–16.4.3	Kod serwera znów działa w trybie strict	next build bez --webpack; zależność, która źle działa dopiero po next start
Obejście błędu trybu strict w next.config.ts	Możesz je usunąć	experimental.serverMinification: false albo pakiet dopisany z tego powodu do serverExternalPackages
PPR i CSP z nonce, build Turbopackiem	Skrypt startowy niesie nonce	Polityka script-src 'nonce-…' i naruszenia CSP w konsoli na prerenderowanych stronach
Preview Mode w Pages Routerze	Ciasteczka podpisuje i weryfikuje fast-jwt, algorytmem HS256	res.setPreviewData w trasie API
next dev z Turbopackiem	Przegapiona zmiana CSS przy starcie przeładowuje stronę	Style, które zignorowały zmianę zrobioną tuż po starcie serwera deweloperskiego
Next.js 15.x lub 16.3.x	Nic: 16.4.4 należy do linii 16.4	npx next --version

Jeśli masz wersję od 16.0.0 do 16.4.0, pilniejszy jest starszy problem: twoja wersja mieści się w zakresie podatnym trzech advisories z 14 października 2026, w tym dwóch krytycznych, m.in. RCE w use cache (otwiera się w nowej karcie) na 16.0.0–16.4.0 i odmowy usługi przez Server Actions (otwiera się w nowej karcie), oba poprawione w 16.4.1. Przejdź od razu na 16.4.4, które zawiera poprawki z 16.4.1.

Jak zaktualizować Next.js z 16.4.3 do 16.4.4

1. Sprawdź, jakiej wersji używasz

   Uruchom npx next --version albo znajdź next w lockfile. Poniżej 16.4.1 jesteś narażony na październikowe advisories, więc zaktualizuj dziś, niezależnie od decyzji w sprawie wydania listopadowego.

2. Zainstaluj 16.4.4

   Uruchom npm install next@16.4.4 (albo pnpm add next@16.4.4, yarn add next@16.4.4). Node.js zostaje na >=20.9.0, a zakres React się nie zmienia, więc react i react-dom nie wymagają osobnej zmiany.

3. Usuń obejścia błędu trybu strict

   Jeśli wyłączyłeś experimental.serverMinification albo dopisałeś pakiet do serverExternalPackages tylko z powodu zgłoszenia #100617, usuń to ustawienie i sprawdź ten pakiet po buildzie produkcyjnym.

4. Zbuduj aplikację i przetestuj to, czego dotyczą poprawki

   Uruchom next build i next start, otwórz prerenderowaną stronę z twoją prawdziwą polityką CSP i patrz w konsoli na zablokowane skrypty. Jeśli używasz Preview Mode, przed wdrożeniem raz wejdź w podgląd, otwórz stronę i wyjdź.

5. Zaplanuj listopadową aktualizację bezpieczeństwa

   Obserwuj stronę bezpieczeństwa Next.js (otwiera się w nowej karcie). Gdy advisories listopadowego wydania wskażą wersje z poprawkami, sprawdź, czy dotyczą twojej aplikacji, i przejdź na wersję podaną dla twojej linii wydań.

Na co uważać

• 16.4.4 to nie jest wersja z poprawkami bezpieczeństwa. Nie zamykaj nią zgłoszenia o bezpieczeństwie. Gdy sprawdzaliśmy 3 listopada, latest w npm był 16.4.4, canary był 16.5.0-canary.38, a ani advisories, ani wpis o listopadowym wydaniu bezpieczeństwa jeszcze się nie ukazały. Zaplanuj w tym tygodniu drugą aktualizację.
• Ścisła CSP bez nonce to wciąż otwarty problem. Zgłoszenie #100906 (otwiera się w nowej karcie), założone 29 października na 16.4.3 i otwarte 3 listopada, opisuje, że shared runtime Turbopacka (experimental.turbopackSharedRuntime, według zgłoszenia domyślnie włączony) wstawia do HTML skrypt startowy bez nonce, który polityka script-src bez 'unsafe-inline' blokuje. 16.4.4 daje temu skryptowi nonce przy wznowieniu PPR, ale nie wyprowadza go z HTML. Zgłaszający nie miał żadnego skryptu osadzonego w HTML przy turbopackSharedRuntime: false albo w buildzie webpackiem.
• Brak wymienionych zmian niekompatybilnych. Informacje o wydaniu nie wymieniają żadnej, wpis w npm ma te same zależności, peer dependencies i engines co 16.4.3, a revert przywraca format kodu, którego linia LTS używała przed optymalizacją.
• Czego nie zrobiliśmy. Nie budowaliśmy aplikacji na 16.4.4. Każde twierdzenie pochodzi z informacji o wydaniu, z pull requestów i zgłoszeń, do których prowadzą, z rejestru npm i z bloga Next.js, czytanych 3 listopada 2026.

Więcej informacji