La sicurezza di Drupal è una delle poche aree del mondo dei CMS open source in cui il processo pubblicato vale più della reputazione della piattaforma. Il team di sicurezza Drupal segue un calendario di divulgazione fisso, assegna a ogni avviso un punteggio su una scala numerica documentata e coordina le correzioni sul core e su decine di migliaia di progetti contribuiti.

Il bilancio sul campo è peggiore di quanto quel processo meriti. I siti Drupal vengono compromessi, e la causa non è quasi mai che nessuno lo sapesse. L’avviso era stato pubblicato, puntuale, di mercoledì. La patch è arrivata in produzione la settimana successiva. Quel divario è l’argomento di questo articolo, e hardening, firewall e permessi sui file esistono tutti per renderlo sopravvivibile o per accorciarlo.

Il rischio dipende da quanto in fretta applicate le patch, non dai moduli che vi capita di usare. Gli avvisi sul core arrivano in una finestra mensile del mercoledì e quelli sui progetti contribuiti ogni mercoledì, ciascuno con un punteggio da 0 a 25 su una scala pubblicata. Falle altamente critiche del core sono state sfruttate poche ore dopo la divulgazione: dopo l’avviso di SQL injection del 2014 l’indicazione ufficiale era di trattare qualsiasi sito non aggiornato entro sette ore come già compromesso. Un sito che non riesce a distribuire una patch del core entro una giornata lavorativa porta con sé quasi tutto il rischio esistente.

Come funziona davvero il processo degli avvisi di sicurezza Drupal

Quasi nessuno di chi gestisce un sito Drupal ha mai letto i documenti di processo, ed è un peccato: dicono esattamente quanto preavviso si riceve, in che forma e in quali giorni.

Le finestre di rilascio

Il team di sicurezza pubblica seguendo un calendario. Gli avvisi sui progetti contribuiti escono ogni mercoledì. Il core ha una finestra per correzioni di bug e funzionalità il primo mercoledì del mese e una finestra di rilascio di sicurezza il terzo, come indicato nella documentazione sulle tempistiche dei rilasci di sicurezza. Una finestra non è la promessa che qualcosa uscirà; esiste perché gli amministratori sappiano quali giorni tenere d’occhio.

Ogni tanto c’è un preavviso. Prima di un rilascio del core altamente critico il team può pubblicare un annuncio di servizio pubblico, di solito il lunedì. PSA-2026-05-18 lo ha fatto per il rilascio del 20 maggio 2026, indicando una finestra dalle 17:00 alle 21:00 UTC e invitando i titolari ad aggiornare prima all’ultima patch del proprio ramo, così che i problemi di aggiornamento emergessero presto. Due giorni sono il preavviso massimo che otterrete.

Avvisi del core e avvisi dei progetti contribuiti

Sono due sistemi con garanzie diverse. Gli avvisi del core coprono i rami minori supportati, due alla volta, il più recente e quello precedente. In pratica il calendario dei rilasci del core significa 11.4.x e 11.3.x, con 10.6.x ancora coperto finché Drupal 10 arriva alla fine del ciclo di vita il 9 dicembre 2026. All’inizio di settembre 2026 le versioni correnti sono 11.4.5, 11.3.16 e 10.6.15. Drupal 12.0.0 e 11.5.0 sono attesi nella settimana del 7 dicembre 2026, momento in cui il supporto per 11.3.x e 10.6.x termina.

La copertura dei progetti contribuiti è volontaria e condizionata. Gli avvisi vengono emessi solo per i rilasci stabili nei rami maggiori supportati dei progetti i cui manutentori hanno richiesto e ottenuto la copertura, secondo la politica sul processo e sui permessi degli avvisi di sicurezza. Un modulo su una versione alpha, beta o release candidate resta fuori dal sistema, così come uno il cui manutentore non ha mai aderito. Nessuno dei due fatti è visibile dall’interfaccia di amministrazione mentre il sito funziona normalmente.

Il volume è il carico di lavoro vero. Mercoledì 26 agosto 2026 il team ha pubblicato dieci avvisi su progetti contribuiti in un solo giorno, tutti moderatamente critici. Un sito che usa sessanta moduli verrà nominato più volte all’anno, e quel flusso costa più nel tempo delle emergenze del core.

