PostgreSQL corregge 52 falle, tra cui un bug vecchio di 22 anni che permette di eseguire codice sul server

Il progetto PostgreSQL ha pubblicato un ciclo di aggiornamenti di sicurezza che chiude 52 vulnerabilità in un colpo solo. Una spicca sulle altre: è tracciata come CVE-2026-6460, ha un punteggio di gravità CVSS pari a 8.8 su 10 ed è presente nel codice da circa 22 anni. Si tratta di una falla di tipo «type confusion», cioè una confusione di tipi. Il programma tratta un dato come se fosse di un genere diverso da quello reale, e questo errore può essere sfruttato per fargli fare cose che non dovrebbe.

Chi sfrutta il difetto deve già avere un accesso al database e la possibilità di creare oggetti al suo interno, come tabelle o funzioni. Il risultato, però, va ben oltre i dati. L'utente può far girare codice sul server e quel codice agisce con i diritti dell'account del sistema operativo che esegue PostgreSQL. Le patch sono state rilasciate ieri. La fonte avverte che applicarle non basta per essere al sicuro: vanno ricompilate anche le estensioni scritte in linguaggio C installate sul server.

Che cosa significa una «confusione di tipi»

Per spiegarlo in modo semplice, si può pensare a un magazziniere che riceve una scatola etichettata «libri» e la tratta come tale, mentre dentro c'è altro. Nel software accade qualcosa di simile. Un pezzo di codice si aspetta un certo tipo di dato in memoria e ne riceve uno diverso. Se chi attacca riesce a orchestrare lo scambio, può spingere il programma a leggere o interpretare la memoria in modi non previsti. In molti casi questo apre la strada all'esecuzione di codice arbitrario.

Nel caso di CVE-2026-6460 la fonte parla di una falla rimasta nascosta per oltre due decenni. Non riporta i dettagli tecnici del meccanismo, e qui non li ricostruiamo. Il dato che conta per chi gestisce database è la conseguenza pratica. Un difetto così vecchio ha attraversato moltissime versioni e installazioni, e per questo l'esposizione potenziale è ampia, anche se lo sfruttamento richiede condizioni precise.

Un difetto nascosto per 22 anni trasforma un semplice account di database in un accesso al server.

Chi è davvero a rischio e perché «autenticato» non basta a rassicurare

La vulnerabilità richiede un utente che esista già nel database e che abbia il permesso di creare oggetti. Per questo la si definisce RCE autenticata, dove RCE sta per esecuzione di codice da remoto. Non è un attacco che qualsiasi sconosciuto può lanciare da Internet senza credenziali. Il punteggio 8.8, comunque alto, riflette la gravità dell'esito: da un account di database si arriva a comandi sul sistema operativo.

Nella pratica quel requisito è meno rassicurante di quanto sembri. Credenziali rubate, applicazioni web con difetti di iniezione SQL, account condivisi tra più servizi o ambienti in cui molti utenti hanno ampi permessi sono scenari comuni. In ognuno di questi basta un accesso modesto per trasformare un incidente sui dati in una compromissione dell'intero server. Poiché il codice parte con i diritti dell'utente del sistema operativo che esegue PostgreSQL, un attaccante potrebbe poi leggere i file del database e muoversi verso altre risorse raggiungibili da quella macchina.

Le patch non bastano: le estensioni in C vanno ricompilate

L'indicazione operativa più delicata riguarda le estensioni. Sono moduli aggiuntivi che ampliano PostgreSQL, e alcune sono scritte in C e compilate contro una versione specifica del database. Secondo la fonte, per ottenere una protezione completa dalla falla vanno ricostruite anche quelle già installate. Aggiornare solo il motore principale potrebbe quindi lasciare scoperto un pezzo del sistema, con la falsa sensazione di aver risolto.

Per i team che gestiscono PostgreSQL il lavoro va oltre l'installazione del pacchetto. Servono un inventario delle estensioni presenti, la verifica di quali siano in C, la ricompilazione e un riavvio controllato. Vanno poi riesaminati i permessi di creazione degli oggetti, spesso concessi in modo più largo del necessario. Restano altre 51 correzioni nello stesso rilascio. È un buon motivo per non trattare l'aggiornamento come un intervento facoltativo da rimandare.

-- Versione del server in esecuzione
SHOW server_version;

-- Estensioni installate (da verificare/ricompilare se scritte in C)
SELECT extname, extversion FROM pg_extension ORDER BY extname;

-- Funzioni scritte in C presenti nel database (linguaggio 'c')
SELECT p.proname, n.nspname FROM pg_proc p JOIN pg_language l ON l.oid = p.prolang JOIN pg_namespace n ON n.oid = p.pronamespace WHERE l.lanname = 'c';

-- Ruoli con privilegio di creare oggetti nel database corrente
SELECT r.rolname FROM pg_roles r WHERE has_database_privilege(r.rolname, current_database(), 'CREATE') AND r.rolcanlogin;

Perché conta. PostgreSQL è uno dei database open source più diffusi e spesso sta al centro di applicazioni critiche. Una falla che porta da un account di database all'esecuzione di codice sul server può trasformare una violazione limitata in una compromissione totale. L'avvertenza sulle estensioni in C è la parte più insidiosa: chi installa solo la patch del motore potrebbe credersi protetto senza esserlo. Per questo la notizia riguarda sia chi amministra i database sia chi decide le priorità di aggiornamento.