Vulnerabilità Next.js: il triage dei 13 avvisi di maggio 2026

Vulnerabilità Next.js: il quadro in una riga e il triage che conta davvero

Il 6 maggio 2026 Next.js ha pubblicato 13 avvisi di sicurezza coordinati e il 7 maggio sono arrivate le release corrette: le versioni 16.2.6 e 15.5.18. L'attenzione della stampa si è concentrata su CVE-2026-44578, l'SSRF via WebSocket, perché lo screenshot fa effetto: un attaccante esegue l'upgrade di una connessione, il server raggiunge 169.254.169.254 e l'endpoint dei metadati restituisce le credenziali IAM. Una scena drammatica.

Ma riguarda soltanto le installazioni self-hosted. In un deployment gestito da Vercel con Cloudflare davanti, quel percorso non è raggiungibile. A poter arrivare fino ai miei lettori è invece la vulnerabilità Moderate di cache poisoning RSC di cui non parla nessuno: una risposta RSC contaminata non resta confinata alla richiesta dell'attaccante, ma finisce nella cache edge condivisa e viene servita a ogni visitatore finché non eseguo il purge del tag.

Chi esegue una qualsiasi versione di Next.js >= 13.4.13 deve aggiornarla questa settimana. Le sole domande sono a quale versione passare, in quale ordine e che cosa ritestare dopo. Il triage che segue è la matrice che ho applicato a omidsaffari.com — App Router su Vercel, Cloudflare davanti, purge tramite Cache-Tag e webhook di revalidate — e spiega perché ho tolto la priorità alla CVE da prima pagina.

Che cosa comporta per i founder non tecnici

Se il vostro prodotto è un'app Next.js, è un'attività da chiudere questa settimana, non un ticket da lasciare nel backlog. Il costo non si misura in latenza o ore di sviluppo: una pagina in cache contaminata o una rotta admin accessibile aggirando l'autenticazione diventano un problema di fiducia dei clienti. Basta uno screenshot della pagina marketing che mostra contenuti inseriti da un attaccante, o una segnalazione di accesso a /admin senza sessione, per passare la settimana successiva a dare spiegazioni invece di vendere.

Fate agli sviluppatori una sola domanda: «Siamo sulla 16.2.6 o sulla 15.5.18, e dopo il deployment abbiamo svuotato la cache edge?» Se la risposta è più vaga — «stiamo applicando la patch», «ci stiamo lavorando», «l'SSRF non ci riguarda» — il lavoro non è finito. I deployment self-hosted (ECS, EC2, Kubernetes e qualsiasi ambiente che esegua next start su un server sotto il vostro controllo) appartengono alla fascia di rischio più alta, perché oltre a tutto il resto sono esposti anche all'SSRF. Chiedete in quale categoria rientrate: la risposta dovrebbe richiedere dieci secondi.

I 13 avvisi, ordinati in base alla possibilità di colpire il vostro stack

L'errore di tutti i post del tipo «13 CVE, applicate subito le patch» che stanno circolando è presentare l'elenco come se ogni voce avesse lo stesso peso. Non è così. Ogni avviso richiede una precondizione — self-hosting, Turbopack, Cache Components, nonce CSP, i18n — e l'esposizione reale coincide con il sottoinsieme compatibile con il vostro deployment. Ecco gli stessi 13 avvisi, raggruppati in base alle condizioni necessarie perché la vulnerabilità si manifesti.

Cluster di bypass di middleware e proxy (5 avvisi, perlopiù High). Il più importante è GHSA-267c-6grr-h53f, che permette a un URL di segment-prefetch dell'App Router di aggirare i controlli di autenticazione del middleware. Nel cluster rientrano anche il follow-up alla correzione incompleta, pubblicato il 7 maggio (GHSA-26hh-7cqf-hhc6) per Turbopack, il bypass di un percorso Pages Router i18n con locale predefinito e un bypass tramite injection del parametro di una rotta dinamica. Precondizione: usate il middleware di Next.js per imporre l'autenticazione o gestire i rewrite. È il caso di quasi tutti.

