Due vulnerabilità critiche, due superfici di attacco diverse

Il 25 agosto 2026 il team di Next.js ha rilasciato un aggiornamento di sicurezza fuori dal normale ciclo di rilascio, anticipando la pubblicazione dopo aver identificato una seconda vulnerabilità critica in una dipendenza upstream mentre stava già preparando la patch per la prima. Il risultato sono due falle di Remote Code Execution non autenticata con severità critica, entrambe corrette nelle versioni 15.5.24 (Maintenance LTS) e 16.3.3 (Active LTS). Per chi gestisce applicazioni Next.js in produzione, specialmente self-hosted, questo è un aggiornamento da applicare senza rimandare.

CVE-1: RCE tramite l’Image Optimization API su file AVIF

La prima vulnerabilità (GHSA-2xp9-vwfh-vxw4, CVSS stimato 9.5) risiede in libheif, la libreria usata da sharp per la decodifica delle immagini AVIF, a sua volta impiegata dall’Image Optimization API integrata in Next.js. La falla upstream (GHSA-g89c-p67h-r497) è un heap buffer overflow nel codice di scaling delle immagini: un file AVIF costruito ad arte, con riferimenti annidati di tipo identity-derivation e auxiliary item, induce il decoder a costruire un’immagine con una profondità di bit del canale Alpha incoerente rispetto al buffer allocato. Lo scaler alloca spazio per dati a 8 bit ma vi scrive valori a 16 bit, scrivendo circa 16.384 byte oltre il limite dell’allocazione: la combinazione classica che apre la strada all’esecuzione di codice arbitrario.

L’aspetto più critico è la superficie di attacco: qualunque endpoint Next.js che passi un’immagine controllata dall’utente attraverso l’Image Optimization API (upload di avatar, contenuti caricati da terzi, immagini remote proxate) è potenzialmente sfruttabile senza autenticazione. Le versioni patchate risolvono il problema nell’immediato disabilitando l’ottimizzazione AVIF finché la fix upstream in libheif non sarà completamente propagata nella supply chain.

CVE-2026-75604: RCE su server Windows con Pages Router + App Router

La seconda falla (CVE-2026-75604 / GHSA-p293-qw3h-jr36, CVSS stimato 9.0) è più circoscritta ma non meno seria per chi ospita Next.js su Windows. Colpisce le applicazioni che utilizzano contemporaneamente Pages Router e App Router senza avere Cache Components attivo, quando il server gira su un filesystem Windows: in questo scenario è possibile innescare un path traversal che porta a RCE non autenticata sfruttando le differenze di gestione dei percorsi tra i due router in ambiente Windows.

Linux e macOS non sono affetti da questa specifica vulnerabilità, il che la rende particolarmente rilevante per ambienti enterprise .NET/Windows Server che ospitano frontend Next.js accanto a backend .NET, uno scenario comune in molte aziende italiane con infrastruttura ibrida. Il team Next.js è stato esplicito: non esiste una mitigazione applicativa nota per le applicazioni Windows-hosted affette; l’unica strada è l’aggiornamento.

Versioni interessate

• Path traversal su Windows (CVE-2026-75604): Next.js 13.4–15.5.23 e 16.0–16.3.2
• RCE via AVIF: Next.js 10.0.0–15.5.23 e tutte le versioni 16.x fino alla 16.3.2
• libheif: tutte le versioni fino alla 1.23.1 inclusa

Come verificare l’esposizione e aggiornare

Il primo passo è capire quale router state utilizzando e se l’Image Optimization API è esposta a input non fidati. Un controllo rapido nella codebase:

# Versione installata di Next.js
npm ls next

# Cercate se esistono sia pages/ che app/ nello stesso progetto
find . -maxdepth 2 -type d \( -name "pages" -o -name "app" \) -not -path "*/node_modules/*"

# Verificate se il Cache Components flag è attivo in next.config
grep -R "cacheComponents" next.config.*

Se il progetto usa entrambi i router senza Cache Components e il server è ospitato su Windows (IIS con iisnode, Windows Server con PM2, container Windows), l’aggiornamento non è opzionale. Per aggiornare:

npm install next@15.5.24   # ramo 15.5 (Maintenance LTS)
npm install next@16.3.3    # ramo 16.3 (Active LTS)

# con pnpm
pnpm add next@15.5.24
pnpm add next@16.3.3

# con yarn
yarn add next@15.5.24
yarn add next@16.3.3

Dopo l’aggiornamento, ricordate di rigenerare il lockfile e di verificare in CI che la build non introduca regressioni, in particolare se il progetto fa uso intensivo di next/image con sorgenti AVIF: l’ottimizzazione per quel formato resterà disabilitata finché non arriverà una fix upstream in libheif, quindi può essere necessario prevedere temporaneamente un fallback a JPEG/WebP per le immagini caricate dagli utenti.

Perché conviene reagire subito, anche se si usa Vercel

Le applicazioni ospitate su Vercel sono protette automaticamente lato piattaforma, ma questo non copre chi fa self-hosting su VM, container Docker, Kubernetes, Azure App Service, IIS o qualunque altro ambiente gestito direttamente. Per i team DevOps italiani che gestiscono deployment Next.js su infrastruttura on-premise o su Windows Server per motivi di compliance o integrazione con sistemi legacy .NET, il rischio è concreto: si tratta di RCE non autenticata, quindi sfruttabile da un attaccante remoto senza credenziali, con impatto potenzialmente totale sul server applicativo.

Alcune azioni consigliate oltre al semplice upgrade:

• Inventariate tutte le applicazioni Next.js in produzione, incluse quelle gestite da team diversi, e verificate la versione installata con npm ls next o controllando il package-lock.json.
• Se non potete aggiornare immediatamente, valutate di disabilitare temporaneamente l’Image Optimization API per sorgenti non fidate, o di filtrare a livello di reverse proxy/WAF le richieste verso l’endpoint /_next/image.
• Per gli ambienti Windows, se non è possibile aggiornare a breve, considerate la migrazione temporanea del workload su un host Linux/macOS finché la patch non è applicata, dato che non esiste mitigazione nota per Windows.
• Automatizzate il monitoraggio delle security advisory di Next.js e delle sue dipendenze critiche (in particolare sharp e le librerie di decodifica immagini) tramite Dependabot, Renovate o strumenti equivalenti, per ridurre il tempo di reazione a futuri annunci simili.

Conclusione

Questo doppio rilascio di sicurezza è un promemoria utile su due fronti. Il primo è tecnico: le pipeline di elaborazione immagini, spesso trattate come funzionalità “di contorno”, restano una delle superfici di attacco più insidiose nelle applicazioni web moderne, perché processano input binario complesso proveniente direttamente dagli utenti. Il secondo è organizzativo: la disponibilità di RCE non autenticate senza mitigazione nota per specifiche piattaforme (in questo caso Windows) impone di conoscere esattamente dove e come sono ospitate le proprie applicazioni Next.js, non solo quale versione del framework stanno eseguendo. Chi gestisce ambienti misti Windows/.NET con frontend Next.js dovrebbe trattare questo aggiornamento come priorità operativa immediata.

Fonte: Next.js – August 2026 Security Release e The Hacker News – Next.js Patches Critical AVIF and Windows Flaws Enabling Unauthenticated RCE