Segui 
Drupal ha rilasciato aggiornamenti di sicurezza per una vulnerabilità di sicurezza “altamente critica” in Drupal Core che può essere sfruttata da attaccanti anonimi contro siti che utilizzano database PostgreSQL. Tracciata come vulnerabilità CVE-2026-9082, il problema risiede nell’API di astrazione del database di Drupal, che dovrebbe sanificare le query prima che raggiungano il database di backend. Drupal classifica la vulnerabilità con un punteggio di 20/25 sulla sua scala di gravità, mentre The Hacker News nota che CVE.org la elenca a 6.5/10.
Per i difensori che iniziano l’analisi di CVE-2026-9082, il rischio principale è che richieste appositamente create possono portare a iniezioni SQL arbitrarie su siti supportati da PostgreSQL, il che può a sua volta causare divulgazione di informazioni e, in alcuni casi, escalation dei privilegi o esecuzione di codice remoto. Drupal afferma anche che la vulnerabilità può essere sfruttata da utenti anonimi, rendendo i siti esposti pubblicamente la massima priorità per la mitigazione.
Anche i dettagli attuali per CVE-2026-9082 contano perché l’ambito è più ristretto di quanto un generico titolo “tutti i siti Drupal” suggerisca. L’avviso di Drupal dice che il problema di iniezione SQL riguarda solo i siti che utilizzano PostgreSQL, ma le stesse release di sicurezza includono anche importanti correzioni upstream per Symfony e Twig, motivo per cui è consigliato l’aggiornamento anche per le distribuzioni non PostgreSQL.
Analisi CVE-2026-9082
A livello tecnico, CVE-2026-9082 è un fallimento nell’API di astrazione del database che normalmente valida e sanifica le query per prevenire l’iniezione SQL. Drupal afferma che un attaccante può inviare richieste appositamente create che bypassano le protezioni attese e consegnano SQL arbitrario al backend PostgreSQL. In termini pratici, il payload di CVE-2026-9082 è una richiesta malevola creata per abusare della gestione delle query piuttosto che un binario o script eliminato su disco.
Quella falla di progettazione è il motivo per cui CVE-2026-9082 colpisce prima la riservatezza e l’integrità, ma può anche aggravarsi ulteriormente a seconda della configurazione del sito. I rapporti citati dicono che uno sfruttamento riuscito può esporre dati sensibili, elevare i privilegi e, in alcuni ambienti, abilitare persino l’esecuzione di codice remoto. Cyber Press aggiunge che l’attacco non richiede autenticazione, il che aumenta il rischio per i siti accessibili da internet che eseguono rami vulnerabili di Drupal Core con PostgreSQL.
Da una prospettiva operativa, il rilevamento di CVE-2026-9082 è più probabile che si basi sull’inventario delle versioni e dei database piuttosto che su un set di firme stabile. L’avviso pubblico e i due rapporti non pubblicano un poc pubblico di CVE-2026-9082 o IOC concreti di CVE-2026-9082, quindi i difensori dovrebbero concentrarsi sull’identificazione dei rami Drupal vulnerabili, confermare se PostgreSQL è in uso e rivedere l’attività di richieste sospette intorno agli endpoint driven dalle query sul database.
Mitigazione CVE-2026-9082
La mitigazione principale per CVE-2026-9082 è installare l’ultima release di Drupal per il ramo interessato. L’avviso di Drupal elenca le versioni corrette come 11.3.10, 11.2.12, 11.1.10, 10.6.9, 10.5.10, e 10.4.10. Per i rami non supportati ma ancora ampiamente utilizzati, Drupal ha pubblicato patch manuali a miglior sforzo per Drupal 9.5 e Drupal 8.9, avvertendo che quelle release a fine vita potrebbero ancora contenere altri problemi di sicurezza precedentemente noti.
Per rilevare l’esposizione a CVE-2026-9082 nella pratica, le organizzazioni dovrebbero prima inventariare ogni installazione di Drupal, mappare ogni sito alla sua versione esatta e verificare se il database di backend è PostgreSQL. Quel passaggio è critico perché il percorso di iniezione SQL è specifico di PostgreSQL, ma gli aggiornamenti di framework inclusi rendono comunque importante applicare patch per tutti i rami supportati.
Dove la correzione immediata è ritardata, i team dovrebbero dare priorità ai siti accessibili pubblicamente che accettano traffico anonimo e rivedere la funzionalità intensiva del database per schemi di richieste anomali. Poiché i materiali citati non includono telemetria delle esplorazioni o regole di rilevamento pubblico, la strategia a breve termine più affidabile è l’applicazione aggressiva delle patch, la convalida dei rami e la revisione di eventuali ruoli o moduli contribuiti che consentono aggiornamenti dei template Twig.
FAQ
Cos’è CVE-2026-9082 e come funziona?
CVE-2026-9082 è una falla di iniezione SQL nel Core di Drupal nell’API di astrazione del database. Funziona permettendo che richieste appositamente create aggirano la logica di sanificazione prevista delle query ed eseguano SQL arbitrario contro i siti Drupal supportati da PostgreSQL.
Quando è stato scoperto per la prima volta CVE-2026-9082?
Le fonti pubbliche non divulgano una data di scoperta privata, ma Drupal ha pubblicato SA-CORE-2026-004 il 20 maggio 2026 e accredita Michael Maturi per la segnalazione del problema.
Qual è l’impatto di CVE-2026-9082 sui sistemi?
L’impatto principale è l’iniezione SQL arbitraria su siti supportati da PostgreSQL, che può portare a divulgazione di informazioni e, in alcuni casi, escalation dei privilegi, esecuzione di codice remoto o altri attacchi. Drupal afferma anche che il problema è sfruttabile da utenti anonimi.
CVE-2026-9082 può ancora colpirmi nel 2026?
Sì. I siti possono essere ancora esposti nel 2026 se rimangono su versioni vulnerabili di Drupal Core e utilizzano PostgreSQL come database di backend. Le distribuzioni non supportate di Drupal 8 e 9 possono essere a rischio aggiuntivo perché non ricevono più la normale copertura di sicurezza.
Come posso proteggermi da CVE-2026-9082?
Aggiorna all’ultimo rilascio corretto di Drupal per il tuo ramo, conferma se PostgreSQL è in uso, applica patch di miglior sforzo se sei ancora su Drupal 8.9 o 9.5 e dai priorità ai siti che accolgono traffico anonimo per una mitigazione immediata. È inoltre raccomandato l’aggiornamento per siti non PostgreSQL perché la stessa release include correzioni di sicurezza upstream per Symfony e Twig.