SSRF, CVE-2026-44578. Nel server self-hosted, il gestore dell'upgrade WebSocket può raggiungere endpoint HTTP interni sulla porta 80, compresi i metadati cloud. Versioni interessate: 13.4.13+ fino a <15.5.16 e 16.0.0–<16.2.5, solo self-hosted. È confermato che i deployment gestiti da Vercel non sono interessati.

Denial of service, due avvisi. Il primo è il DoS RSC upstream; il secondo è un DoS per esaurimento delle connessioni nelle app che hanno attivato Cache Components (High, GHSA-q4gf-8mx6-v5v3). Precondizione per il secondo: Cache Components deve essere stato abilitato esplicitamente, cosa che la maggior parte delle app non ha fatto.

Cache poisoning RSC (Moderate). Le collisioni nel meccanismo di cache busting della pipeline dei payload RSC consentono a una richiesta appositamente costruita di contaminare una risposta in cache. Precondizione: memorizzate nella cache le risposte RSC in un punto qualsiasi a valle — CDN, reverse proxy, edge di Vercel, Cloudflare. È questa la vulnerabilità rilevante per il mio stack.

XSS, due avvisi. CVE-2026-44581 (Moderate) nelle app con App Router che generano nonce CSP, più un XSS negli script beforeInteractive che ricevono input non attendibile. Precondizioni: distribuite una CSP con nonce oppure passate input utente a un tag script beforeInteractive.

Annotate le precondizioni soddisfatte dal vostro deployment: quello è il vostro elenco reale. Per omidsaffari.com il quadro è questo: cluster di bypass del middleware (sì), SSRF (no, hosting Vercel), DoS RSC (sì, upstream), DoS di Cache Components (no, non abilitato), cache poisoning RSC (sì, con effetto amplificato), XSS dei nonce CSP (sì), XSS beforeInteractive (no). Otto avvisi High/Moderate si riducono ai cinque che mi riguardano, e quello con il raggio d'impatto maggiore non è il più famoso.

Perché l'SSRF che compare in ogni screenshot probabilmente non è il vostro problema, mentre il cache poisoning sì

CVE-2026-44578 richiede che il server Node di next start gestisca l'upgrade WebSocket e segua il redirect. Vercel non instrada le mie richieste attraverso quel server in modo da rendere raggiungibile il percorso SSRF: la piattaforma termina i WebSocket e l'endpoint dei metadati si trova dietro IMDSv2, con un hop limit che comunque non supererebbe quel tragitto. La presenza di Cloudflare davanti non cambia la conclusione. In una topologia Vercel + Cloudflare, lo screenshot spettacolare non si materializza.

Con l'avviso sul cache poisoning RSC accade l'opposto. La vulnerabilità si trova nel percorso di gestione attraversato da tutte le richieste e produce un payload RSC contaminato, cioè l'albero React serializzato ricevuto dai lettori. Sul mio sito quel payload non resta legato alla richiesta dell'attaccante, ma arriva qui:

Cache-Control: public, s-maxage=300, stale-while-revalidate=86400
Cache-Tag: article:nextjs-may-2026-security-triage

s-maxage=300 fa conservare la risposta a Cloudflare per cinque minuti. stale-while-revalidate=86400 permette di continuare a servirla per un giorno dopo la scadenza mentre la rivalidazione avviene in background. Il Cache-Tag è il mio meccanismo di purge: quando pubblico una nuova revisione, il webhook di revalidate avvia il purge del tag e l'oggetto viene eliminato.

