Next.js 16.4.1 i 15.5.28: krytyczne RCE w use cache i SVG

Next.js 16.4.1 i Next.js 15.5.28 naprawiają dwie krytyczne podatności RCE oraz poważny błąd odmowy usługi. Jedna luka dotyczy App Routera i funkcji oznaczonych use cache, druga pochodzi z przetwarzania obrazów SVG na systemach Linux opartych na glibc. Dla pierwszej z nich producent nie podaje obejścia — konieczna jest aktualizacja.

Komunikat z 14 października 2026 roku ma znaczenie dla firm utrzymujących sklepy, portale, systemy klienta i aplikacje SaaS na Next.js. Nie każda aplikacja ma taki sam poziom ekspozycji, ale sam brak podobnej funkcji cache w kodzie biznesowym nie jest podstawą do pominięcia poprawki. Oficjalne zalecenie dla krytycznego błędu GHSA-673q-mjm6-r5xr brzmi: zaktualizować nawet wtedy, gdy aplikacja nie zawiera funkcji zwracającej opisane typy danych.

Najważniejsze działanie: ustal wersję Next.js w każdym wdrożeniu, zaktualizuj do 16.4.1 lub 15.5.28, przebuduj artefakty od zera i potwierdź, że środowisko produkcyjne rzeczywiście działa na nowym pakiecie. Zmiana samego pliku package.json nie zamyka ryzyka.

Jakie podatności naprawia Next.js 16.4.1

Aktualizacja obejmuje trzy ważne scenariusze. Dwa mogą prowadzić do zdalnego wykonania kodu bez uwierzytelnienia, a trzeci do wyczerpania procesora.

GHSA-673q-mjm6-r5xr: krytyczne RCE w use cache

Pierwsza podatność występuje w Next.js 16 korzystającym z App Routera i funkcji Cache Components. Jeżeli funkcja use cache zwraca wiele tablic typowanych, specjalnie przygotowane żądanie może doprowadzić do zdalnego wykonania kodu na serwerze.

Advisory obejmuje wersje od 16.0.0 do 16.4.0 i wskazuje wersję 16.4.1 jako naprawioną. Luka otrzymała 9,5 w CVSS v4. Producent nie podaje skutecznego obejścia. Co ważne, zaleca aktualizację wszystkich wdrożeń z podatnego zakresu, nawet gdy zespół nie znalazł podobnej funkcji w swojej aplikacji.

CVE-2026-96889: krytyczne RCE podczas optymalizacji SVG

Drugi problem jest śledzony jako CVE-2026-96889 i GHSA-2464-fhr4-w9xw. Pochodzi z błędu pamięci w komponencie używanym przez mechanizm optymalizacji obrazów. Ryzyko dotyczy przetwarzania SVG na serwerach Linux korzystających z glibc i może prowadzić do wykonania kodu bez logowania.

Podatne są wersje Next.js od 10.0.0 do 15.5.27 oraz od 16.0.1 do 16.4.0. Wersjami naprawionymi są 15.5.28 i 16.4.1. Alternatywnym środkiem dla tego jednego problemu jest użycie biblioteki sharp w wersji co najmniej 0.35.5, ale aktualizacja Next.js zapewnia zależność z poprawką i jest prostsza do udokumentowania.

GHSA-p3m5-59mp-jv5r: odmowa usługi przez Server Actions

Trzecia podatność ma poziom wysoki. Dotyczy aplikacji korzystających z App Routera i co najmniej jednej Server Action. Specjalnie przygotowane żądania mogą powodować nadmierne zużycie procesora i ograniczyć dostępność usługi. Aplikacje używające wyłącznie Pages Routera oraz aplikacje bez Server Actions nie są objęte tym konkretnym scenariuszem.

Które firmy i aplikacje są zagrożone

Pilnego działania wymagają zespoły, które:

• używają Next.js 16.0.0–16.4.0 z App Routerem i Cache Components;
• używają Next.js 10.0.0–15.5.27 albo 16.0.1–16.4.0 z serwerową optymalizacją obrazów SVG;
• mają App Router oraz Server Actions w wersji objętej komunikatem;
• budują jeden obraz bazowy lub szablon dla wielu aplikacji klientów;
• posiadają nieaktywne, testowe lub podglądowe wdrożenia dostępne z internetu.

Wersję trzeba sprawdzać w lockfile i zbudowanym artefakcie, a nie tylko w deklaracji zależności. Zakres taki jak ^16.0.0 może rozwiązywać się inaczej zależnie od daty instalacji, cache’u i menedżera pakietów. Monorepo może też zawierać kilka aplikacji na różnych wydaniach.

Jak bezpiecznie zaktualizować Next.js

