NGINX, Next.js e Drupal sotto patch: RCE nel cuore del Web

🛡️ Executive Summary

• NGINX 1.30.6 e 1.31.7 correggono cinque vulnerabilità, comprese tre falle di memoria che in configurazioni specifiche possono arrivare al crash dei worker e alla possibile esecuzione di codice.
• Next.js 15.5.28 e 16.4.1 chiudono due RCE critiche e un DoS: sono coinvolti Image Optimization, Cache Components e Server Actions.
• Drupal corregge CVE-2026-108097 nel modulo Field UI: il Core da solo non offre un percorso diretto, ma moduli contribuiti possono rendere possibile una RCE anche senza autenticazione.

Tre componenti collocati in punti differenti dello stack Web hanno ricevuto nello stesso ciclo correzioni che meritano priorità immediata: NGINX sul fronte server e reverse proxy, Next.js sul framework applicativo e Drupal sul CMS. Il denominatore comune non è soltanto la presenza di vulnerabilità critiche, ma la posizione occupata da questi software: elaborano richieste provenienti da Internet, trasformano contenuti e spesso operano direttamente davanti ai dati e alla logica applicativa. Il 14 ottobre NGINX ha corretto cinque CVE nelle release 1.30.6 stable e 1.31.7 mainline; Vercel ha pubblicato Next.js 15.5.28 e 16.4.1 dopo due nuove RCE critiche e un problema di denial of service; Drupal Security Team ha distribuito una patch per CVE-2026-108097, RCE classificata Critical nel modulo Field UI. La priorità non consiste quindi nel leggere tre advisory separati, ma nel verificare quale parte della propria catena Web stia ancora eseguendo codice vulnerabile.

NGINX corregge cinque falle e tre possono arrivare alla corruzione della memoria

NGINX 1.30.6 e 1.31.7 correggono CVE-2026-15176, CVE-2026-93479, CVE-2026-95101, CVE-2026-97629 e CVE-2026-97205. Le prime due sono buffer overflow legati rispettivamente alla combinazione di alias e rewrite e alla valutazione di espressioni con variabili; CVE-2026-97205 è invece un use-after-free in scenari che combinano asynchronous file I/O e Server Side Includes. Tutte richiedono configurazioni specifiche, quindi non ogni server NGINX è automaticamente sfruttabile, ma la superficie è delicata perché un aggressore remoto non autenticato può raggiungere direttamente il worker attraverso richieste manipolate. In determinate condizioni le falle di memoria possono provocare crash ripetuti e, quando le mitigazioni come ASLR vengono superate o non sono disponibili, creare un percorso verso l’esecuzione di codice. Il problema prosegue una sequenza già osservata con CVE-2026-42533, il precedente heap buffer overflow NGINX capace di produrre DoS e possibile RCE.

Le altre due vulnerabilità agiscono invece sul traffico e sulle sessioni. CVE-2026-95101 riguarda HTTP/3: con proxy_request_buffering abilitato un attaccante remoto può iniettare dati nella richiesta inoltrata all’upstream, alterando il confine tra ciò che NGINX riceve e ciò che l’applicazione backend interpreta. CVE-2026-97629 interessa invece la rotazione delle chiavi utilizzate dai TLS session ticket e può portare alla falsificazione di sessioni in condizioni specifiche. Per NGINX Open Source la soglia è netta: sono considerate corrette 1.30.6 e 1.31.7 o successive. Il dato operativo è particolarmente importante nei deployment containerizzati e Kubernetes, dove controllare soltanto la versione installata sull’host può non rilevare proxy o ingress controller rimasti dentro immagini precedenti.

Leggi anche: Nginx Rift trasforma vecchie configurazioni in nuovi percorsi di attacco

Next.js chiude due RCE critiche e un DoS fuori dal normale ciclo

Per Next.js il quadro è ancora più urgente di quanto suggerisca il riferimento a “due falle”. La release del 14 ottobre interviene su tre problemi: due remote code execution critiche e un denial of service High. La prima RCE riguarda l’Image Optimization API e una vulnerabilità memory-related in una libreria upstream: su sistemi Linux basati su glibc l’elaborazione di SVG controllabili dall’attaccante può portare a esecuzione di codice. Sono interessate le versioni fino a 15.5.27 e 16.4.0; le release corrette sono 15.5.28 e 16.4.1, mentre chi non può aggiornare immediatamente deve almeno assicurarsi di utilizzare sharp 0.35.5 o superiore. Il precedente ciclo di RCE Next.js dell’agosto 2026 aveva già mostrato quanto la pipeline di trasformazione delle immagini possa portare codice non fidato dentro dipendenze native eseguite dal server.

La seconda RCE, GHSA-673q-mjm6-r5xr, interessa Next.js 16 nelle applicazioni App Router che utilizzano Cache Components e presentano una funzione use cache capace di restituire più typed array. Il punteggio CVSS raggiunge 9,5 e non esiste un workaround indicato: Vercel raccomanda l’upgrade immediato a 16.4.1. A questo si aggiunge GHSA-p3m5-59mp-jv5r, DoS con CVSS 8,2: richieste appositamente costruite contro applicazioni App Router che espongono almeno una Server Action possono provocare consumo eccessivo di CPU e bloccare l’elaborazione delle altre richieste nello stesso processo. Le applicazioni che utilizzano esclusivamente Pages Router o non impiegano Server Actions non ricadono in questo specifico vettore. La distinzione conta perché consente di stabilire l’esposizione, ma non cambia la remediation consigliata: aggiornare e ridistribuire l’applicazione.