Seguiamo il percorso di una risposta contaminata. L'attaccante richiama una rotta sfruttando la collisione del cache busting. Cloudflare vede una risposta memorizzabile, la salva sotto la chiave di cache di quell'URL e le assegna il tag article:<slug>. Da quel momento, ogni visitatore dello slug riceve dall'edge il payload RSC contaminato: non arriva dall'origine, non attraversa alcun middleware e non incontra le regole WAF aggiunte dieci minuti più tardi. L'oggetto compromesso è già a valle. Rimane lì finché non scade la finestra s-maxage o la mia pipeline di pubblicazione non esegue un purge. Le regole WAF all'origine non possono intervenire su una risposta già distribuita in 300 PoP.

Per questo l'asset a rischio è la superficie dei contenuti pubblicati — l'output del motore di contenuti — non un'API interna. Nell'elenco dei 13 avvisi, l'SSRF è classificato High e questa vulnerabilità Moderate. Su un sito RSC con cache davanti, l'ordine dell'impatto pratico si capovolge.

Come aggiornare, passo per passo, senza cadere nella trappola del follow-up per Turbopack

Primo passaggio: verificate la versione effettivamente installata. Se l'intervallo usa il simbolo caret, package.json non dice la verità sulla versione risolta; controllate il lockfile.

bun pm ls | grep next
# or
npm ls next

Poi fissate la versione a 16.2.6 (ramo Next.js 16) oppure 15.5.18 (ramo Next.js 15). Non 16.2.5. Non 15.5.16.

bun add next@16.2.6
# or
npm install next@16.2.6 --save-exact

Il pin esatto serve a evitare la trappola di cui quasi nessuno parla. Le correzioni dei 13 avvisi originali sono arrivate nelle versioni 16.2.5 / 15.5.16 il 6 maggio. Il 7 maggio Vercel ha pubblicato GHSA-26hh-7cqf-hhc6, il follow-up a una correzione incompleta del bypass del middleware tramite segment-prefetch che restava sfruttabile quando la richiesta passava da Turbopack. Chi non usava Turbopack era protetto con 16.2.5 / 15.5.16; chi lo usava, no. La correzione completa è nelle versioni 16.2.6 / 15.5.18.

Per i rami 13.x o 14.x non arriverà alcuna patch: Vercel non effettuerà il backport. La soluzione è migrare a 15.x o 16.x, pianificando il lavoro come una migrazione e non come un semplice bun update. Per un'app non banale va messa in conto almeno una settimana: la superficie interessata dalle breaking change è concreta, soprattutto nei matcher del middleware e nei comportamenti predefiniti di caching dell'App Router.

Una volta completato il deployment, svuotate la cache edge. È il passaggio che manca in tutti gli altri approfondimenti che ho letto questa settimana. Senza purge, ogni payload RSC memorizzato da Cloudflare prima che la patch entrasse in produzione resta al suo posto — potenzialmente contaminato, se qualcuno ha sfruttato la vulnerabilità in quella finestra — e continua a essere servito dall'edge fino alla scadenza di s-maxage. Nel mio stack:

curl -X POST "https://api.cloudflare.com/client/v4/zones/$ZONE/purge_cache" \
  -H "Authorization: Bearer $CF_API_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"purge_everything": true}'

Poi verificate il risultato. Scegliete una rotta protetta dall'autenticazione del middleware, ricreate la forma dell'URL di segment-prefetch descritta nell'avviso e ripetete la richiesta in produzione. Dovreste ricevere un 401 / 302 / o qualunque risposta restituisca il vostro middleware alle richieste non autenticate. Se ottenete un 200 con del contenuto, la patch del middleware non è stata applicata: il problema è nel deployment, non in Next.js.

Che cosa si è rotto con la 16.2.6, senza giri di parole

La realtà è che non si tratta di semplici patch di sicurezza. Diverse correzioni cambiano intenzionalmente il routing e il comportamento delle chiavi di cache, perché le vulnerabilità si trovavano proprio nel routing e nelle chiavi di cache. È quindi normale aspettarsi differenze.