1. Zbuduj listę wdrożeń

Przeszukaj repozytoria, lockfile, SBOM-y, obrazy kontenerowe i platformę hostingową. Uwzględnij produkcję, środowiska testowe, preview deployments, stare domeny oraz szablony startowe. Przypisz właściciela i wersję do każdej instancji.

2. Zaktualizuj właściwą linię LTS

Next.js 16 należy podnieść co najmniej do 16.4.1, a utrzymywaną linię 15 — do 15.5.28. Po aktualizacji odśwież lockfile w kontrolowany sposób, uruchom testy i zweryfikuj zmiany zależności pośrednich. Nie kopiuj starego katalogu node_modules do nowego obrazu.

3. Przebuduj i ponownie wdróż aplikację

Nowy commit nie oznacza automatycznie nowej produkcji. Przebuduj obrazy oraz artefakty bez użycia skażonego cache’u, opublikuj je i sprawdź identyfikator wdrożenia. Następnie usuń lub ogranicz stare instancje, które nadal mogą obsługiwać ruch.

4. Przetestuj funkcje biznesowe

Sprawdź cache, generowanie stron, Server Actions, przesyłanie i optymalizację obrazów, logowanie, płatności oraz integracje. Monitoruj błędy, opóźnienia i zużycie CPU. Aktualizacja bezpieczeństwa nadal wymaga normalnej kontroli jakości.

5. Zachowaj dowód zamknięcia

Zapisz podatną i docelową wersję, listę wdrożeń, wynik testów, czas publikacji oraz osobę akceptującą zmianę. W bezpiecznym procesie CI/CD takie dane powinny powstawać automatycznie, a krytyczna zależność powinna blokować promocję starego artefaktu.

Czy WAF ochroni aplikację Next.js przed RCE?

WAF może ograniczyć część podejrzanego ruchu i kupić czas, ale nie jest potwierdzonym zamiennikiem aktualizacji dla tych luk. Nowe warianty wejścia mogą omijać reguły sygnaturowe, a ruch do funkcji serwerowych może wyglądać podobnie do legalnych żądań.

Jeżeli pełne wdrożenie musi poczekać, ogranicz publiczny dostęp do środowisk testowych, wyłącz niepotrzebną optymalizację niezaufanych SVG, zastosuj limity żądań i monitoruj skoki CPU. Dla luki SVG sharp 0.35.5 lub nowszy jest oficjalnie wskazanym środkiem, ale nie rozwiązuje osobnej podatności use cache.

Fakty źródłowe i wnioski Breachroad

Zespół Next.js potwierdza dotknięte wersje, wymagane konfiguracje, dwie możliwości RCE, scenariusz DoS, naprawione wydania i brak obejścia dla krytycznej luki use cache. Advisory GitHub potwierdzają zakres wersji i ocenę 9,5 w CVSS v4 dla obu RCE.

Zalecenia dotyczące inwentaryzacji preview deployments, czystej przebudowy, dowodu wdrożenia i testów biznesowych są wnioskami Breachroad. Organizacje mogą utrwalić taki sposób pracy na szkoleniu z cyberbezpieczeństwa dla zespołów, a aplikacje o wysokiej wartości zweryfikować w ramach audytu bezpieczeństwa IT.

FAQ: Next.js 16.4.1 i krytyczne RCE

Do jakiej wersji Next.js trzeba zaktualizować?

Dla aktywnej linii 16 jest to co najmniej 16.4.1, a dla utrzymywanej linii 15 — co najmniej 15.5.28. Trzeba też śledzić kolejne wydania bezpieczeństwa producenta.

Czy Pages Router jest podatny na RCE w use cache?

Opisany scenariusz GHSA-673q-mjm6-r5xr dotyczy App Routera z Cache Components. Nie zwalnia to jednak aplikacji Pages Router z aktualizacji innych podatnych komponentów, w tym optymalizacji SVG.

Czy wyłączenie SVG wystarczy?

Może ograniczyć scenariusz CVE-2026-96889, ale nie naprawia RCE w use cache ani DoS związanej z Server Actions. Najpełniejszą odpowiedzią jest przejście na naprawione wydanie.

Jak sprawdzić wersję na produkcji?

Najlepiej odczytać ją z lockfile i SBOM-u konkretnego artefaktu lub obrazu, a następnie powiązać z identyfikatorem produkcyjnego wdrożenia. Sama deklaracja w package.json nie potwierdza wersji działającej usługi.

Źródła pierwotne: Next.js — Security Update, 14 October 2026, GitHub Advisory — GHSA-673q-mjm6-r5xr, GitHub Advisory — GHSA-2464-fhr4-w9xw.