Il 20 maggio il team di sicurezza di Drupal ha pubblicato le correzioni per la CVE-2026-9082, una SQL injection nel core del CMS classificata come «altamente critica». Due giorni dopo l’avviso è stato aggiornato: i tentativi di sfruttamento erano già partiti, e le autorità statunitensi hanno aggiunto la falla all’elenco di quelle sfruttate attivamente.
Chi segue Drupal da qualche anno avrà un brivido familiare. Nel 2014 Drupageddon, un’altra SQL injection nel core, fu sfruttata in massa entro poche ore, e nel 2018 Drupalgeddon2 seguì la stessa strada. Stavolta c’è una differenza importante: la falla riguarda solo i siti che usano PostgreSQL come database. Chi usa MySQL, MariaDB o SQLite non è esposto.
Il problema sta nel modo in cui Drupal costruisce alcune query specifiche per PostgreSQL. Un visitatore anonimo, con richieste costruite ad arte, può inserire comandi SQL e leggere o modificare il database. Nei casi peggiori si arriva all’esecuzione di codice sul server.
Patch anche per i rami chiusi
Le versioni corrette sono la 11.3.10, la 11.2.12 e la 11.1.10, e la 10.6.9, la 10.5.10 e la 10.4.10. I rami 11.1 e 10.4, ormai fuori supporto, hanno ricevuto una correzione eccezionale. Per Drupal 8.9 e 9.5 c’è solo una patch da applicare a mano. Drupal 7 non è coinvolto.
Le analisi del codice corretto sono circolate in poche ore. Secondo un fornitore di firewall applicativi, entro il 22 maggio si contavano già oltre 15.000 tentativi di sfruttamento contro circa 6.000 siti in 65 Paesi. Quanti siano andati a segno, nessuno lo ha ancora detto.
Drupal è molto usato da enti pubblici, università e grandi organizzazioni, ambienti in cui PostgreSQL è una scelta frequente. E una SQL injection anonima nel core trasforma in bersaglio ogni sito con quella configurazione, anche senza un solo modulo aggiuntivo.
Controlla quale database usa il tuo sito e quale versione del core hai installato. Se la risposta è PostgreSQL, aggiorna subito alla versione corretta del tuo ramo. Se sei ancora su Drupal 8 o 9, applica la patch manuale, e pianifica la migrazione.
Poi apri il database e cerca nuovi account amministratore e contenuti modificati di recente. Se il sito è rimasto esposto senza aggiornamento dopo il 20 maggio, cambia le password degli amministratori e le credenziali del database.