Matcher del middleware più restrittivi per gli URL .rsc e segment-prefetch. La correzione del bypass tramite segment-prefetch ha modificato la logica di corrispondenza dei matcher. Se un pattern dipendeva dalla forma precedente — in particolare se usavate un negative lookahead per escludere i percorsi _next dando per scontato che .rsc si trovasse sempre al loro interno — verificatelo di nuovo. Ho dovuto ampliare un matcher per intercettare esplicitamente il suffisso segment-prefetch su una rotta protetta. Una correzione da cinque minuti, ma senza un replay test sarebbe diventata una regressione silenziosa.

Gestione dei nonce CSP. La correzione XSS (CVE-2026-44581) cambia la propagazione dei nonce nel rendering dell'App Router. Se generate i nonce nel middleware e li richiamate in un componente Script, mantenete la CSP in modalità report-only per un giorno dopo il deployment. Io non ho rilevato violazioni, ma il cambiamento è reale e un team mi ha riferito di aver dovuto aggiornare il proprio flusso di generazione dei nonce.

Cambiamento di comportamento di Cache Components. Se usate Cache Components nel percorso interessato dalla correzione del DoS per esaurimento delle connessioni, cambia il modo in cui i cache miss vengono aggregati sotto carico. Ritestate i percorsi più sollecitati. Io non uso Cache Components, quindi non è stato necessario.

La checklist di verifica che ho eseguito prima di considerare concluso l'aggiornamento:

[ ] next version pinned to 16.2.6 in lockfile
[ ] middleware auth replay on /admin via segment-prefetch URL → 401
[ ] middleware auth replay via .rsc URL → 401
[ ] RSC cache key sanity: same URL, two clients, identical payload
[ ] forced edge purge after deploy
[ ] CSP report-only on for 24h with no new violations
[ ] one full revalidate cycle on a high-traffic page

Prevedete un passaggio in staging. Non è un aggiornamento di patch a rischio zero, perché le correzioni di sicurezza modificano deliberatamente il routing e il comportamento delle chiavi di cache. La differenza tra un deployment di martedì pomeriggio e un incidente di martedì sera sta nell'aver sottoposto a replay test i percorsi di autenticazione prima di passare in produzione.

Applicate la patch, non affidatevi al WAF: la lezione strutturale

Per questa release Vercel non ha distribuito regole WAF. Il changelog afferma che applicare le patch è l'unica mitigazione completa, e ha ragione: nessuno di questi avvisi può essere filtrato in modo pulito all'edge, perché le forme delle richieste malevole si sovrappongono troppo a quelle legittime. Il 6 maggio Cloudflare ha distribuito regole WAF e mitigazioni negli adapter dei framework come defense in depth, non come alternativa all'aggiornamento. Il testo va letto con attenzione: il changelog di Cloudflare chiarisce che le regole WAF riducono l'esposizione durante la finestra di rollout, non dopo.

È questa la lezione strutturale della settimana. Uno stack in grado di aggiornare un framework, eseguire un nuovo deployment e svuotare la cache edge in un solo pomeriggio trasforma una divulgazione coordinata di 13 CVE in una normale attività del martedì. Uno stack che non può farlo — perché l'aggiornamento richiede una migrazione, perché manca un meccanismo di purge, perché la pipeline di deployment prevede gate manuali — resta esposto per tutta la durata del rollout. Giorni. A volte settimane.

È lo stesso principio dell'argomento sul raggio d'impatto degli agenti: una capacità strutturale di recupero rapido batte il filtraggio reattivo. Non si può impedire ogni richiesta malevola, così come non si può impedire ogni chiamata errata di un agente. Si costruisce invece il sistema affinché, quando accade, la finestra di risposta si misuri in minuti e il raggio d'impatto sia limitato dalla topologia, non dalla speranza.

Aggiornate questa sera. Fissate la versione a 16.2.6 o 15.5.18. Subito dopo, svuotate la cache. La CVE da screenshot non è la priorità: conta la vulnerabilità Moderate che può toccare ogni pagina in cache.