Luki w Next.js i React: kogo dotyczą łaty z października

Jeśli Twoja strona albo sklep działa na Next.js, w październiku pojawiły się dla niej ważne poprawki bezpieczeństwa. 14 października 2026 r. zespół Next.js wydał wersje 16.4.1 i 15.5.28, które zamykają trzy luki. Dwie z nich mogą pozwolić obcej osobie uruchomić na serwerze własny kod bez logowania. Tego samego dnia wyszły też poprawki Reacta dla stron korzystających z React Server Components.

Nie każda strona na Next.js jest narażona, a wielu właścicieli firm nie wie, na czym w ogóle stoi ich strona. Poniżej wyjaśniam, kogo dotyczą te luki, jak sprawdzić wersję bez programisty, co zrobić dziś i co zlecić wykonawcy. Stan wiedzy: 30 października 2026 r. Wersje z poprawkami mogą się zmienić, więc przed aktualizacją sprawdź je na blogu Next.js.

Co się stało 14 października

Next.js to popularny framework do budowy stron i sklepów w Reakcie, rozwijany przez firmę Vercel. 14 października zespół wydał aktualizację bezpieczeństwa poza zwykłym harmonogramem. Ogłoszenie na blogu Next.js opisuje trzy błędy:

• Optymalizacja obrazów i pliki SVG (CVE-2026-96889). Błąd tkwi w bibliotece librsvg, z której korzysta sharp, czyli narzędzie zmniejszające zdjęcia na serwerze. Na Linuksie z biblioteką glibc spreparowany plik SVG może doprowadzić do zdalnego wykonania kodu. Waga: krytyczna.
• Funkcje „use cache” (GHSA-673q-mjm6-r5xr). Dotyczy tylko Next.js 16 z włączonymi Cache Components. Gdy funkcja z dyrektywą use cache zwraca kilka tablic typowanych (typed arrays), atakujący bez logowania może uruchomić kod na serwerze. Obejścia nie ma. Waga: krytyczna.
• Server Actions (GHSA-p3m5-59mp-jv5r). Spreparowane zapytania mogą tak obciążyć procesor, że strona przestaje odpowiadać (atak DoS). Waga: wysoka.

Obie krytyczne luki mają w zgłoszeniach na GitHubie ocenę 9,5 na 10 w skali CVSS 4.0. Singapurska agencja cyberbezpieczeństwa CSA w alercie z 20 października zaleca natychmiastową aktualizację. Vercel w ogłoszeniu nie wspomina o atakach, a luki CVE-2026-96889 nie ma w katalogu CISA KEV, czyli amerykańskim spisie luk wykorzystywanych w atakach (stan na 29.10.2026). To dobry moment, żeby załatać stronę spokojnie, a nie w pośpiechu.

Kogo dotyczą te luki

Krótko: dotyczą stron, na których Next.js działa na serwerze, czyli przygotowuje strony albo obrazy w chwili, gdy wchodzi klient.

Przy luce w „use cache” Next.js zaleca aktualizację nawet wtedy, gdy w projekcie nie ma takich funkcji. Strona na Next.js dostaje poprawki Reacta razem z aktualizacją Next.js, bo framework ma własną kopię tych pakietów. Osobno aktualizują je projekty, które korzystają z React Server Components w innym narzędziu, na przykład w React Router albo Waku.

Czego te luki nie dotyczą:

• stron na WordPressie, WooCommerce, Shoperze i innych systemach bez Next.js,
• aplikacji w samym Reakcie bez serwera (na przykład zbudowanych w Vite): zespół Reacta pisze wprost, że kod bez serwera nie jest narażony,
• stron Next.js eksportowanych statycznie (output: 'export'). Na hostingu leżą wtedy same pliki HTML, CSS i JavaScript, a eksport statyczny nie obsługuje Server Actions ani domyślnej optymalizacji obrazów. Taką stronę i tak zaktualizuj przy najbliższej przebudowie.

