Allarme CVE-2026-9082: Drupal sotto attacco, cosa fare subito

Tre giorni. È il tempo che è bastato perché la vulnerabilità più grave nella storia recente di Drupal passasse da «teorica» a «sfruttata attivamente in natura». Era il 20 maggio 2026 quando il Drupal Security Team rilasciava le patch per CVE-2026-9082, una falla SQL injection classificata "highly critical". Il 22 maggio, il risk score veniva già rivisto al rialzo da 20 a 23 — su una scala massima di 25 — perché i tentativi di exploit erano in corso contro migliaia di siti web in oltre 65 Paesi. Oggi, 23 maggio, Imperva ha contato più di 15.000 tentativi di compromissione diretti a quasi 6.000 installazioni Drupal. Per chi gestisce un sito Drupal in Italia — che sia un portale istituzionale, un e-commerce B2B o il sito di un'associazione di categoria — la finestra per mettersi in sicurezza si sta chiudendo rapidamente.

Cos'è CVE-2026-9082: la falla nel database abstraction layer

CVE-2026-9082 è una vulnerabilità SQL injection nel database abstraction layer di Drupal core, il componente software che ha il compito di «igienizzare» le query inviate al database per prevenire attacchi di tipo injection. L'API incriminata è lo EntityQuery condition handler per PostgreSQL: un meccanismo che, in condizioni normali, dovrebbe garantire che qualsiasi richiesta al database venga ripulita da codice malevolo prima dell'esecuzione. Invece, un attaccante può inviare richieste appositamente costruite per iniettare comandi SQL arbitrari [drupal.org].

La gravità è amplificata da tre fattori critici. Primo: la vulnerabilità è sfruttabile da utenti anonimi, senza alcuna autenticazione. Secondo: l'impatto spazia dalla semplice estrazione di dati alla possibilità, in alcune configurazioni, di ottenere escalation di privilegi e persino esecuzione di codice remoto (RCE). Terzo: la patch stessa, una volta resa pubblica, ha funzionato come una mappa per gli attaccanti. Il patch diff — la differenza tra il codice vulnerabile e quello corretto — è stato condiviso sui social network nel giro di poche ore dal rilascio, consentendo a chiunque di analizzare la falla e costruire un exploit [tenable.com].

Cronologia di un disastro annunciato

La sequenza degli eventi è istruttiva per chiunque si occupi di gestione delle vulnerabilità — e andrebbe stampata e appesa in ogni ufficio IT italiano. Ecco la timeline:

1. 18 maggio 2026 — Drupal pubblica un PSA (Public Service Announcement) che preannuncia una patch di sicurezza "highly critical" per il 20 maggio, invitando gli amministratori a «riservare tempo per gli aggiornamenti» perché «exploit potrebbero essere sviluppati nel giro di ore o giorni» [drupal.org].
2. 20 maggio, ore 17:00-21:00 UTC — Rilascio delle patch per tutti i branch supportati (11.3.x, 11.2.x, 10.6.x, 10.5.x) e — misura eccezionale — anche per i branch end-of-life 11.1.x e 10.4.x, data la gravità della falla [drupal.org].
3. 20 maggio, sera — Il patch diff viene condiviso pubblicamente. Una proof-of-concept di rilevamento e un laboratorio di riproduzione vengono pubblicati lo stesso giorno [tenable.com].
4. 22 maggio — Drupal aggiorna il risk score da 20 a 23, confermando che tentativi di exploit sono in corso in the wild [securityweek.com].
5. 23 maggio — Imperva riporta oltre 15.000 tentativi di exploit contro quasi 6.000 siti in 65 Paesi. Quasi metà degli attacchi si concentra su siti di gaming e servizi finanziari, ma la scansione automatica sta setacciando l'intero ecosistema Drupal [securityweek.com].

L'ultima volta che Drupal ha registrato una vulnerabilità critica sfruttata attivamente in natura risale al 2019. Prima ancora, i casi noti come Drupalgeddon e Drupalgeddon2 fecero notizia per la compromissione di un numero impressionante di siti web. CVE-2026-9082 spezza un silenzio lungo sette anni — e lo fa con una violenza che gli analisti definiscono «prevedibile ma allarmante» [securityweek.com].