Il punteggio di rischio, e perché non è CVSS

Ogni avviso porta un numero su 25. La scala si basa sul NIST Common Misuse Scoring System, NISTIR 7864, ed è documentata sulla pagina dei livelli di rischio di sicurezza. Sei metriche la alimentano: complessità di accesso, autenticazione richiesta, impatto sulla riservatezza, impatto sull’integrità, esistenza di un exploit noto e diffusione dei bersagli. Le fasce vanno da non critico da 0 a 4, poco critico da 5 a 9, moderatamente critico da 10 a 14, critico da 15 a 19 e altamente critico da 20 a 25.

Poiché la diffusione dei bersagli fa parte del punteggio, una falla che colpisce solo una configurazione poco comune si colloca più in basso di quanto farebbe con CVSS. SA-CORE-2026-005 del 17 giugno 2026, un problema di PHP object injection tracciato come CVE-2026-55803, ha ottenuto 18 ed è stato classificato critico anziché altamente critico proprio per questo motivo.

Quando un modulo contribuito diventa non supportato

Il team di sicurezza non può obbligare un manutentore volontario a correggere nulla. Quando un manutentore smette di rispondere, la procedura documentata prevede di contrassegnare il progetto come non supportato dopo ripetuti tentativi di contatto. La pagina del progetto avverte allora i titolari di scegliere un’alternativa mantenuta attivamente, oppure di pagare qualcuno perché corregga il difetto così che il modulo possa essere ripubblicato.

Quel consiglio è corretto e costoso, perché quando un modulo viene contrassegnato come non supportato di solito è portante, e sostituirlo significa migrazione dei dati, modifiche ai template e un test di regressione completo. Il momento economico per agire è il rilascio prima dell’abbandono, quando il manutentore è diventato silenzioso ma nulla si è ancora rotto, e quasi nessuno guarda in quel momento.

Drupal 7 è a fine vita, e il supporto esteso non equivale a essere sicuri

Drupal 7 è arrivato a fine vita il 5 gennaio 2025, come confermato in PSA-2025-01-06. Dopo quella data il team di sicurezza ha smesso di fornire supporto e avvisi per il core di Drupal 7 e per i suoi moduli e temi contribuiti. L’annuncio era esplicito: i problemi di sicurezza di Drupal 7 possono ora essere divulgati pubblicamente senza coordinamento, e possono verificarsi zero day.

Esiste un mercato commerciale di supporto esteso. La Drupal Association ha certificato dei fornitori, tra cui HeroDevs e Tag1 Consulting, nell’ambito di un Extended Security Support Provider Program, e questi producono davvero patch. È meglio di niente, ma non è la stessa cosa dell’essere supportati. Il fornitore aggiorna il core e un insieme definito di moduli che ha scelto di coprire, secondo i propri tempi, per i clienti che pagano. Il resto dell’ecosistema da cui dipende il vostro sito resta fuori dal perimetro.

Un CMS non supportato è anche difficile da difendere in un questionario di verifica dei fornitori o davanti a un assicuratore dopo un incidente. La nostra guida su costi, opzioni e scadenze della migrazione Drupal illustra quanto costa l’uscita.

Lo schema storico: Drupalgeddon e ciò che è seguito

Tre incidenti hanno plasmato il modo in cui la comunità pensa alla velocità di aggiornamento. Ognuno era una falla di injection o di esecuzione di codice remoto nel core, e ognuno ha visto sfruttamenti automatizzati di massa nel giro di ore o giorni.

La finestra di sette ore dell’ottobre 2014

Il Drupalgeddon originale è stato SA-CORE-2014-005, pubblicato il 15 ottobre 2014. CVE-2014-3704 era una falla di SQL injection nel livello di astrazione del database di Drupal 7, sfruttabile da utenti anonimi, con punteggio pieno di 25 su 25. Ogni sito Drupal 7 sotto la 7.32 era interessato.

