Il 14 ottobre il team di Next.js ha pubblicato l'aggiornamento di sicurezza straordinario che aveva annunciato la settimana prima: tre vulnerabilità corrette nelle versioni 16.4.1 e 15.5.28. Il 21 ottobre Next.js 15 ha compiuto due anni e la sua finestra di manutenzione si è chiusa. Se hai un sito o un'applicazione ancora sulla 15, portala almeno alla 15.5.28 adesso: con ogni probabilità è l'ultima patch che riceverà. Per sapere su che versione sei, nella cartella del progetto basta npm ls next.
Cosa ha corretto la patch del 14 ottobre
La falla che copre più versioni è CVE-2026-96889, critica. Un difetto di memoria nella libreria che Next.js usa per ottimizzare le immagini permette di eseguire codice sul server, senza autenticazione, quando l'applicazione elabora file SVG su Linux con glibc. Sono vulnerabili tutte le versioni dalla 10 alla 15.5.27, e la 16 fino alla 16.4.0. Chi non può aggiornare subito ha una via d'uscita temporanea indicata nell'avviso: assicurarsi che sharp sia almeno alla 0.35.5. Copre però solo questa falla.
La seconda critica, GHSA-673q-mjm6-r5xr, tocca solo la 16: esecuzione di codice da remoto nelle funzioni use cache che restituiscono più typed array, nelle app con App Router e Cache Components. Per questa non esiste una soluzione temporanea. La terza, GHSA-p3m5-59mp-jv5r, è di gravità alta: con richieste costruite apposta si porta al massimo la CPU di un'app App Router che abbia almeno una Server Action, e il processo smette di rispondere. Colpisce dalla 13 in su.
Per la 15 esiste una sola versione corretta, la 15.5.28. Per la 13 e la 14, esposte a due delle tre falle, non è uscito niente.
Cosa vuol dire «fuori supporto»
Secondo la politica di supporto di Next.js, una versione principale resta in Active LTS finché non esce la successiva. Poi passa in Maintenance LTS, dove riceve solo correzioni critiche e aggiornamenti di sicurezza essenziali, e ci resta per due anni dal proprio rilascio. La 15 è uscita il 21 ottobre 2024: i due anni sono finiti il 21 ottobre 2026. Il 22 ottobre la tabella della stessa pagina indicava ancora la 15 come Maintenance LTS, ma la regola dei due anni è scritta qualche riga sopra.
Il sito continua a funzionare come prima, ma smette di ricevere correzioni: la prossima falla verrà chiusa sulla 16 e resterà aperta sulla 15. La pagina aggiunge che «in rare circostanze», se il bug è abbastanza grave, il team corregge anche versioni fuori supporto. È successo a dicembre 2025, ma nessuno può dirti in anticipo se succederà con la prossima falla. Vale lo stesso per PHP 8.2, che perde il supporto di sicurezza il 31 dicembre.
44 avvisi di sicurezza nel 2026
Nell'elenco degli avvisi del progetto, quelli pubblicati dal 1° gennaio al 21 ottobre 2026 sono 44, cinque dei quali critici. Ad agosto una falla nell'ottimizzazione delle immagini AVIF permetteva di eseguire codice da remoto senza autenticazione: colpiva tutte le versioni dalla 10 in poi ed è stata corretta solo nella 15.5.24 e nella 16.3.3. A ottobre è andata allo stesso modo con gli SVG.
La 13 e la 14 sono rimaste scoperte entrambe le volte. Chi era sulla 15 ma su una versione minore precedente, per esempio la 15.2, ha dovuto prima salire alla 15.5, perché ad agosto e a ottobre le correzioni sono uscite solo lì. Dopo il 21 ottobre la prossima falla di questo tipo lascerà nella stessa situazione anche chi è sulla 15.5.
Il precedente: React2Shell
Il 3 dicembre 2025 è stata resa pubblica CVE-2025-55182, soprannominata React2Shell: esecuzione di codice da remoto, senza autenticazione, nei React Server Components, con punteggio 10 su 10. Secondo Invicti i primi attacchi reali sono stati osservati il giorno dopo. L'11 dicembre sono uscite le falle collegate, fra cui una negazione del servizio che il team ha corretto anche sulla 14, fuori supporto da ottobre, con la 14.2.34.
Chi aveva una versione aggiornata se l'è cavata cambiando un numero nel package.json e rifacendo il deploy; chi era indietro di una o due versioni principali ha dovuto prima recuperare il ritardo, di corsa, con gli attacchi già in giro.
Cosa cambia passando a Next.js 16
Si parte dal codemod ufficiale, npx @next/codemod@canary upgrade latest, che riscrive le parti meccaniche: per esempio rinomina middleware in proxy e sostituisce next lint con ESLint. La guida all'aggiornamento avverte però che non fa tutto. Se il codice legge ancora cookies(), headers(), params o searchParams in modo sincrono, come la 15 tollerava con un avviso, serve un secondo comando, npx @next/codemod@canary next-async-request-api ., perché nella 16 l'accesso sincrono non esiste più.
Le modifiche che rompono la build
Node.js 20.9 è la versione minima e Node 18 non è più supportato: su alcuni hosting e su alcune pipeline va aggiornato prima di tutto il resto. Turbopack diventa il default anche per next build, e se nel progetto c'è una configurazione webpack, magari aggiunta da un plugin, la build si ferma; per tenere webpack si usa next build --webpack. Le route parallele vogliono un file default.js esplicito per ogni slot, altrimenti la build fallisce. E revalidateTag chiamato con un solo argomento ora dà errore in TypeScript: serve il secondo, il profilo di cacheLife.
Le modifiche che cambiano il comportamento senza errori
Queste fanno più danni, perché la build passa e il problema si vede in produzione. Il proxy gira solo sul runtime Node.js: un middleware che contava sull'edge va lasciato com'è, non rinominato. Le immagini di next/image restano in cache 4 ore invece di 60 secondi, e di default è ammessa una sola qualità, 75: una richiesta diretta a /_next/image con un altro valore risponde 400. Le immagini da indirizzi IP locali vengono bloccate, una protezione contro gli attacchi SSRF che però rompe le installazioni in rete privata finché non si attiva dangerouslyAllowLocalIP. E serverRuntimeConfig e publicRuntimeConfig spariscono, sostituiti dalle variabili d'ambiente.
Nessuna obbliga a riscrivere l'applicazione, ma conviene trovarle tutte in una copia di prova invece che una alla volta dopo il rilascio.
Come lo affrontiamo noi
Quando l'aggiornamento dalla 15 alla 16 lo facciamo noi, l'ordine è questo:
- Fotografia di partenza: versioni di Next.js, React e Node, dipendenze che dichiarano compatibilità solo con la 15, configurazioni webpack aggiunte dai plugin.
- Un ramo separato, i due codemod, poi la revisione a mano delle modifiche, file per file.
- Prove su un'anteprima identica alla produzione, soprattutto su immagini, cache, autenticazione e reindirizzamenti.
- Rilascio solo quando l'anteprima si comporta come il sito attuale, con il ritorno indietro già pronto.
Se non sai su che versione gira la tua applicazione, o sai che è indietro, scrivici o guarda come lavoriamo sull'aggiornamento di software esistente. Partiamo dalla fotografia della situazione e ti diciamo quanto lavoro c'è, prima di toccare il codice.