Chi è colpito (e chi no)

Un dato aiuta a dimensionare il problema, ma rischia anche di generare un pericoloso senso di falsa sicurezza: la vulnerabilità interessa solo i siti Drupal che utilizzano PostgreSQL come database backend. Drupal stima che meno del 5% delle installazioni totali siano su PostgreSQL. Siti con MySQL, MariaDB o SQLite non sono esposti a CVE-2026-9082.

Tuttavia, emerge un dettaglio cruciale che estende l'obbligo di aggiornamento a tutti gli amministratori Drupal. Le patch del 20 maggio includono aggiornamenti coordinati per Symfony e Twig, due librerie su cui Drupal si appoggia per il funzionamento del framework. Si tratta di vulnerabilità distinte da CVE-2026-9082, ma alcune riguardano direttamente Drupal core. Twig è stato aggiornato alla versione 3.26.0 e Symfony ha emesso una serie di advisory di sicurezza separate. In altre parole: anche chi usa MySQL deve installare questo aggiornamento [csoonline.com].

Quali versioni aggiornare

Drupal ha pubblicato correzioni per sei branch, incluse due release eccezionali per versioni normalmente fuori supporto. Ecco la tabella riepilogativa:

Drupal 7 non è interessato dalla vulnerabilità. Per Drupal 8 e 9, completamente end-of-life, il Security Team ha pubblicato patch «best-effort» non garantite, con l'avvertimento che queste versioni contengono «numerose altre vulnerabilità di sicurezza precedentemente divulgate» che non verranno mai corrette. La raccomandazione è di migrare a una versione supportata il prima possibile [drupal.org].

L'impatto per le PMI e gli enti italiani

Drupal è storicamente uno dei CMS più adottati nel panorama italiano per progetti che richiedono flessibilità architetturale e gestione di contenuti strutturati. Lo usano enti pubblici, università, testate editoriali, associazioni di categoria e aziende B2B con portali complessi. Spesso si tratta di siti che gestiscono dati sensibili: anagrafiche di iscritti, transazioni, documenti riservati.

Per queste realtà, il rischio non è teorico. I numeri diffusi da Imperva — 6.000 siti nel mirino in 65 Paesi, con gli scanner automatici che setacciano sistematicamente Internet alla ricerca di installazioni vulnerabili — significano che qualsiasi sito Drupal non aggiornato su PostgreSQL è un bersaglio. La fase attuale è ancora dominata da ricognizione e validazione, ma la natura della vulnerabilità fa sì che «un exploit andato a segno possa passare rapidamente dal sondaggio all'estrazione dati o all'escalation di privilegi», come sottolineano i ricercatori di Imperva [securityweek.com].

Inoltre, il contesto normativo italiano ed europeo aggiunge un livello di complessità. Un data breach causato da una vulnerabilità nota e non patchata configura una violazione del GDPR con potenziali conseguenze che vanno dalle sanzioni amministrative (fino al 4% del fatturato annuo) all'obbligo di notifica al Garante della Privacy entro 72 ore. Per gli enti pubblici, il quadro si inserisce anche negli obblighi del Perimetro di Sicurezza Nazionale Cibernetica (PSNC) e delle direttive AgID.

Guida operativa: cosa fare nelle prossime 24 ore

Non c'è tempo per le valutazioni. Ecco i passaggi operativi, in ordine di priorità, per mettere in sicurezza un'installazione Drupal:

1. Aggiornamento immediato del core

L'azione prioritaria e non negoziabile è l'aggiornamento di Drupal core alla versione patchata corrispondente al proprio branch. Per i branch supportati, l'operazione è gestibile via Composer o tramite l'interfaccia di amministrazione. Il comando Composer tipico è:

composer update drupal/core --with-dependencies
drush updb
drush cr

Chi utilizza Drupal Steward, il servizio di protezione gestito dal Drupal Security Team, è già protetto dai vettori di attacco noti, ma deve comunque programmare l'aggiornamento perché potrebbero emergere nuovi vettori non ancora coperti [drupal.org].

2. Verifica di compromissioni pregresse

