Next.js ha corretto 13 advisory di sicurezza. I team self-hosted hanno più lavoro da fare.

Il 7 maggio, Vercel ha rilasciato una patch di sicurezza coordinata che copre 13 advisory per Next.js e React Server Components. Il pacchetto include problemi ad alta gravità per denial-of-service, server-side request forgery, avvelenamento della cache e diverse vulnerabilità di bypass del middleware che interessano App Router. Se il vostro team esegue Next.js in modalità self-hosted su Node, avete il lavoro più impegnativo davanti.

Le correzioni sono in 15.5.18 e 16.2.6. Gli utenti di React che usano react-server-dom dovrebbero aggiornarsi a 19.0.6, 19.1.7 o 19.2.6 a seconda della versione che seguono. Le versioni 13.x e 14.x non riceveranno patch, quindi chiunque sia ancora su queste versioni deve pianificare un aggiornamento piuttosto che attendere un cherry-pick.

Cosa c'è nel pacchetto

Il CVE principale che la maggior parte delle fonti cita è CVE-2026-23870, un DoS ad alta gravità nella deserializzazione del protocollo React Flight. Una richiesta HTTP appositamente costruita a qualsiasi funzione server di App Router può bloccare un core CPU. Grave, ma un tipo di bug noto, che un WAF o un rate limiter può attenuare.

La categoria che vale la pena approfondire è quella dei bypass del middleware. Gli advisory descrivono varianti in cui gli URL .rsc e di segment-prefetch si risolvono alla stessa pagina di una richiesta normale, ma saltano le regole del middleware matcher. In pratica: se il vostro middleware.ts è l'unica barriera tra una richiesta non autenticata e una pagina protetta, un attaccante può richiedere lo stesso contenuto tramite un trasporto diverso e accedere. Esiste anche una variante correlata per Pages Router legata alla gestione delle localizzazioni i18n, più un advisory successivo per il percorso di codice Turbopack perché la correzione originale non lo copriva.

I restanti advisory riguardano SSRF tramite richieste di upgrade WebSocket su Node self-hosted (le app ospitate su Vercel non sono interessate), DoS nell'API Image Optimization, XSS e avvelenamento della cache delle risposte RSC.

Perché «il middleware come auth» continua a creare problemi

Nei nostri engagement di pentesting, questo è uno dei pattern che testiamo per primi quando vediamo Next.js nel perimetro. Lo schema si ripete: un singolo middleware.ts controlla il cookie di sessione, reindirizza al login se mancante, e il team tratta ogni route sotto di esso come protetta. Sembra pulito. Si legge bene nelle PR. E di solito ha una lacuna legata alla variante di trasporto che qualcuno troverà prima o poi.

Il middleware in Next.js è una questione di routing. Viene eseguito presto, ha API limitate e ha storicamente avuto comportamenti anomali nel modo in cui i matcher si applicano alle forme di richiesta interne (payload RSC, prefetch, segmenti dinamici, percorsi con prefisso locale). Ognuna di queste anomalie è emersa come classe di CVE in qualche momento. Il lotto di questa settimana è l'ultimo promemoria.

Quando sviluppiamo app cloud-native con App Router, trattiamo il middleware come un filtro rapido e inseriamo i veri controlli di autorizzazione nel route handler, nella server action o nel server component stesso. Il valore del cookie diventa l'input, non il verdetto. Quel controllo aggiuntivo costa quasi nulla e elimina un'intera famiglia di rischi di bypass.

Cosa fare questa settimana

Una breve lista:

1. Aggiornate next a 15.5.18 o 16.2.6. Se pubblicate su Pages Router con i18n tramite l'adattatore OpenNext, aggiornatelo anche a 5.15.11.
2. Se dipendete direttamente da react-server-dom-*, allineate la versione patch 19.x che state usando (19.0.6, 19.1.7 o 19.2.6).
3. Pianificate la migrazione dalle versioni 13.x o 14.x. Questi rami non riceveranno queste correzioni.
4. Verificate il vostro middleware.ts. Se una route è protetta solo dal middleware, aggiungete un controllo di autorizzazione lato server all'interno del route handler, della server action o del layout. Non saltate questo passaggio solo perché avete aggiornato.
5. Per le distribuzioni Node self-hosted, controllate i log edge o proxy per richieste .rsc insolite, upgrade WebSocket verso origini inattese e picchi di traffico sull'API Image Optimization. I problemi SSRF e DoS si manifesteranno prima negli ambienti self-hosted.

Una nota su self-hosted e piattaforma

Diversi di questi problemi riguardano esplicitamente il Node self-hosted. Vercel afferma che i progetti ospitati avevano regole WAF prima della patch. Netlify dice che alcuni advisory non si applicano affatto al loro modello serverless. Questo divario vale la pena di considerare quando si decide dove eseguire Next.js.

Dal nostro lavoro di sviluppo cloud-native, abbiamo visto molti team scegliere il self-hosting per motivi di costo o conformità (soprattutto i clienti enterprise svizzeri), ed è una scelta legittima. Ma vi assumete una maggiore responsabilità per la sicurezza runtime, e la cadenza delle patch diventa parte del budget operativo, non un ripensamento trimestrale.

Se mantenere uno stack Next.js self-hosted protetto e aggiornato secondo un calendario reale vi suona familiare, parliamone. Facciamo questo lavoro su build web e mobile e revisioni di sicurezza, e la risposta è raramente «più middleware».