Uwaga na stare wersje. Według polityki wsparcia Next.js linie 14.x i starsze nie dostają już aktualizacji, a październikowe łaty wyszły tylko dla 15.5 i 16.4. Strona na Next.js 14 wymaga przejścia na nowszą linię. Linia 15 ma dostawać poprawki bezpieczeństwa do 31 stycznia 2027 r., więc warto już planować przejście na 16.

Vercel, Netlify czy własny serwer

• Własny serwer (VPS, Docker, hosting z Node.js). Tu ryzyko jest największe, bo obrazy przetwarza Twój serwer, zwykle z Linuksem. Popularne systemy Debian i Ubuntu korzystają z glibc.
• Netlify. W komunikacie z 14 października Netlify pisze, że obrazy z next/image obsługuje jego własna usługa Image CDN, więc luka w SVG nie działa tą drogą. Luka w „use cache” dotyczy jednak także stron na Netlify. Netlify zaleca aktualizację i usunięcie publicznych podglądów starych wdrożeń (deploy previews), bo mogą pozostać podatne.
• Vercel. Nie znalazłem komunikatu Vercel, że platforma sama chroni projekty przed tymi lukami (przy sierpniowym wydaniu taki komunikat był). Zakładaj więc, że projekt trzeba zaktualizować i wdrożyć ponownie.

Jak sprawdzić, czy Twoja strona jest narażona

Sposób 1: przeglądarka (2 minuty)

1. Otwórz swoją stronę w Chrome albo Edge na komputerze.
2. Naciśnij F12 (albo kliknij prawym przyciskiem myszy i wybierz Zbadaj), a potem otwórz kartę Console (Konsola).
3. Wpisz next.version i naciśnij Enter.

Jeśli pojawi się numer, na przykład "16.4.0", strona działa na Next.js i znasz jej wersję. Wersja 16.4.1 lub wyższa albo, w linii 15, 15.5.28 lub wyższa oznacza, że łaty z października są na miejscu. Liczby między kropkami porównuj osobno: 15.5.3 to wersja starsza niż 15.5.28. Gdy konsola pokaże błąd „next is not defined”, strona najpewniej nie jest zbudowana na Next.js.

Ta metoda nie powie, czy strona korzysta z „use cache” albo Server Actions ani jaką wersję sharp ma serwer. To wie wykonawca.

Sposób 2: pliki projektu

Jeśli masz dostęp do repozytorium (na przykład na GitHubie), otwórz plik package.json i znajdź linię z "next". Zapis ^16.4.0 oznacza zakres, a dokładną wersję pokazuje plik blokady: package-lock.json, pnpm-lock.yaml albo yarn.lock. Programista sprawdzi wszystko jednym poleceniem:

npm ls next sharp

Sposób 3: panel hostingu

Na Vercelu i Netlify otwórz ostatnie wdrożenie i jego logi budowania. Next.js wypisuje na początku budowania linię z wersją, na przykład „▲ Next.js 16.4.1”. Sprawdź wdrożenie produkcyjne, a nie tylko testowe.

Co zrobić dziś

1. Ustal, czy strona stoi na Next.js i w jakiej wersji. Wystarczy sposób 1 albo pytanie do wykonawcy.
2. Zrób kopię zapasową kodu i danych. Jak zrobić to porządnie, opisuję w poradzie o kopii zapasowej według zasady 3-2-1.
3. Zaktualizuj Next.js do co najmniej 16.4.1 (linia 16) albo 15.5.28 (linia 15). Pod koniec października najnowszą wersją była 16.4.3 z 23 października.
4. Sprawdź sharp. Ma mieć wersję 0.35.5 lub nowszą. Next.js 15.5.28 dopuszcza jeszcze starszą gałąź sharp 0.34, więc po aktualizacji upewnij się, co faktycznie się zainstalowało.
5. Zbuduj i wdróż stronę od nowa, a potem przeklikaj najważniejsze miejsca: formularz, koszyk, logowanie, galerię zdjęć.
6. Zaplanuj kolejną aktualizację. Na 3 listopada Next.js zapowiedział planowe wydanie bezpieczeństwa z poprawkami siedmiu luk o średniej wadze. Gdy się ukaże, powtórz kroki 2–5.