Prima ancora dell'aggiornamento (o subito dopo, se l'aggiornamento è già stato fatto), è essenziale verificare se il sito è già stato compromesso. Fritz Jean-Louis di Info-Tech Research Group raccomanda di esaminare i log di PostgreSQL e del Web Application Firewall alla ricerca di «attività anomale da parte di utenti anonimi o query SQL sospette nel periodo precedente all'applicazione della patch» [csoonline.com].

Segnali di compromissione da cercare:

• Query SQL contenenti pattern insoliti (es. UNION SELECT, pg_read_file(), COPY ... TO)
• Accessi anonimi a URL che normalmente richiederebbero autenticazione
• Creazione di nuovi account amministratore o modifica di account esistenti
• Presenza di file PHP sconosciuti nella directory del sito
• Modifiche non autorizzate a contenuti, blocchi o configurazioni

3. Aggiornare Symfony e Twig (anche se si usa MySQL)

Le patch di Drupal includono aggiornamenti per Symfony e Twig che correggono vulnerabilità separate. Come sottolinea Greg Enderle, esperto di sicurezza Drupal: «Anche se l'IT usa MySQL o SQLite e pensa di essere al sicuro dal bug principale di Drupal, deve comunque applicare l'aggiornamento» [csoonline.com]. In particolare, le vulnerabilità Twig richiedono un audit di chi ha effettivamente il permesso di modificare i template Twig tramite Views o altri moduli, limitando l'accesso ai soli amministratori fidati.

4. Hardening e monitoraggio

Oltre all'aggiornamento immediato, è opportuno attivare o rafforzare alcune misure di protezione aggiuntive:

• Web Application Firewall (WAF): attivare o aggiornare le regole specifiche per SQL injection su Drupal. Molti WAF commerciali hanno già rilasciato firme per CVE-2026-9082.
• Monitoraggio dei log: attivare alert automatici su pattern SQL anomali e accessi amministrativi sospetti. Per chi gestisce più installazioni, strumenti centralizzati come soluzioni SIEM per PMI possono fare la differenza.
• Backup verificato: assicurarsi di disporre di un backup integro e recente, preferibilmente seguendo una strategia 3-2-1-1-0, prima di applicare qualsiasi modifica significativa.
• Limitazione dell'accesso al database: verificare che PostgreSQL non sia esposto su interfacce di rete pubbliche e che l'accesso sia ristretto ai soli host autorizzati.

Quando l'aggiornamento non basta: limiti e criticità

L'aggiornamento del core è condizione necessaria ma potrebbe non essere sufficiente in tre scenari.

Primo scenario: siti già compromessi. Se un attaccante ha già sfruttato CVE-2026-9082 prima dell'applicazione della patch, potrebbe aver installato una backdoor — un file PHP malevolo, un modulo alterato, un account amministratore nascosto — che sopravvive all'aggiornamento. In questo caso serve una bonifica completa, idealmente ripristinando da un backup pulito e applicando la patch su quell'istanza.

Secondo scenario: versioni end-of-life. Chi usa Drupal 8 o 9 ha accesso solo a patch manuali «best-effort» non garantite, che potrebbero introdurre regressioni o non coprire tutti i vettori. Inoltre, queste versioni contengono decine di vulnerabilità note e non patchate. L'unica soluzione sostenibile è la migrazione a una versione supportata (almeno Drupal 10.6), ma questo richiede pianificazione, budget e competenze che non tutte le PMI hanno immediatamente disponibili.

Terzo scenario: moduli contrib personalizzati. Drupal deve gran parte della sua potenza all'ecosistema di moduli contrib. Se un modulo personalizzato interagisce direttamente con il database abstraction layer o con l'EntityQuery API, potrebbe esporre nuovi vettori di attacco anche dopo l'aggiornamento del core. È opportuno un audit dei moduli installati, dando priorità a quelli che eseguono query dinamiche.

Alternative e confronto: Drupal è ancora la scelta giusta?

Ogni crisi di sicurezza riapre inevitabilmente il dibattito: per una PMI italiana, Drupal è ancora il CMS giusto? La risposta non è binaria e merita un'analisi onesta.