È stato il seguito a renderlo una pietra miliare. PSA-2014-003 ha comunicato ai titolari che attacchi automatizzati avevano iniziato a compromettere siti non aggiornati entro poche ore dall’annuncio, e che dovevano dare per scontato che qualsiasi sito non aggiornato entro le 23:00 UTC di quel giorno, sette ore dopo la pubblicazione, fosse stato compromesso. Non che potesse esserlo. Che lo era. L’avviso metteva in guardia sul fatto che gli attaccanti potessero aver preso tutti i dati e installato backdoor, ed è questo che trasforma un problema di patch in un problema di risposta agli incidenti.

Drupalgeddon 2 e 3

SA-CORE-2018-002, pubblicato il 28 marzo 2018, era CVE-2018-7600: una falla di esecuzione di codice remoto su più sottosistemi in Drupal 7 e Drupal 8, con punteggio 24 su 25. Riguardava Drupal dalla 7.0 alla 7.57 e i rami 8.x fino alla 8.5.0, e gli exploit pubblici sono arrivati nel giro di circa due settimane.

Quattro settimane più tardi è arrivato SA-CORE-2018-004, il 25 aprile 2018. CVE-2018-7602 era un’altra falla di esecuzione di codice remoto in codice affine, con punteggio 20 su 25, e l’avviso dichiarava che era già sfruttata in rete. L’intervallo è la lezione: i siti che avevano aggiornato a marzo e poi avevano smesso di prestare attenzione si sono ritrovati esposti di nuovo ad aprile.

Maggio 2026, e ciò che non è cambiato

Lo schema non è storia. SA-CORE-2026-004 è stato pubblicato il 20 maggio 2026: CVE-2026-9082, una falla di SQL injection che riguarda i siti su PostgreSQL, valutata altamente critica con 23 su 25 e relativa a tutti i rami dalla 8.9 fino alla 11.3.9. Il 22 maggio alle 04:30 UTC l’avviso è stato modificato per registrare tentativi di sfruttamento rilevati in rete, meno di 48 ore dalla pubblicazione agli attacchi osservati.

Nulla di tutto ciò è una critica al team di sicurezza. Ha dato due giorni di preavviso, ha rilasciato dentro la finestra annunciata e ha aggiornato l’avviso quando il quadro è cambiato. La modalità di guasto sta dal lato di chi gestisce: nessun percorso provato che porti da un avviso a un sito di produzione aggiornato.

Dove la sicurezza Drupal fallisce davvero nella pratica

Il core fa notizia ed è la parte minore. Nei siti che verifichiamo il riscontro che conta è raramente un rilascio del core non aggiornato, perché gli aggiornamenti del core compaiono nell’interfaccia di amministrazione e qualcuno se ne accorge. L’esposizione sta altrove.

L’inventario dei moduli che nessuno ha

Un sito Drupal di medie dimensioni usa fra quaranta e ottanta moduli contribuiti, ciascuno con un manutentore e una cadenza propri. La domanda a cui quasi nessuno sa rispondere su due piedi è quali di essi abbiano ancora un manutentore attivo, quali siano coperti dalla politica degli avvisi e quali non ricevano un commit da due anni. Produrre quell’elenco richiede un pomeriggio.

Il modulo su misura di cui nessuno risponde

Il riscontro grave più comune è un modulo su misura scritto da un consulente che se n’è andato. Di solito fa qualcosa di forma integrativa: un flusso verso il CRM, un gestore di form specifico, una callback di pagamento. È stato scritto su una API più vecchia, non ha test e nessuno nel team sa dire che cosa valida. Il codice su misura sta fuori dal sistema degli avvisi per definizione: nessuna email del mercoledì vi dirà che contiene una SQL injection, e il rapporto di stato mostrerà tutto come aggiornato. Richiede la stessa disciplina di revisione di qualsiasi altro lavoro di sviluppo software.

Lo stack sotto Drupal

Drupal è PHP, e le versioni di PHP arrivano a fine vita secondo un calendario proprio. Un sito può essere del tutto aggiornato a livello di CMS e girare comunque su una versione di PHP che ha smesso di ricevere correzioni di sicurezza un anno fa, perché l’hosting non è mai entrato nella conversazione sulla manutenzione. Le indicazioni su permessi e proprietà dei file poggiano sul principio che il server web non deve poter scrivere i file che esegue, eppure molti siti girano con una directory di codice scrivibile perché così si semplificava uno script di distribuzione.

Come andrebbe davvero applicata una patch a un sito Drupal

