Drupal CVE-2026-9082: cosa fare ora

Il 20 maggio 2026 il Drupal Security Team ha pubblicato SA-CORE-2026-004, advisory ufficiale per Drupal CVE-2026-9082. La vulnerabilità è una SQL injection nel core di Drupal, sfruttabile da utenti anonimi sui siti che usano PostgreSQL come database. Il 22 maggio Drupal ha aggiornato il punteggio di rischio a Highly critical 23/25, perché sono stati rilevati tentativi di exploit in the wild.

La frase importante è questa: non tutti i siti Drupal sono colpiti dalla SQL injection, ma tutti gli amministratori Drupal dovrebbero leggere l'advisory e pianificare l'aggiornamento. Le release pubblicate includono anche aggiornamenti di sicurezza per dipendenze di terze parti.

Drupal CVE-2026-9082: cosa è successo

La fonte primaria è l'advisory ufficiale Drupal SA-CORE-2026-004. Secondo Drupal, il problema riguarda la database abstraction API, cioè il livello che dovrebbe costruire query SQL in modo sicuro e coerente fra database diversi.

Nel caso di CVE-2026-9082, richieste appositamente costruite possono portare a SQL injection arbitraria sui siti Drupal che usano PostgreSQL. L'impatto indicato da Drupal include disclosure di informazioni e, in alcuni casi, escalation di privilegi, remote code execution o altri attacchi.

La vulnerabilità può essere sfruttata da utenti anonimi. Questo è il dettaglio che sposta la priorità: non serve un account rubato, non serve essere editor, non serve convincere un amministratore a cliccare un link. Se il sito è esposto su Internet e rientra nella configurazione vulnerabile, la finestra di rischio è concreta.

Chi è davvero vulnerabile

La SQL injection di CVE-2026-9082 riguarda i siti Drupal con database PostgreSQL. Drupal lo specifica chiaramente: questa parte dell'advisory non si applica a installazioni basate su MySQL, MariaDB o SQLite.

Le versioni interessate sono:

Drupal 8 e Drupal 9 sono end-of-life. Per la gravità del caso, il team ha pubblicato patch best effort per Drupal 8.9 e 9.5, ma il messaggio operativo resta lo stesso: quei rami non sono una base sicura per un sito in produzione.

Drupal 7 non è colpito da questa vulnerabilità specifica.

Perché aggiornare anche se non usi PostgreSQL

Qui nasce la confusione. Se il tuo sito Drupal usa MySQL o MariaDB, la SQL injection CVE-2026-9082 non si applica. Questo però non significa che l'update sia inutile.

Nello stesso advisory, Drupal segnala che le release per i rami supportati includono anche aggiornamenti coordinati per Symfony e Twig. A seconda della configurazione del sito e dei moduli contrib installati, questi aggiornamenti possono proteggere da vulnerabilità diverse rispetto alla SQL injection.

La lettura corretta è quindi:

• Sito Drupal con PostgreSQL: aggiornamento immediato, priorità alta.
• Sito Drupal con MySQL o MariaDB: non sei esposto alla SQL injection, ma conviene comunque aggiornare per le dipendenze.
• Sito Drupal 8 o 9: patch temporanea se non puoi migrare subito, ma la soluzione vera è passare a un ramo supportato.
• Sito Drupal 7: CVE-2026-9082 non si applica, ma il ciclo di vita e il supporto vanno valutati separatamente.

La sicurezza dei CMS raramente è un singolo interruttore acceso o spento. È una somma di core, moduli, tema, librerie PHP, configurazione server, permessi e abitudini operative.

La lezione del preavviso del 18 maggio

Due giorni prima dell'advisory, Drupal aveva pubblicato la PSA-2026-05-18, un preavviso pubblico per una release altamente critica prevista il 20 maggio 2026 tra le 17:00 e le 21:00 UTC.

Il messaggio era chiaro: dedictate del tempo all'update, perché gli exploit per questo tipo di vulnerabilità possono essere sviluppati in ore o giorni. Non era allarmismo. Il 22 maggio, l'advisory è stato aggiornato per indicare che i tentativi di exploit venivano già rilevati in the wild.