Drupal eccelle nella gestione di contenuti strutturati, tassonomie complesse, flussi editoriali multi-ruolo e integrazioni enterprise. Per un ente pubblico che gestisce centinaia di tipologie di contenuto con workflow di approvazione granulari, Drupal rimane tecnicamente superiore a molte alternative.

Drupal delude quando viene adottato senza le risorse per mantenerlo. La curva di apprendimento è ripida, gli aggiornamenti tra versioni major possono essere traumatici (il passaggio da Drupal 7 a 8 fu una riscrittura quasi totale), e il costo di gestione continuativa — in termini di competenze interne o servizi esterni — è superiore rispetto a CMS più semplici.

Ecco un confronto pragmatico con le principali alternative per il contesto italiano:

Criteri decisionali: se l'organizzazione ha un team tecnico (interno o esterno) in grado di seguire aggiornamenti mensili e migrazioni major, Drupal rimane una scelta solida. Se invece il sito è gestito da personale non specializzato, aggiornato sporadicamente e basato su una versione installata «una volta per sempre», è il momento di considerare seriamente un'alternativa con un costo totale di gestione più basso — o di affidare la manutenzione a un provider specializzato. Per un approfondimento sulla protezione complessiva delle infrastrutture web, la guida alla cybersecurity per PMI offre un quadro più ampio.

Non solo Drupal: il quadro sicurezza di maggio 2026

CVE-2026-9082 non è un episodio isolato. Maggio 2026 si sta rivelando un mese denso di allarmi di sicurezza che coinvolgono componenti ampiamente diffusi nell'infrastruttura digitale delle PMI italiane. Nella stessa settimana, Cisco ha patchato CVE-2026-20223, una vulnerabilità CVSS 10.0 (il massimo) in Secure Workload che consente a un attaccante remoto non autenticato di accedere a dati sensibili via REST API [thehackernews.com].

Ubiquiti ha corretto tre vulnerabilità di massima severità in UniFi OS, sfruttabili senza autenticazione [bleepingcomputer.com]. E TrendAI ha rilasciato una patch d'emergenza per una zero-day in Apex One già sfruttata in the wild [securityweek.com].

Il denominatore comune è l'accorciamento del tempo tra disclosure e sfruttamento attivo. L'analisi automatica dei patch diff tramite strumenti di intelligenza artificiale sta comprimendo la finestra di reazione a poche ore, rendendo obsoleto il tradizionale approccio «aspetta qualche giorno prima di aggiornare». Per un approfondimento su come l'AI sta trasformando il panorama delle minacce, si veda anche l'articolo su zero-day generate da AI.

Conclusioni: aggiornare oggi, ripensare domani

CVE-2026-9082 è un caso da manuale di quanto rapidamente il panorama delle minacce possa evolvere. In meno di 72 ore, una vulnerabilità annunciata con preavviso è diventata un attacco su larga scala contro migliaia di siti. Per le PMI e gli enti italiani che gestiscono installazioni Drupal, il messaggio è inequivocabile: aggiornare immediatamente, verificare la presenza di compromissioni, e poi fare un passo indietro per valutare se la propria strategia di gestione del CMS sia sostenibile nel medio periodo.

Chi è su una versione supportata e ha un processo di aggiornamento regolare può risolvere la crisi in poche ore. Chi è fermo a Drupal 8 o 9 deve usare le patch best-effort come misura tampone e pianificare subito la migrazione. Chiunque gestisca un sito Drupal, indipendentemente dal database usato, deve applicare questo aggiornamento per via delle vulnerabilità in Symfony e Twig incluse nella stessa release.

La lezione più ampia, valida ben oltre Drupal, è che la gestione continuativa delle vulnerabilità non è più un'attività accessoria ma il cuore pulsante di qualsiasi strategia di sicurezza. I tre giorni di preavviso che Drupal ha concesso prima del rilascio della patch sono stati un lusso — e chi non li ha usati per prepararsi, oggi sta correndo ai ripari.

Articolo aggiornato al 23 maggio 2026. Le informazioni sulle patch e le versioni sono tratte dalle comunicazioni ufficiali del Drupal Security Team e verificate con fonti multiple. Per assistenza sulla protezione delle proprie infrastrutture, i clienti Neomedia possono contattare il supporto tecnico.