--- title: "Drupal CVE-2026-9082: cosa fare ora" description: "Drupal ha pubblicato SA-CORE-2026-004 per CVE-2026-9082: SQL injection su siti PostgreSQL, tentativi di exploit rilevati e patch da applicare subito." canonical_url: "https://spaziorc.com/blog/drupal-cve-2026-9082" --- > Index of every page on this site: [llms.txt](https://spaziorc.com/llms.txt) 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](https://www.drupal.org/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:
Ramo Drupal Versioni vulnerabili Versione corretta
Drupal 11.3 11.3.0 fino a 11.3.9 11.3.10
Drupal 11.2 11.2.0 fino a 11.2.11 11.2.12
Drupal 11.0 e 11.1 prima di 11.1.10 11.1.10
Drupal 10.6 10.6.0 fino a 10.6.8 10.6.9
Drupal 10.5 10.5.0 fino a 10.5.9 10.5.10
Drupal 10.4 e precedenti prima di 10.4.10 10.4.10
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](https://www.drupal.org/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](https://spaziorc.com/hosting-condiviso) con manutenzione chiara o una soluzione [cloud](https://spaziorc.com/cloud-server) 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](https://spaziorc.com/blog/cpanel-zero-day-supply-chain): 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. ## Sitemap See the full [sitemap](https://spaziorc.com/sitemap.md) for all pages.