Drupal ha una RCE nel Field UI ma il vero rischio nasce dalla composizione dei moduli

Drupal Security Team classifica CVE-2026-108097 come Critical, 19 su 25, e individua la vulnerabilità nel modulo Field UI del Core. Sono interessate le versioni precedenti a Drupal 10.6.19, 11.3.19 e 11.4.10, oltre alle prime beta della linea 12. Il dettaglio più importante è che Drupal Core da solo non espone direttamente il percorso completo verso la RCE, ma esistono diverse catene di sfruttamento attraverso moduli contribuiti e almeno una di queste non richiede autenticazione. Anche codice custom può rendere raggiungibile la funzionalità vulnerabile. Questo rende pericoloso valutare l’esposizione soltanto guardando il Core: due installazioni della stessa versione possono avere rischio differente in funzione di moduli e personalizzazioni. Il tema è già emerso con precedenti vulnerabilità che coinvolgevano Drupal e altri componenti dell’infrastruttura Web, dove la composizione dello stack determinava l’effettivo percorso di compromissione.

Chi non può aggiornare immediatamente può disinstallare temporaneamente il modulo field_ui, mitigazione esplicitamente indicata dal Drupal Security Team. Non è però una soluzione equivalente alla patch: serve a rimuovere il componente vulnerabile mentre viene organizzato l’aggiornamento. Le installazioni su rami Drupal ormai end-of-life richiedono particolare attenzione perché possono risultare vulnerabili senza ricevere una release ufficiale corretta della propria major. Per gli ambienti realmente esposti, quindi, il controllo dovrebbe comprendere Core, contributed modules e codice personalizzato, non soltanto il numero di versione riportato dall’interfaccia amministrativa.

Chi rischia: reverse proxy, applicazioni Node self-hosted e CMS pubblici

Il rischio maggiore riguarda infrastrutture direttamente esposte a Internet, soprattutto quando la stessa organizzazione utilizza più livelli coinvolti contemporaneamente. Un NGINX vulnerabile può trovarsi davanti a un’applicazione Next.js, che a sua volta può convivere nello stesso perimetro con portali Drupal. In questo scenario una singola scansione di vulnerabilità non basta: bisogna sapere quale versione gira realmente nel container, quali feature del framework sono abilitate, quali moduli Drupal risultano attivi e quali configurazioni NGINX vengono ereditate da template o chart. La vulnerabilità più grave non è necessariamente quella con il CVSS maggiore, ma quella raggiungibile nella configurazione realmente esposta. Il problema dei CMS non aggiornati è stato dimostrato in modo quasi didattico quando ShinyHunters ha compromesso il leak site di Clop sfruttando Grav CMS: la patch disponibile non serve se la release vulnerabile resta quella effettivamente in produzione.

Come mitigare: patch prima i componenti che elaborano input non autenticato

La risposta operativa parte dall’inventario. NGINX Open Source deve essere portato almeno a 1.30.6 stable o 1.31.7 mainline e le organizzazioni devono verificare immagini container e prodotti derivati, non soltanto il pacchetto di sistema. Next.js deve essere aggiornato a 15.5.28 o 16.4.1, seguito da una nuova build e redeploy che elimini anche eventuali deploy preview o staging dimenticati; chi dipende direttamente da Sharp deve controllare che la libreria sia almeno alla 0.35.5. Drupal deve passare a 10.6.19, 11.3.19, 11.4.10 o alla release corretta della linea 12, disinstallando field_ui se la patch non può essere applicata immediatamente. Per tutti e tre i prodotti è necessario verificare i log successivamente all’aggiornamento: la patch impedisce nuovi exploit, ma non dimostra che l’ambiente non sia già stato compromesso.

Continua con:

WordPress Click2Shell installa temi senza consenso e può arrivare alla RCE

ShinyHunters buca Clop: una falla Grav trasforma il leak site in bersaglio

Il problema non è il singolo bug ma quante volte il Web esegue codice al posto dell’utente

NGINX, Next.js e Drupal mostrano tre varianti dello stesso problema architetturale. Il Web moderno affida enormi quantità di input non fidato a componenti che devono trasformarlo, instradarlo, memorizzarlo o interpretarlo. NGINX manipola richieste e memoria dei worker; Next.js trasforma immagini, serializza dati e gestisce funzioni server-side; Drupal compone funzionalità Core, moduli contribuiti e codice personalizzato. Più lo stack diventa modulare, più il confine di sicurezza attraversa componenti differenti e più una vulnerabilità apparentemente locale può diventare RCE quando viene inserita nella combinazione giusta. La conseguenza per chi gestisce infrastrutture Web è concreta: patchare il CMS senza conoscere il reverse proxy o aggiornare il framework senza controllarne le dipendenze native non è più sufficiente. Il perimetro reale è l’intera catena che riceve una richiesta Internet e la trasforma in codice, contenuto o accesso ai dati.