La risposta è noiosa, ed è per questo che resta inattuata. Nessuno strumento elimina la necessità di un percorso provato dall’avviso alla produzione, e costruirlo una volta costa meno della prima emergenza.

Il flusso di lavoro con Composer

Tutto da Drupal 8 in avanti è un progetto Composer. Aggiornate i pacchetti del core con le loro dipendenze, poi applicate gli aggiornamenti del database e ricostruite la cache:

1composer update "drupal/core-*" --with-all-dependencies
2drush updatedb
3drush cache:rebuild

Drush può essere sostituito da update.php. Controllate il rapporto di stato prima e dopo. La parte importante non sono i comandi, ma il fatto che girino prima da qualche parte diversa dalla produzione.

Uno staging che è davvero una copia

Un ambiente di staging aiuta solo se rispecchia la produzione: lo stesso insieme di moduli, la stessa versione di PHP, un database recente e ripulito. Uno staging vecchio produce un esito verde che non significa nulla, il che è peggio di non avere staging affatto perché fabbrica fiducia.

La sequenza è portare la produzione giù verso lo staging, applicare l’aggiornamento, eseguire gli aggiornamenti del database, percorrere le pagine e i form che rendono il sito commercialmente utile, e poi distribuire. Con una pipeline funzionante sono 45 fino a 90 minuti. Senza, un giorno e mezzo.

L’automazione e i suoi limiti

Gli aggiornamenti automatici delle dipendenze aiutano soprattutto sul flusso dei moduli contribuiti, l’estremità ad alto volume e bassa gravità. Un bot che apre una richiesta di merge per ogni aggiornamento di modulo, con i test eseguiti su ciascuna, trasforma una passata manuale mensile in una coda di revisione. Il core sta andando nella stessa direzione: il lavoro su Automatic Updates poggia sul modulo Package Manager, che viene distribuito nel core ma è ancora sperimentale.

Il budget di tempo realistico

Un sito Drupal mantenuto costa circa mezza giornata al mese in aggiornamenti di routine dei moduli, più da una a tre ore per ogni rilascio di sicurezza del core che si applica. Aggiungete un margine per i uno o due rilasci altamente critici all’anno che vanno fatti la sera stessa. È il numero che la maggior parte dei team interni non ha mai messo a budget, ed è per questo che il lavoro slitta.

Hardening oltre le patch

L’hardening non sostituisce le patch. Riduce quante delle vulnerabilità pubblicate siano sfruttabili sulla vostra installazione, e compra tempo quando una patch non può uscire subito. Le voci specifiche di Drupal sono poco costose e permanenti.

Host attendibili e file system

Impostate i pattern degli host attendibili. Drupal usa il meccanismo di trusted host di Symfony, configurato tramite l’impostazione trusted_host_patterns in settings.php come espressioni regolari che corrispondono ai domini su cui il sito risponde. Le richieste con qualsiasi altro header Host vengono respinte con un 400. Senza quello un attaccante può avvelenare i link di reimpostazione della password e gli URL assoluti in cache usando un header falsificato.

Usate il file system privato per tutto ciò che non deve essere leggibile pubblicamente, e assicuratevi che PHP non possa essere eseguito dentro la directory dei file pubblici. Drupal include un file .htaccess che blocca l’esecuzione sotto Apache, ma nginx non ha un file equivalente da depositare e la regola va scritta a mano nella configurazione del server. I siti passati anni fa da Apache a nginx hanno perso spesso quella protezione in silenzio.

Applicate poi il modello di proprietà: directory a 750, file di codice a 640, la directory dei file scrivibile dal server web e da nient’altro, e settings.php leggibile solo dal suo proprietario.

Permessi, rotte di amministrazione e passata di revisione

Limitate le rotte amministrative. Non c’è alcuna ragione perché i percorsi di login e di amministrazione di un sito i cui redattori lavorano da tre uffici siano raggiungibili da tutta internet, e un elenco di indirizzi IP consentiti o un proxy con autenticazione elimina un’intera classe di attacchi alle credenziali.

Verificate poi la griglia dei permessi. Cresce con ogni modulo installato, e il riscontro ha quasi sempre la stessa forma: un ruolo di redattore che può amministrare i filtri di testo, o un ruolo che può eseguire PHP arbitrario. Entrambi convertono una password di redattore rubata in esecuzione di codice remoto, così una email di phishing diventa una compromissione del server.

