Drupal, falla critica in Field UI: installa subito la patch! (aggiornato: 16 ottobre 2026, ore 19:39)

Una funzione PHP che esegue qualunque callable le venga passata, nascosta nel codice che disegna le tabelle di amministrazione dei campi. È il cuore di CVE-2026-108097, la vulnerabilità di esecuzione di codice da remoto che il Drupal Security Team ha corretto il 14 ottobre 2026 con l'advisory SA-CORE-2026-014. Il componente coinvolto è Field UI (field_ui), un modulo che il profilo di installazione Standard attiva di default. Si trova quindi su qualunque sito costruito a partire da quel profilo, a meno che qualcuno non l'abbia rimosso. Sulla scala di rischio di Drupal la falla ottiene 19 punti su 25, cioè la fascia "critica". Per chi amministra un sito Drupal la priorità è aggiornare prima che compaia un exploit pubblico.

Un callback eseguito alla cieca

Field UI costruisce le tabelle di amministrazione a partire dai render array, gli array PHP che Drupal trasforma in HTML. Prima della correzione, la fase di pre-render dell'elemento tabella eseguiva tramite call_user_func_array qualsiasi callable PHP contenuto nella proprietà #region_callback di ciascuna riga. Chi riesce a controllare quel valore, quindi, sceglie quale codice far girare sul server.

La correzione è drastica: il core non chiama più la funzione impostata in #region_callback quando assegna le righe alle regioni nelle tabelle riepilogative di Field UI. Il meccanismo, semplicemente, non esiste più.

C'è però una sfumatura importante. Secondo l'advisory, Drupal core da solo non è direttamente sfruttabile. I percorsi di attacco passano dai moduli contribuiti e ce ne sono diversi. Almeno uno di questi non richiede alcuna autenticazione. Anche il codice personalizzato può esporre la funzionalità vulnerabile.

L'advisory non dice però quali moduli aprano la strada. Un amministratore non può quindi controllare se il proprio sito compare in una lista, e la valutazione del rischio resta incerta. L'unica risposta sicura è aggiornare.

La segnalazione è attribuita a Drew Webber, membro del Security Team, e a Octavio Galland. Nello stesso giorno sono stati pubblicati cinque advisory: oltre a questo, una seconda RCE critica nel modulo contribuito Entity List (SA-CONTRIB-2026-218, CVE-2026-108099, anch'essa 19/25 e non sfruttabile da sola) e tre vulnerabilità XSS, nel core e nel tema di amministrazione Gin.

Le versioni corrette, ramo per ramo

Per ogni ramo ancora gestito esiste una release che chiude la falla.

• Drupal 11.4.x: aggiornare a 11.4.10
• Drupal 11.3.x: aggiornare a 11.3.19
• Drupal 10.6.x: aggiornare a 10.6.19
• Drupal 12: le versioni da alpha1 a beta1 sono vulnerabili, la correzione è in 12.0.0-beta2 (da non usare in produzione)
• Drupal 7: corretto nella versione 7.107, distribuita tramite il servizio LTS di Pantheon in collaborazione con Tag1 Consulting, senza costi aggiuntivi

Chi è su 11.3.x o 10.6.x deve tenere presente un'altra scadenza: entrambi i rami perderanno la copertura di sicurezza a dicembre 2026. Conviene dunque aggiornare subito e pianificare fin d'ora il passaggio a un ramo ancora supportato.

151.442 siti su rami che non riceveranno patch

Il quadro peggiora per chi è rimasto indietro. Drupal 11.2.x e precedenti, 10.5.x e precedenti, Drupal 9 e Drupal 8.9 sono vulnerabili e non riceveranno alcuna correzione.

I numeri spiegano perché è un problema concreto. Nella settimana iniziata il 4 ottobre, 151.442 siti su 531.499 tra quelli che comunicano la versione del core a drupal.org, cioè il 28,5%, si trovavano su un ramo vulnerabile e privo di correzione. Il dato va letto con cautela: comprende solo i siti che inviano questa informazione e non indica quanti siano davvero attaccabili, dato che lo sfruttamento dipende dai moduli installati. Resta il fatto che oltre un sito su quattro non ha una patch da installare.

Nessun exploit pubblico, per ora

Al momento della pubblicazione dell'advisory non esisteva codice di exploit pubblico. Fino al 15 ottobre non ne sono comparsi, e né l'advisory né le segnalazioni pubbliche descrivono attacchi in corso. Il Security Team, però, il 12 ottobre aveva preannunciato il rilascio e invitato gli amministratori a tenersi del tempo libero, «perché gli exploit potrebbero essere sviluppati nel giro di ore o giorni».

Non è un timore astratto. A maggio, Drupal aveva registrato tentativi di sfruttamento entro due giorni dall'advisory su una SQL injection nel core che colpiva solo i siti con PostgreSQL. Quella falla è poi finita nel catalogo Known Exploited Vulnerabilities della CISA.

Cosa fare adesso

La strada maestra è installare la release corretta per il proprio ramo. Se non è possibile farlo subito, l'advisory indica una soluzione temporanea: disinstallare il modulo field_ui, che «offrirà protezione mentre i siti vengono aggiornati». Il prezzo è che le pagine di amministrazione per gestire i campi e la loro visualizzazione resteranno inaccessibili. Prima di procedere, quindi, conviene verificare dipendenze e flussi di lavoro che si appoggiano a Field UI.

Chi usa Drupal Steward, il servizio WAF con regole scritte dal Security Team e offerto da Acquia, Pantheon, Ironstar e Skpr, ha una protezione parziale: le regole bloccano alcuni vettori di attacco noti, ma non tutti gli exploit possibili. L'aggiornamento resta comunque necessario.

Dopo l'aggiornamento, le note di Pantheon per Drupal 7 consigliano di controllare il codice personalizzato che usa #region_callback, visto che il core non lo esegue più. Vanno poi provate le pagine "Gestisci campi" e "Gestisci visualizzazione". Per chi è su un ramo non più supportato, disinstallare Field UI è un tampone e non una soluzione: senza una migrazione a una versione corretta, il sito resta esposto a ogni modulo contribuito che apra un percorso verso quel callback.

Fonti: drupal.org, cveplayground.com, thehackernews.com, thedroptimes.com