PostgreSQL, un bug vecchio di 22 anni permette di eseguire codice sul server: corretti 52 difetti

Il progetto PostgreSQL ha rilasciato aggiornamenti di sicurezza che chiudono 52 vulnerabilità. Tra queste spicca una falla rimasta nascosta per ventidue anni, catalogata come CVE-2026-6460 e valutata 8,8 su 10 nella scala CVSS, lo standard che misura la gravità dei difetti. Il punteggio la colloca nella fascia alta: non è il livello massimo, ma abbastanza da imporre una risposta rapida a chi gestisce database in produzione.

Il problema è di tipo "type confusion", cioè confusione di tipo: il software tratta un dato come se fosse di una natura diversa da quella reale, e questo errore può essere sfruttato per far accadere cose che gli sviluppatori non avevano previsto. In questo caso l'esito è l'esecuzione di codice arbitrario sul server (in gergo RCE, remote code execution). C'è però un passaggio in più rispetto alle correzioni di routine: per essere davvero al riparo non basta aggiornare il database, bisogna anche ricompilare le estensioni scritte in linguaggio C installate sul sistema.

Che cosa permette di fare la falla

Secondo quanto riportato, a poter sfruttare il difetto è un utente del database che ha già un accesso valido e il permesso di creare oggetti, come tabelle, funzioni o altri elementi della struttura dati. Si parla perciò di vulnerabilità autenticata: serve un account, non basta affacciarsi dall'esterno. Il dettaglio non va sottovalutato, perché in molte aziende account con questi privilegi esistono in gran numero, tra applicazioni, strumenti di analisi e collaboratori esterni.

Il salto di qualità è nel risultato. Partendo da un account di database, l'attaccante può far girare codice sul server che ospita PostgreSQL, uscendo dal perimetro dei dati per arrivare al sistema operativo. Il codice eseguito in questo modo ottiene i diritti dell'utente del sistema operativo con cui il database è in funzione. Quanto sia grave dipende quindi da come il servizio è configurato: un processo con pochi permessi limita il danno, uno con privilegi ampi lo amplifica.

Per chiudere davvero la falla non basta aggiornare il database: vanno ricostruite anche le estensioni scritte in C.

Un errore rimasto in circolazione per due decenni

Il fatto che il difetto avesse ventidue anni dice qualcosa sul modo in cui nascono e sopravvivono le vulnerabilità nei grandi progetti software. Il codice che gestisce i tipi di dato è tra le parti più delicate di un database, ed errori sottili possono passare inosservati per generazioni di versioni, fino a quando qualcuno non li esamina con l'approccio giusto. Non significa che il bug sia stato sfruttato per tutto questo tempo: la fonte non lo afferma, e l'anzianità indica solo da quanto era presente nel codice.

L'aggiornamento arriva insieme ad altre 51 correzioni di sicurezza, per un totale di 52. È un pacchetto ampio, e anche se la CVE-2026-6460 è quella che attira l'attenzione, chi rimandasse l'installazione per concentrarsi su una sola falla rischierebbe di lasciare aperte molte altre porte. Per l'elenco puntuale delle versioni interessate e di quelle corrette conviene consultare gli avvisi ufficiali del progetto.

Le estensioni in C: il passaggio che molti dimenticheranno

Le estensioni sono moduli aggiuntivi che ampliano le funzioni del database. Quelle scritte in linguaggio C sono compilate, cioè trasformate in codice macchina legato alla versione di PostgreSQL con cui sono state costruite. Per questo la fonte precisa che la protezione completa dalla falla richiede di ricostruirle: installare i nuovi binari del database senza rigenerare questi moduli può lasciare una parte del rischio ancora in piedi.

Dal punto di vista operativo è l'aspetto più insidioso, perché un aggiornamento di sicurezza viene spesso trattato come una semplice sostituzione di pacchetti. Qui serve invece un inventario: sapere quali estensioni sono installate, da dove provengono e chi le mantiene. Se un modulo viene da un fornitore terzo, occorre verificare che ne sia disponibile una versione ricompilata. Nel frattempo ha senso rivedere chi, nei database, possiede il permesso di creare oggetti, e ridurlo al minimo necessario.

-- 1) Versione del server in uso
SELECT version();

-- 2) Estensioni installate
SELECT extname, extversion FROM pg_extension ORDER BY extname;

-- 3) Funzioni implementate in linguaggio C (da ricompilare/verificare)
SELECT p.proname, p.probin FROM pg_proc p JOIN pg_language l ON l.oid = p.prolang WHERE l.lanname = 'c' ORDER BY p.probin, p.proname;

-- 4) Database in cui il ruolo PUBLIC o altri possono creare oggetti
SELECT datname, datacl FROM pg_database;

Perché conta. PostgreSQL è uno dei database open source più diffusi e custodisce dati spesso critici. Una falla che trasforma un normale account con permessi di creazione in esecuzione di codice sul server può diventare il punto di partenza per compromettere l'intera macchina. La necessità di ricompilare le estensioni C rende la correzione meno immediata del solito: chi si limita ad applicare l'aggiornamento rischia di credersi al sicuro senza esserlo del tutto.