Drupal corregge una RCE critica: Field UI può aprire la strada senza login

Il 14 ottobre 2026 il Drupal Security Team ha pubblicato l’avviso SA-CORE-2026-014 per CVE-2026-108097, una vulnerabilità di esecuzione remota di codice nel modulo Field UI del core, classificata critica con 19 punti su 25 nella scala del progetto. Le release corrette per i rami supportati sono Drupal 10.6.19, 11.3.19 e 11.4.10. Per capire se un sito è esposto bisogna distinguere la versione del core, lo stato di Field UI e gli eventuali percorsi aperti dal codice aggiuntivo.

Il core da solo non offre un percorso diretto per sfruttare la falla. I moduli contribuiti possono però rendere raggiungibile la funzione vulnerabile e almeno un percorso noto non richiede autenticazione; anche il codice personalizzato può esporla. La ricostruzione di SecurityWeek distingue questa vulnerabilità di Field UI dalla falla separata del modulo Entity List e, alla pubblicazione del 19 ottobre, non riportava attacchi osservati contro la prima.

Quando Field UI diventa un percorso di attacco

Field UI è il modulo del core che fornisce le funzioni amministrative per gestire i campi. La vulnerabilità si trova in quel componente, ma la sua presenza nel pacchetto Drupal non equivale da sola a un ingresso utilizzabile da un visitatore. La condizione decisiva è che un modulo contribuito o una personalizzazione faccia arrivare dati controllabili da una richiesta alla funzione vulnerabile.

Questo spiega perché la richiesta di login sulle normali pagine di amministrazione non basta a escludere il rischio. Un’estensione può creare un percorso diverso verso la stessa funzione, con condizioni di accesso proprie. La valutazione deve quindi riguardare la configurazione effettivamente installata e il comportamento dei moduli che interagiscono con Field UI, non soltanto i permessi delle pagine amministrative standard.

La ricerca di laboratorio Fortbridge mostra il meccanismo attraverso il callback #region_callback: un modulo sintetico collega richieste HTTP alle righe elaborate da Field UI, confrontando Drupal 11.4.9 con la release corretta 11.4.10 in un ambiente isolato. Il modulo usato nella prova è stato costruito per il test; la sua presenza nel laboratorio non identifica un’estensione contribuita da cercare negli inventari dei siti pubblici.

Il risultato chiarisce la differenza fra due domande operative. Verificare che Field UI sia installato individua i siti su cui la mitigazione può avere effetto. Esaminare i moduli aggiuntivi e il codice personalizzato serve invece a capire se, prima della correzione, esistesse un percorso sfruttabile dall’esterno e se quel percorso richiedesse credenziali.

Le versioni Drupal interessate

Nei rami supportati sono vulnerabili Drupal 10.6.x precedenti a 10.6.19, 11.3.x precedenti a 11.3.19 e 11.4.x precedenti a 11.4.10. Per le prerelease di Drupal 12, l’intervallo indicato va da 12.0.0-alpha1 fino alle versioni anteriori a 12.0.0-beta2. Quella soglia appartiene al ramo di sviluppo e non cambia la scelta della release corretta per un sito in produzione sui rami supportati.

La stessa vulnerabilità interessa anche versioni più vecchie comprese nell’intervallo dell’avviso, ma il loro stato di supporto cambia la risposta. Drupal 8 e 9, i rami 10.5.x e precedenti e i rami 11.2.x e precedenti non ricevono più copertura di sicurezza. Restare su uno di questi rami significa non poter applicare la correzione mantenendo la vecchia linea di release: occorre programmare il passaggio a una versione supportata.

Il numero mostrato nell’inventario del codice deve corrispondere a quello realmente eseguito dal sito dopo il rilascio. Se più installazioni condividono repository o pacchetti, ciascuna va considerata secondo la propria versione distribuita e i propri moduli attivi. Anche un ambiente non pubblico può richiedere attenzione quando usa lo stesso codice aggiuntivo dell’installazione esposta.

Patch e disinstallazione temporanea sono percorsi distinti

Aggiornare il core alla release corretta elimina la vulnerabilità nelle versioni supportate. Disinstallare temporaneamente field_ui è la mitigazione prevista mentre l’aggiornamento attende il change control: rimuove il componente interessato, ma interrompe anche le sue funzioni amministrative. Prima della modifica occorre verificare le dipendenze dei moduli presenti sul sito e prevedere come gestire i campi durante l’attesa.

La sequenza di intervento può essere concentrata sui dati che cambiano davvero la decisione:

1. Registrare la versione del core in esecuzione, lo stato di installazione di Field UI e i moduli contribuiti o personalizzati che intervengono nella gestione dei campi. Un elenco dei soli pacchetti presenti nel repository non mostra necessariamente quali componenti siano attivi sul sito.
2. Distribuire la release corretta del ramo supportato e verificare, dopo il rilascio, la versione effettivamente in uso. Controllare anche le funzioni amministrative dei campi e le integrazioni personalizzate coinvolte nella modifica.
3. Se la patch deve attendere, valutare la disinstallazione di field_ui come misura temporanea, annotando quando è stata applicata. Ripristinare il modulo soltanto dopo l’aggiornamento e la verifica delle funzioni che ne dipendono.

Drupal Steward protegge alcuni percorsi di attacco conosciuti, ma la copertura dichiarata non comprende tutti quelli possibili. La presenza del servizio non sostituisce quindi l’aggiornamento del core. Sui rami fuori supporto, la mitigazione temporanea e la migrazione a una release coperta rispondono a esigenze diverse: la prima riduce l’esposizione immediata, la seconda rende disponibile la correzione.

Che cosa cercare dopo l’intervento

Per un sito che ha eseguito una versione interessata con Field UI installato, la verifica non finisce quando la patch viene distribuita. I log del server web e dell’applicazione possono aiutare a ricostruire richieste anomale dirette a form, pagine amministrative o percorsi introdotti dai moduli aggiuntivi. La ricerca deve usare le rotte e le integrazioni presenti su quella specifica installazione: la prova di laboratorio non fornisce un indicatore universale di compromissione.

Una richiesta insolita, da sola, non dimostra che sia stato eseguito codice. Se emergono segnali sospetti, orari e richieste vanno confrontati con errori applicativi e modifiche inattese a file o configurazione, conservando i dati utili all’analisi. Quando compaiono modifiche che non hanno una spiegazione amministrativa, l’installazione della patch chiude la falla ma non chiarisce che cosa sia accaduto prima: serve un’indagine sull’istanza interessata.

Leggi anche:

• WordPress 7.1.2 chiude una falla critica già sfruttata negli attacchi
• Matomo senza cookie: una riga di codice non elimina ogni obbligo
• #adv non basta sempre: come segnalare una sponsorizzazione in Italia