Eseguite il modulo Security Review prima di discutere di qualsiasi altra cosa. Automatizza i controlli che a mano sono noiosi: permessi del file system, formati di testo non sicuri, PHP o JavaScript nei contenuti, esposizione dei messaggi di errore, estensioni di caricamento, accessi falliti, permessi pericolosi e configurazione degli host attendibili. La versione 3.1.3, rilasciata a gennaio 2026, supporta Drupal 10.3 e successivi oltre a Drupal 11.

Cosa offre un firewall e cosa no

Un web application firewall è una patch virtuale, ed è così che la Drupal Association presenta Drupal Steward, il servizio a pagamento che gestisce insieme al team di sicurezza. Applica una mitigazione a livello di rete per certe vulnerabilità altamente critiche del core, proteggendo un sito durante il divario fra avviso e distribuzione. Il prezzo pubblicato è sotto i 20 dollari statunitensi al mese per un sito che serve un milione di richieste HTTP, e sotto i 100 dollari statunitensi oltre i dieci milioni.

I limiti li dichiara il progetto stesso: non ogni problema può essere mitigato in questo modo, e il meccanismo copre solo le vulnerabilità sfruttate attraverso una richiesta al server web. Un firewall non fa nulla contro una password di amministratore compromessa, un aggiornamento di modulo malevolo o una falla nel vostro codice. Trattatelo come un’assicurazione per la finestra di aggiornamento, non come una ragione per allargarla, che è la posizione che teniamo anche nella nostra checklist di hardening della sicurezza WordPress.

Quanto costa una compromissione e come si presenta il ripristino

Riprendersi da una compromissione Drupal non è una patch. Una volta che un attaccante ha ottenuto l’esecuzione di codice, l’ipotesi di lavoro è che siano stati scritti file, prese credenziali e installato un meccanismo di persistenza, che è quanto il team di sicurezza disse ai titolari di siti Drupal 7 nel 2014. Ripulire sul posto un sito compromesso è tirare a indovinare travestito da rimedio.

L’approccio difendibile è ricostruire la base di codice dal controllo di versione su un host nuovo, ripristinare solo i contenuti e i file caricati dopo un’ispezione, ruotare ogni credenziale che il sito custodiva e conservare l’immagine del disco compromesso invece di cancellarla. È l’ultimo passo quello che si salta sotto pressione, ed è l’unica prova di che cosa sia successo.

Il costo commerciale raramente è la ricostruzione. Sono il tempo di inattività, il lavoro forense, la comunicazione ai clienti e il procedimento normativo. Una ricostruzione in condizioni di incidente vale in genere da 5.000 a 20.000 sterline di ingegneria, di solito la voce più piccola del totale.

Obblighi britannici di protezione dei dati

Se dati personali sono stati o potrebbero essere stati consultati, l’orologio del GDPR britannico parte quando ne venite a conoscenza, non quando finite di indagare. Le linee guida dell’ICO sulle violazioni impongono che una violazione notificabile sia segnalata senza ingiustificato ritardo e comunque entro 72 ore dal momento in cui se ne è venuti a conoscenza, e se impiegate di più dovete motivarlo. Quando la violazione può comportare un rischio elevato per i diritti e le libertà delle persone, dovete anche informare quelle persone senza ingiustificato ritardo.

L’ICO è chiaro sul fatto che un quadro incompleto non è una ragione per mancare la scadenza: segnalate quello che sapete e integrate dopo. Non notificare quando è richiesto può comportare una sanzione fino a 8,7 milioni di sterline o al 2 per cento del fatturato globale.

Quell’orologio è il motivo per cui la domanda forense conta. Un sito senza log e senza traccia di quale versione fosse in esecuzione non può dire a quali dati si sia acceduto, e finisce per segnalare lo scenario peggiore. È l’argomento a favore di un audit di sicurezza del sito web prima di un incidente anziché dopo.

Cosa dovrebbe includere un contratto di manutenzione della sicurezza Drupal

