Next.js przechodzi na comiesięczne łatki bezpieczeństwa: 9 CVE na start. Koniec ery strony „zrób i zapomnij”

Co ogłosił zespół Next.js i co dokładnie załatano?

13 lipca 2026 na oficjalnym blogu Next.js pojawił się wpis o formalnym security release program: mniej więcej raz w miesiącu zespół będzie z wyprzedzeniem zapowiadał paczkę łatek — z terminem i najwyższą przewidywaną ważnością — tak, żeby zespoły developerskie mogły planować aktualizacje, a hostingi przygotować reguły firewalla, zanim szczegóły podatności staną się publiczne. Pilne 0-daye nadal będą łatane ad hoc. Deklaracja z ogłoszenia: „Today we are moving to a formal security release program, with updates that teams can plan around”.

Pierwsza planowa paczka, zapowiedziana na 20 lipca, wyszła 21 lipca 2026 i zawiera 9 CVE: 4 o ważności high i 5 medium. Poprawki trafiły do wersji 16.2.11 (Active LTS) i 15.5.21 (Maintenance LTS). Żadna z podatności nie jest krytyczna i na dzień 25 lipca brak doniesień o ich wykorzystaniu w atakach — ale wśród czterech high jest m.in. drugi w historii frameworka bypass autoryzacji w middleware (CVE-2026-64642, Turbopack z jednym wpisem w i18n.locales) oraz dwa SSRF (CVE-2026-64645 w rewrites(), CVE-2026-64649 w Server Actions na custom serwerach).

Które strony realnie obejmuje 9 lipcowych CVE?

Tu należy się czytelnikowi uczciwość, której brakuje w alarmistycznych omówieniach: większość z 9 podatności wymaga konkretnej konfiguracji. Strona w pełni statyczna (output: export, bez serwerowego runtime'u Next.js) jest praktycznie poza polem rażenia 6 z 9 CVE. Pełną ekspozycję ma za to każda strona z panelem klienta, formularzami na Server Actions albo logowaniem w middleware.

Dlaczego Next.js przechodzi na miesięczny rytm właśnie teraz?

Oficjalne uzasadnienie brzmi: „The volume of vulnerability research across the industry is rising fast, driven by LLM-assisted discovery”. I stoi za nim twardy przykład: 22 kwietnia 2026 Mozilla wydała Firefoksa 150 z 271 poprawkami błędów znalezionych w jednym przebiegu narzędzia Claude Mythos (Anthropic). Warto tę liczbę od razu urealnić, bo bywa nadużywana: w oficjalnym advisory tylko 3 z nich dostały numery CVE, a sama Mozilla studzi emocje — każdy z tych błędów „mógłby znaleźć także elitarny badacz-człowiek”. AI zmienia tempo odkrywania dziur, nie ich kategorię. Vercel deklaruje, że sam używa tej klasy narzędzi (projekt deepsec, bug bounty na HackerOne).

Program ma też krytyków — i obie linie krytyki warto potraktować poważnie. Pierwsza: zapowiedź z wyprzedzeniem pomaga również atakującym, bo daje im kalendarz do polowania na okno między publikacją łatki a jej wdrożeniem u spóźnialskich. Kontrargument: identyczny model działa od lat w Node.js i Chrome, a hostingi dostają czas na wdrożenie mitygacji WAF przed ujawnieniem szczegółów — Netlify opublikowało swoje reguły i zalecenia już 21 lipca. Druga: to element marketingu Vercela, wzmacniający narrację „hostuj u nas, my łatamy za ciebie”. Częściowo tak — ale program formalizuje coś, co po grudniowym React2Shell i tak stało się koniecznością, niezależnie od tego, komu przy okazji pomaga wizerunkowo.

Czego nauczył nas React2Shell — ile naprawdę masz czasu na patch?

3 grudnia 2025 ujawniono CVE-2025-55182, zwany React2Shell: pre-auth RCE w React Server Components z oceną CVSS 10.0, dotykający Next.js 15.x i 16.x z App Routerem. Eksploitacja ruszyła w ciągu godzin od publikacji — według Wiz skuteczność prób była bliska 100%, a wśród atakujących znalazły się grupy powiązane z Chinami (Earth Lamia, Jackpot Panda — dane AWS). CyberScoop potwierdził ponad 50 ofiar. Shadowserver widział szczytowo ponad 165 000 adresów IP i 644 000 domen z podatnym kodem; 11 grudnia 2025 — wciąż około 137 200 wystawionych IP, z czego według The Register połowa była niezałatana mimo aktywnej eksploitacji. Według Wiz podatne wersje zawierało 39% monitorowanych środowisk chmurowych.

Lekcja jest prosta: okno między publikacją podatności a atakiem liczy się w godzinach, nie w tygodniach. Przewidywalny, comiesięczny rozkład jazdy łatek to odpowiedź na dokładnie ten problem.

Do kiedy Twoja wersja Next.js dostaje łatki?

Polityka wsparcia (stan na 25.07.2026, oficjalna strona support policy) wygląda tak:

To najważniejszy wiersz tej tabeli: strona na Next.js 14 lub starszym nie dostanie poprawki także na przyszłe odpowiedniki React2Shell. A mowa o niemałej populacji — Next.js napędza 3,0% wszystkich stron WWW (W3Techs, lipiec 2026), w tym serwisy Amazona, Nike czy OpenAI.

Czy Google naprawdę zaostrzył LCP do 2,0 sekundy?

Od czerwca krąży fala tekstów — w większości generowanych maszynowo — że „Google w March 2026 core update zaostrzył próg LCP z 2,5 s do 2,0 s”. To nieprawda. Dokumentacja web.dev na 25 lipca 2026 podaje niezmiennie: LCP 2,5 s, INP 200 ms, CLS 0,1. Jeśli ktoś argumentuje przebudowę strony rzekomym nowym progiem Google — prosi o pieniądze pod fałszywym pretekstem. Prawdziwych powodów do dbania o stronę, jak widać wyżej, wymyślać nie trzeba.

Co to wszystko oznacza dla właściciela strony firmowej?

Z praktyki AD AWARDS — budujemy strony w Next.js dla polskich firm i po React2Shell utrzymujemy wdrożenia wyłącznie na wersjach LTS — płynie jedna obserwacja porządkująca cały ten news: ekspozycja zależy od architektury strony, nie od samego frameworka. Statyczna wizytówka bez Server Actions jest poza zasięgiem większości lipcowej paczki. Strona z panelem klienta, formularzami serwerowymi czy logowaniem w middleware wchodzi w pełne pole rażenia — łącznie z drugim już w historii frameworka obejściem autoryzacji.

Szerszy wniosek: strona firmowa na nowoczesnym frameworku przestała być produktem „zrób i zapomnij” — ma cykl serwisowy jak samochód, a od 21 lipca 2026 ten cykl ma oficjalny, comiesięczny rozkład jazdy. Minimalny plan na najbliższe tygodnie: sprawdzić wersję Next.js swojej strony (14 lub starsza = alarm), zaktualizować do 16.2.11 albo 15.5.21, a przy 15.x — wpisać do kalendarza migrację na 16.x przed 21 października 2026.