PostgreSQL: 52 vulnerabilità corrette, guida per verificare e aggiornare i server

PostgreSQL: 52 vulnerabilità corrette, guida per verificare e aggiornare i server

Il 12 novembre PostgreSQL ha pubblicato aggiornamenti che correggono 52 vulnerabilità, tra cui CVE-2026-6460: un problema di confusione dei tipi che può consentire a un utente in grado di creare oggetti di eseguire codice con i permessi dell'account di sistema che esegue il database. La correzione non si completa sostituendo i binari del server: occorre anche ricompilare le estensioni scritte in C.

Il problema interessa le versioni precedenti a 18.7, 17.12, 16.16, 15.20 e 14.25, a seconda del ramo. PostgreSQL non ha segnalato attacchi che sfruttino CVE-2026-6460; ciò non elimina la necessità di applicare l'aggiornamento. La possibilità concreta di creare oggetti dipende dai permessi dell'account e non è chiaro se i privilegi predefiniti siano sufficienti per arrivare all'esecuzione di codice.

«trigger this crash as a lowest-privileged login role»

— Mehmet Ince, ricercatore di sicurezza

1. Identifica la versione e il tipo di installazione

Per prima cosa, scopri quale versione esegue ogni istanza, non solo quella installata sul tuo computer. IlSoftware.it indica che puoi consultare la versione da una sessione SQL con:

SELECT version();

Confronta il ramo principale restituito dalla query con la tabella e annota quali server devono essere aggiornati. Se PostgreSQL proviene dai repository di una distribuzione Linux, IlSoftware.it consiglia di controllare anche gli avvisi del fornitore: potrebbe aver integrato una correzione nel proprio pacchetto senza modificare il numero di versione che ti aspetti di vedere.

Ramo interessatoVersione corretta
1818.7
1717.12
1616.16
1515.20
1414.25

La tabella riporta le versioni corrette pubblicate dal PostgreSQL Global Development Group. PostgreSQL 14.25 è l'ultima versione di quel ramo; PostgreSQL 14 ha raggiunto la fine del ciclo di vita. Se usi ancora quel ramo, applica l'ultimo aggiornamento disponibile e pianifica la migrazione a una versione supportata.

2. Aggiorna il server alla revisione del tuo ramo

Installa la versione corretta corrispondente: per affrontare questo avviso non è necessario passare a un altro ramo principale. Le note di PostgreSQL 18.7 specificano che chi aggiorna all'interno della serie 18 non deve eseguire il dump e il ripristino del database. Non estendere questa indicazione a una migrazione tra rami: si riferisce all'esecuzione di un aggiornamento minore all'interno della serie 18.x.

Se il server viene eseguito al di fuori dell'unità di servizio del relativo pacchetto, per esempio sotto Patroni, un manutentore dei pacchetti RPM consiglia di riavviarlo subito dopo l'aggiornamento. Verifica come viene gestita ogni istanza e assicurati che il processo stia eseguendo i nuovi binari; non dare per scontato che basti installare il pacchetto.

3. Ricompila le estensioni scritte in C

Questa attività fa parte della correzione di CVE-2026-6460. PostgreSQL ha aggiunto controlli per rilevare valori composti il cui tipo non corrisponde più a quello previsto, ma per completare la protezione è necessario ricompilare le estensioni in linguaggio C per la versione aggiornata. Alcune richiedono anche modifiche al codice sorgente.

Aggiorna o ricompila tutte le estensioni C installate e verifica che i pacchetti disponibili per il tuo sistema siano già stati ricompilati. Se gestisci la compilazione, segui le istruzioni di ciascuna estensione e verifica che venga caricata di nuovo sul server aggiornato. La versione ricompilata potrebbe non caricarsi sui server meno recenti, quindi coordina entrambi gli aggiornamenti.

4. Aggiorna gli strumenti client

Gli avvisi riguardano anche componenti diversi dal server. The Hacker News segnala rischi nelle utilità client: un file di backup manipolato può indurre pg_restore a eseguire codice con i permessi dell'utente che lo avvia; un server di origine compromesso può indurre psql a eseguire codice tramite uno script di ripristino incluso in un output tar di pg_dump.

Aggiorna pg_dump, pg_restore, reindexdb e vacuumdb su ogni macchina che li utilizza. Includi i server di amministrazione, le workstation e i sistemi di automazione. Non eseguire ripristini da file non attendibili e non presumere che l'aggiornamento del motore aggiorni automaticamente gli strumenti installati su altri computer.

5. Controlla gli indici e i backup

Le note di PostgreSQL 18.7 segnalano diversi bug che possono corrompere gli indici e consigliano di esaminare le voci del registro delle modifiche che menzionano REINDEX. Individua quali indici della tua installazione potrebbero essere interessati e ricostruisci quelli, seguendo le istruzioni delle note di rilascio pertinenti; non trasformare il controllo in una ricostruzione indiscriminata di tutti gli indici.

Se utilizzi backup incrementali, considera non affidabili quelli esistenti: le note indicano che potrebbero essere stati corrotti. Dopo l'aggiornamento, crea un nuovo backup completo e usalo come base per i backup incrementali successivi. Non continuare a concatenare backup incrementali a partire da una base precedente all'aggiornamento.

6. Verifica lo stato delle istanze cloud

Mehmet Ince ha condiviso privatamente prove di concetto con i team di sicurezza di diversi fornitori, tra cui AWS, Microsoft, Google, Supabase, Databricks e Ubicloud. Tra i servizi citati figurano Aurora e RDS, Azure PostgreSQL e AlloyDB. Non è stato specificato lo stato attuale della patch per ciascun servizio.

Se utilizzi PostgreSQL gestito, verifica con il tuo fornitore se l'istanza ha già ricevuto la correzione e quale azione devi intraprendere. Non dare per scontato che tutti i servizi siano stati aggiornati contemporaneamente e non cercare di applicare autonomamente i passaggi previsti per un server autogestito se il motore è amministrato dal fornitore.

Errori da evitare

Non disattivare composite_type_mismatch per aggirare problemi di compatibilità. PostgreSQL avverte che disabilitare questi controlli comporta rischi per la sicurezza; alcune estensioni potrebbero richiedere modifiche al codice proprio per funzionare con la protezione attiva.

Non considerare nemmeno il firewall o l'assenza di attacchi noti come sostituti della patch. Secondo l'avviso del progetto, CVE-2026-6460 richiede un account in grado di creare oggetti, non un account superuser. L'aggiornamento è la misura principale; controllare i permessi non necessari può ridurre l'esposizione, ma non sostituisce l'aggiornamento.

Infine, non dimenticare i componenti che restano fuori dal processo di aggiornamento del server: estensioni C, utilità client, indici potenzialmente interessati e base dei backup incrementali. E se esegui ancora PostgreSQL 14, tieni presente che la versione 14.25 chiude quel ramo: la correzione non ne prolunga il supporto.

Fonti: The Hacker News, IlSoftware.it, VONNG, PostgreSQL Global Development Group, PostgreSQL Global Development Group