Next.js tocmai a corectat 13 vulnerabilități de securitate. Echipele self-hosted au cea mai multă treabă.

Pe 7 mai, Vercel a lansat o actualizare coordonată de securitate acoperind 13 advisory-uri pentru Next.js și React Server Components. Pachetul include probleme de severitate ridicată pentru denial-of-service, server-side request forgery, otrăvire a cache-ului și mai multe vulnerabilități de bypass al middleware-ului care afectează App Router. Dacă echipa ta rulează Next.js self-hosted pe Node, ai cel mai mult de lucru.

Corecțiile ajung în 15.5.18 și 16.2.6. Utilizatorii React pe react-server-dom ar trebui să treacă la 19.0.6, 19.1.7 sau 19.2.6, în funcție de linia pe care o urmăresc. Versiunile 13.x și 14.x nu primesc patch-uri, deci oricine mai e pe acestea trebuie să planifice un upgrade în loc să aștepte un cherry-pick.

Ce conține pachetul

CVE-ul principal pe care majoritatea publicațiilor îl citează este CVE-2026-23870, un DoS de severitate ridicată în deserializarea protocolului React Flight. O cerere HTTP special construită către orice funcție de server App Router poate bloca un nucleu CPU. Grav, dar o formă de bug cunoscută, genul pe care un WAF sau un rate limiter îl poate atenua.

Clasa care merită citită mai atent este setul de bypass-uri de middleware. Advisory-urile descriu variante unde URL-urile .rsc și segment-prefetch se rezolvă la aceeași pagină ca o cerere normală, dar ocolesc regulile matcher-ului de middleware. Traducere: dacă middleware.ts este singurul lucru dintre o cerere neautentificată și o pagină protejată, un atacator poate solicita același conținut printr-un alt transport și poate intra. Există o variantă conexă pentru Pages Router legată de gestionarea localei i18n, plus un advisory de urmărire pentru calea de cod Turbopack, deoarece corecția originală nu o acoperea.

Celelalte advisory-uri acoperă SSRF prin cereri de upgrade WebSocket pe Node self-hosted (aplicațiile găzduite pe Vercel nu sunt afectate), DoS în API-ul de optimizare a imaginilor, XSS și otrăvirea cache-ului răspunsurilor RSC.

De ce „middleware ca autorizare” continuă să afecteze echipele

În angajamentele noastre de pentesting, acesta este unul dintre pattern-urile pe care le testăm primele când vedem Next.js în domeniu. Forma se repetă: un singur middleware.ts verifică cookie-ul de sesiune, redirecționează către login dacă lipsește, iar echipa tratează fiecare rută de sub el ca protejată. Pare curat. Se citește bine în PR-uri. Și de obicei are un gap de variantă de transport pe care cineva îl va găsi în cele din urmă.

Middleware-ul în Next.js este o preocupare de rutare. Rulează devreme, are API-uri limitate și a avut istoric ciudățenii legate de modul în care matcher-ele se aplică la formele interne de cereri (payload-uri RSC, prefetch-uri, segmente dinamice, căi cu prefix de locală). Fiecare dintre aceste ciudățenii a apărut la un moment dat ca o clasă de CVE. Pachetul din această săptămână este cel mai recent memento.

Când construim aplicații cloud-native cu App Router, tratăm middleware-ul ca un filtru de cale rapidă și punem verificări reale de autorizare în route handler, server action sau server component. Valoarea cookie-ului devine input, nu verdict. Această verificare suplimentară nu costă aproape nimic și elimină o întreagă familie de riscuri de bypass.

Ce să faci săptămâna aceasta

O listă scurtă:

1. Actualizează next la 15.5.18 sau 16.2.6. Dacă publici pe Pages Router cu i18n prin adaptorul OpenNext, actualizează-l și pe acesta la 5.15.11.
2. Dacă depinzi direct de react-server-dom-*, potrivește linia de patch 19.x pe care ești (19.0.6, 19.1.7 sau 19.2.6).
3. Planifică migrarea de pe 13.x sau 14.x. Acele ramuri nu vor primi aceste corecții.
4. Auditează-ți middleware.ts. Dacă o rută este protejată doar de middleware, adaugă o verificare de autorizare server-side în route handler, server action sau layout. Nu sări peste asta doar pentru că ai actualizat.
5. Pentru deployment-urile Node self-hosted, verifică log-urile de edge sau proxy pentru cereri .rsc neobișnuite, upgrade-uri WebSocket către origini neașteptate și spike-uri de trafic la Image Optimization. Problemele SSRF și DoS vor apărea mai întâi în mediile self-hosted.

O notă despre self-hosted vs platformă

Câteva dintre aceste probleme sunt explicit limitate la Node self-hosted. Vercel spune că proiectele găzduite aveau reguli WAF în fața patch-ului. Netlify spune că unele advisory-uri nu se aplică deloc modelului lor serverless. Acel gap merită luat în considerare când decizi unde să rulezi Next.js.

Din munca noastră de dezvoltare cloud-native, am văzut multe echipe care aleg self-hosting din motive de cost sau conformitate (în special clienți enterprise elvețieni), iar aceasta este o alegere validă. Dar îți asumi mai multă responsabilitate pentru securitatea runtime, iar cadența patch-urilor devine parte din bugetul operațional, nu o grijă trimestrială.

Dacă menținerea unui stack Next.js self-hosted securizat și actualizat conform unui program real îți sună familiar, să vorbim. Facem această muncă în dezvoltări web și mobile și review-uri de securitate, iar răspunsul este rareori „mai mult middleware”.