Un contratto che promette soltanto di applicare gli aggiornamenti non vale i soldi che costa, perché applicare gli aggiornamenti è la metà facile. Quello che pagate è il percorso di risposta nel giorno in cui arriva un avviso altamente critico, e il risultato che dimostra che funziona è una prova generale.

Il perimetro che vale la spesa copre il monitoraggio dei flussi di avvisi per il vostro esatto insieme di moduli, un ciclo mensile di patch con staging, test e piano di rollback, una finestra di risposta fuori orario concordata per i rilasci altamente critici del core, una revisione trimestrale dei moduli abbandonati con i sostituti quotati, il monitoraggio delle versioni di PHP e della piattaforma, e una revisione annuale della configurazione.

Nel Regno Unito gli accordi di solo monitoraggio si collocano intorno a 250 fino a 450 sterline al mese. Un contratto che include staging, test e distribuzione per un sito di medie dimensioni sta piuttosto sulle 600 fino a 1.500 sterline al mese, in scala con il numero di moduli e la quantità di codice su misura, perché entrambi decidono quanti test di regressione serva ogni ciclo. A fronte di tariffe giornaliere di agenzia da 600 a 900 sterline, la parte alta di quella fascia compra circa due giornate di un ingegnere. La nostra nota su tariffe e selezione degli sviluppatori Drupal ha i numeri.

Chiudere la finestra

Drupal vi dà più preavviso e più struttura di quasi ogni piattaforma paragonabile. Gli avvisi seguono un calendario e i rilasci altamente critici arrivano con due giorni di preavviso. Nulla di tutto ciò aiuta un sito che impiega due settimane a distribuire una patch da una riga.

Mecanik si occupa di patch e hardening Drupal come parte del nostro audit di sicurezza del sito web e del lavoro continuativo di sviluppo software. Il primo incarico è di solito un inventario più che una correzione, perché la maggior parte dei siti non sa dire quali dei propri moduli siano ancora supportati. Se state valutando la piattaforma in sé, la nostra guida 2026 allo sviluppo web con Drupal copre quel tema.

Domande frequenti

Con quale frequenza Drupal rilascia aggiornamenti di sicurezza? Gli avvisi sui progetti contribuiti escono ogni mercoledì, e il core di Drupal ha una finestra di rilascio di sicurezza il terzo mercoledì di ogni mese, anche se una finestra non garantisce un rilascio. I rilasci del core altamente critici sono di solito preceduti da un annuncio di servizio pubblico circa due giorni prima, che indica data e finestra oraria.

Che cosa significa un punteggio di rischio Drupal di 20 su 25? Drupal assegna a ogni avviso un punteggio da 0 a 25 con un sistema basato sul NIST Common Misuse Scoring System, combinando complessità di accesso, autenticazione richiesta, impatto su riservatezza e integrità, esistenza di un exploit noto e quanti siti sono interessati. Tutto ciò che va da 20 a 25 è altamente critico, il che significa applicare la patch in giornata.

Drupal 7 è ancora sicuro da usare nel 2026? No. Drupal 7 è arrivato a fine vita il 5 gennaio 2025 e il team di sicurezza Drupal non emette più avvisi per il suo core, per i moduli contribuiti o per i temi, quindi le falle possono essere divulgate pubblicamente senza una correzione coordinata. Il supporto esteso commerciale copre un insieme definito di codice alle condizioni del fornitore, il che aiuta durante una migrazione ma non equivale a essere supportati.

Quanto in fretta gli attaccanti sfruttano una vulnerabilità Drupal? Nel giro di ore, nei casi peggiori. Dopo l’avviso di SQL injection dell’ottobre 2014 il team di sicurezza Drupal disse ai titolari di dare per scontato che qualsiasi sito non aggiornato entro sette ore fosse già stato compromesso. A maggio 2026 sono stati rilevati in rete tentativi di sfruttamento contro una SQL injection altamente critica del core meno di due giorni dopo la pubblicazione.

Un web application firewall rende inutili le patch di Drupal? No. Un firewall come Drupal Steward fornisce una patch virtuale per certe falle altamente critiche del core sfruttate tramite una richiesta web, e questo compra tempo durante la finestra di distribuzione. Non può nulla contro una password di amministratore rubata, un modulo compromesso o una falla nel vostro codice, quindi riduce il rischio del divario invece di chiuderlo.