Polecenia dla osoby, która wdraża stronę:

npm install next@16.4.1   # linia 16 (albo nowsza 16.4.x)
npm install next@15.5.28  # linia 15
npm ls sharp              # oczekiwane: 0.35.5 lub nowsza

Jeśli strona stoi na 16.0–16.3, przejście na 16.4.1 to coś więcej niż drobna poprawka i wymaga testu przed wdrożeniem. Jeśli to potrwa dłużej, tymczasowym obejściem luki w obrazach jest wymuszenie sharp 0.35.5 lub nowszego. Na lukę w „use cache” obejścia nie ma.

Co zlecić hostingowi albo wykonawcy

Hosting zwykle aktualizuje system i Node.js, ale nie pakiety Twojej aplikacji. Next.js i sharp są częścią projektu, więc aktualizuje je wykonawca strony albo osoba z dostępem do kodu i wdrożeń. Kto za co odpowiada, najlepiej mieć zapisane w umowie na wykonanie strony.

Wiadomość do skopiowania:

Dzień dobry, w związku z aktualizacją bezpieczeństwa Next.js z 14 października 2026 r. proszę o:

1. informację, na jakiej wersji Next.js i sharp działa nasza strona (produkcja, wersja testowa i podglądy),
2. aktualizację do co najmniej 16.4.1 albo 15.5.28 i potwierdzenie wersji po wdrożeniu,
3. informację, czy strona korzysta z optymalizacji obrazów, Server Actions i „use cache”,
4. plan aktualizacji po wydaniu bezpieczeństwa Next.js zapowiedzianym na 3 listopada.

Proszę o odpowiedź do [data]. Dziękuję.

Jeśli wykonawca odpowie, że strona „nie używa SVG”, dopytaj o szczegóły. Domyślnie Next.js nie optymalizuje plików SVG, a część analiz wiąże ryzyko z włączoną opcją dangerouslyAllowSVG. Oficjalne ogłoszenie tego jednak nie zawęża, więc to nie powód, żeby odłożyć aktualizację.

Next.js działa na Node.js, więc przy okazji poproś też o sprawdzenie wersji Node.js. Opisuję to w poradzie o luce Node2Shell (CVE-2026-111497) w Node.js i Brotli.

Jeśli nie masz już kontaktu z wykonawcą, mogę przejąć stronę w ramach opieki technicznej. Pakiet Czuwanie (od 149 zł netto miesięcznie) to monitoring, kopie zapasowe, aktualizacje bezpieczeństwa i reakcja w 2 dni robocze. Standard (od 349 zł) i Pro (od 749 zł) dodają godziny prac i szybszą reakcję, w Pro do 4 godzin.

Jak nie przegapić kolejnych łat

Od lipca 2026 r. Next.js wydaje poprawki bezpieczeństwa według stałego programu i zapowiada je kilka dni wcześniej. Przy poważnych lukach wydaje je też poza kolejką, jak 14 października. Wystarczą trzy nawyki:

• Obserwuj zgłoszenia bezpieczeństwa Next.js na GitHubie (Security Advisories) albo blog Next.js.
• Włącz Dependabota w repozytorium projektu. Sam zaproponuje aktualizację pakietów, w których wykryto luki.
• Ustal z wykonawcą czas reakcji, na przykład wgranie poprawki krytycznej luki w ciągu 48 godzin od jej wydania.

Podsumowanie

Październikowe luki dotyczą stron, w których Next.js działa na serwerze: z optymalizacją obrazów, Server Actions albo „use cache”. Sprawdź wersję w przeglądarce, poproś wykonawcę o aktualizację do 16.4.1 lub 15.5.28 (albo nowszej) z potwierdzeniem na piśmie i nie zapomnij o wydaniu z 3 listopada. Jeśli wolisz, żeby ktoś zrobił to za Ciebie, napisz do mnie: sprawdzę wersje i zaktualizuję stronę, a przy większym projekcie zrobię audyt bezpieczeństwa. Nowe strony na Next.js buduję w ramach usługi Strona szyta na miarę.