Questo è un punto importante per chi gestisce un sito aziendale: quando un progetto come Drupal pubblica una PSA ad alta criticità, non è un promemoria generico. È un invito a liberare una finestra tecnica, verificare backup, controllare compatibilità e prepararsi a patchare appena escono le versioni corrette.

Nel 2026 il tempo fra disclosure e scansione automatica è sempre più corto. Gli attaccanti leggono gli advisory, confrontano i diff, automatizzano test e puntano prima i siti facili: installazioni vecchie, backup non verificati, hosting senza manutenzione, ambienti dove nessuno sa chi deve premere "aggiorna".

Cosa controllare oggi

Se gestisci un sito Drupal, parti da tre domande semplici.

1. Quale database usa il sito?

Controlla la configurazione del progetto. Su Drupal moderni, il riferimento è in sites/default/settings.php o nella configurazione ambiente usata dal deploy. Se il driver è PostgreSQL, il sito rientra nel perimetro della SQL injection.

Se non hai accesso tecnico e il sito è gestito da un fornitore, chiedi conferma. La domanda giusta non è "siamo sicuri?", ma: "Il sito usa PostgreSQL? Quale versione Drupal è in produzione? L'update SA-CORE-2026-004 è stato applicato?".

2. Il ramo Drupal è supportato?

Drupal 10.5, 10.6, 11.2 e 11.3 hanno ricevuto release supportate. I rami 10.4, 11.0 e 11.1 hanno ricevuto release eccezionali perché il caso era grave, ma restano rami da superare. Drupal 8 e 9 richiedono patch manuali e non sono una strategia accettabile per il medio periodo.

Se il sito è ancora su un ramo non supportato, l'urgenza non finisce con questa CVE. Questa vulnerabilità è solo il modo in cui il problema diventa visibile.

3. Hai un rollback verificato?

Aggiornare un CMS senza un valido backup è un rischio. Non aggiornare un CMS esposto a exploit lo è ancora di più.

Se il sito gestisce lead, ordini o dati personali, questo processo dovrebbe essere normale manutenzione, non emergenza improvvisata.

Hosting e manutenzione: dove si vede la differenza

CVE-2026-9082 è un caso Drupal, ma la lezione vale per ogni CMS. Lo abbiamo visto anche con WordPress, cPanel e plugin vulnerabili: il problema non è solo "esiste una falla". Il problema è chi se ne accorge, chi decide la priorità, chi applica la patch e chi controlla che il sito sia ancora integro dopo l'update.

Per un piccolo e-commerce, uno studio professionale o un sito istituzionale, questa differenza si traduce in ore. Un hosting economico senza assistenza ti lascia spesso con una notifica da interpretare. Un servizio gestito deve aiutarti a capire cosa è urgente, cosa riguarda davvero la tua configurazione e cosa va pianificato.

Se il tuo sito vive su un CMS e non hai una persona tecnica che segue aggiornamenti e advisory, valuta un piano hosting condiviso con manutenzione chiara o una soluzione cloud quando servono isolamento e controllo maggiore. Non è una garanzia contro ogni vulnerabilità, ma riduce il punto più fragile: l'assenza di responsabilità operativa.

Vale anche la pena rileggere il caso cPanel sulla lezione dei due mesi di silenzio: software diverso, stesso principio. La sicurezza non è il pannello che vedi, è la filiera che reagisce quando qualcosa si rompe.

In sintesi

Drupal CVE-2026-9082 è una SQL injection critica pubblicata il 20 maggio 2026 e aggiornata il 22 maggio dopo tentativi di exploit rilevati in the wild. Colpisce i siti Drupal che usano PostgreSQL, ma le release includono anche aggiornamenti di dipendenze utili per tutti i siti sui rami supportati.

La cosa da fare oggi è: verifica database, versione Drupal e stato della patch. Se sei su PostgreSQL, aggiorna subito. Se non lo sei, aggiorna comunque appena la compatibilità lo consente. Se sei su Drupal 8 o 9, questa non è solo una patch: è il segnale che la migrazione non può più restare in fondo alla lista.