PostgreSQL CVE-2026-6460: gli utenti del database che possono creare oggetti possono eseguire codice sul server

Cosa è successo

Il 12 novembre 2026 il PostgreSQL Global Development Group ha rilasciato PostgreSQL 18.7, 17.12, 16.16, 15.20 e 14.25. Secondo The Hacker News, queste versioni correggono 52 vulnerabilità di sicurezza. La più grave è CVE-2026-6460 (CVSS 8.8), una vulnerabilità di confusione di tipo nel server principale.

Un utente del database che può creare oggetti può usare ALTER ... SET DATA TYPE per far leggere al server un valore obsoleto come se avesse un nuovo tipo. Altre istruzioni DDL possono fare lo stesso, ad esempio ALTER TABLE ... ADD COLUMN; ROLLBACK; ALTER TABLE ... ADD COLUMN. In questo modo l'utente può eseguire codice arbitrario con l'utente del sistema operativo che avvia PostgreSQL. La correzione aggiunge controlli di versione, così il server può riconoscere i valori che non corrispondono più al loro tipo.

Il ricercatore di sicurezza Mehmet Ince ha pubblicato un approfondimento tecnico con un exploit funzionante, che ha dimostrato su PostgreSQL 18.6. L'approfondimento include l'SQL che manda in crash un server non aggiornato e un passaggio che rivela indirizzi di memoria. Non include il passaggio finale che esegue un comando. Ince ha scritto di aver potuto provocare il crash con un ruolo di accesso con i privilegi più bassi. Le fonti non dicono se un account con i soli privilegi predefiniti possa andare oltre ed eseguire codice. Red Hat afferma che un attaccante ha bisogno di un accesso al database che possa creare o modificare oggetti.

Il progetto PostgreSQL non ha segnalato attacchi che sfruttino questa vulnerabilità, e CISA non la elenca tra quelle sfruttate.

Le stesse versioni correggono altre vulnerabilità, tra cui CVE-2026-116322, che consente a un client non autenticato di costringere i server PostgreSQL 18 a riavviarsi. Correggono inoltre vulnerabilità negli strumenti client: un archivio appositamente creato può far eseguire codice a pg_restore con l'utente che lo avvia, e un server di origine compromesso può far eseguire codice a psql tramite lo script di ripristino nell'output tar di pg_dump.

Chi è interessato

• PostgreSQL 18 precedenti a 18.7, 17 precedenti a 17.12, 16 precedenti a 16.16, 15 precedenti a 15.20 e 14 precedenti a 14.25.
• Anche le versioni principali più vecchie sono interessate e non riceveranno un aggiornamento. PostgreSQL 14 è ora fuori supporto, e 14.25 è la sua ultima versione.
• Il rischio è massimo sui server dove persone di cui non si fida completamente hanno un accesso al database che può creare o modificare oggetti. Questo include l'hosting condiviso, i database affidati ai clienti e le applicazioni web il cui account database è proprietario del proprio schema. Se un attaccante prende il controllo di una di queste applicazioni, ad esempio tramite SQL injection, potrebbe usarne l'account database in questo modo.
• Servizi gestiti: il ricercatore ha condiviso le proof of concept con AWS (RDS, Aurora), Microsoft (Azure PostgreSQL), Google (AlloyDB), Supabase, Databricks e Ubicloud. Lo stato attuale delle loro patch non è noto. Controlli gli avvisi del Suo fornitore.
• I server che non eseguono PostgreSQL non sono interessati. MySQL e MariaDB non sono interessati.

Cosa fare ora

1. Esegua il backup della configurazione di PostgreSQL (ad esempio postgresql.conf e pg_hba.conf) e si assicuri di avere un backup aggiornato del database.
2. Aggiorni il server alla versione corretta per la Sua versione principale: 18.7, 17.12, 16.16, 15.20 o 14.25. Se utilizza pacchetti della Sua distribuzione (Debian, Ubuntu, RHEL e derivate), installi i pacchetti corretti indicati nell'avviso della distribuzione non appena disponibili. Poi usi il gestore dei pacchetti come di consueto (apt update && apt upgrade oppure dnf upgrade).
3. Aggiorni o ricompili ogni estensione in linguaggio C contemporaneamente al server. I manutentori RPM del progetto avvertono che le estensioni compilate con versioni precedenti continuano a caricarsi, ma potrebbero non essere protette. Alcune estensioni richiedono anche modifiche al codice sorgente. I pacchetti di estensione nei repository RPM di PostgreSQL ora richiedono la nuova versione minore.
4. Riavvii PostgreSQL. Se viene eseguito al di fuori della unit di servizio del proprio pacchetto, ad esempio sotto Patroni, lo riavvii manualmente subito dopo l'aggiornamento.
5. Segua i passaggi di reindicizzazione indicati nell'annuncio ufficiale del rilascio. Se utilizza backup incrementali, esegua un nuovo backup completo e basi su di esso i futuri backup incrementali.
6. Aggiorni gli strumenti client come pg_dump, pg_restore, psql, reindexdb e vacuumdb su ogni macchina che li utilizza, inclusi gli host di backup e le postazioni degli amministratori.
7. Non usi la nuova impostazione composite_type_mismatch per disattivare i nuovi controlli. Il progetto afferma che farlo comporta rischi per la sicurezza.
8. Se non può aggiornare subito, tenga presente che il progetto non offre alcuna soluzione alternativa. Finché non potrà aggiornare, verifichi quali account possono creare o modificare oggetti, in particolare gli account usati dalle applicazioni web o affidati ai clienti, e si assicuri che PostgreSQL non sia raggiungibile da internet se non è necessario.
9. Se utilizza ancora PostgreSQL 14 o una versione più vecchia, pianifichi un passaggio a una versione principale supportata.

Come verificare se è interessato

• Verifichi la versione del server in esecuzione con psql -c 'SELECT version();' oppure SHOW server_version;. Le versioni inferiori a 18.7, 17.12, 16.16, 15.20 o 14.25 all'interno della rispettiva serie principale sono interessate.
• Verifichi i binari e i pacchetti installati con postgres -V, dpkg -l | grep postgresql oppure rpm -qa | grep postgresql. Riavvii il server se la versione in esecuzione è più vecchia di quella installata.
• Elenchi le estensioni installate con SELECT extname, extversion FROM pg_extension; in ogni database. Si assicuri che ogni estensione in C sia stata aggiornata o ricompilata per la nuova versione.
• Controlli i log di PostgreSQL per individuare crash imprevisti dei backend, come processi del server terminati da un segnale. L'exploit pubblicato manda in crash i server non aggiornati, quindi questi crash meritano un'analisi più attenta.

Fonti

• https://nvd.nist.gov/vuln/detail/CVE-2026-6460
• https://www.postgresql.org/support/security/CVE-2026-6460/