PostgreSQL corregge un bug di 22 anni fa che permette di eseguire codice sul server

Il progetto PostgreSQL ha rilasciato il 12 novembre gli aggiornamenti 18.7, 17.12, 16.16, 15.20 e 14.25. Secondo il progetto, correggono 52 vulnerabilità e oltre 140 altri bug. La più discussa è CVE-2026-6460, con un punteggio di 8,8 su 10: un utente del database autorizzato a creare oggetti può eseguire codice proprio sul server con i permessi dell'utente di sistema che fa girare PostgreSQL. Il progetto ha dato lo stesso punteggio ad altre 31 vulnerabilità di questo rilascio. Finora non sono stati segnalati attacchi che sfruttino CVE-2026-6460.

Perché il bug ha 22 anni

La falla riguarda i tipi compositi, cioè tipi formati da più campi con un nome. Il tipo di un campo può essere cambiato mentre valori più vecchi restano in altre parti del server, che poi legge un vecchio valore come se avesse già il nuovo tipo. Nel suo avviso il progetto ammette che il sistema tracciava male il tipo dei valori. Il ricercatore Mehmet Ince, che ha mostrato un exploit funzionante sulla versione 18.6, fa risalire il problema al 5 maggio 2004, quando PostgreSQL ha introdotto la possibilità di cambiare il tipo di una colonna, riporta The Hacker News.

Secondo Ince, è riuscito a mandare in crash un server non aggiornato con il ruolo meno privilegiato. Nessuna delle fonti chiarisce se con un account del genere si arrivi anche a eseguire codice. Ad agosto ha adattato l'exploit ai database gestiti e lo ha condiviso con i team di sicurezza di AWS, Microsoft Azure, Google, Supabase, Databricks e Ubicloud. Non è noto se tutti abbiano già applicato la correzione.

Chi deve preoccuparsi

Soprattutto chi fa entrare altre persone nello stesso database: hosting, servizi cloud e qualsiasi progetto che dà ai clienti un proprio account PostgreSQL. Se con il database parla solo la vostra applicazione, un attaccante esterno dovrebbe prima ottenere dei permessi al suo interno. Sono stati corretti anche gli strumenti client: un archivio preparato ad arte può far eseguire a pg_restore del codice sul computer di chi ripristina il database. Solo una delle 52 vulnerabilità funziona senza login, e permette di riavviare un server PostgreSQL 18.

Non è l'unico aggiornamento lato server della settimana da installare senza aspettare: di recente abbiamo scritto di una falla HTTP/2 in Apache.

Cosa fare

• Aggiornate il server a 18.7, 17.12, 16.16, 15.20 o 14.25 in base alla versione principale. Non serve esportare e ricaricare il database.
• Ricompilate o aggiornate tutte le estensioni in C contemporaneamente. Le vecchie build si caricano ancora, ma secondo i manutentori dei pacchetti RPM potrebbero restare senza protezione.
• Aggiornate pg_dump, pg_restore, reindexdb e vacuumdb su tutte le macchine che li usano.
• Se PostgreSQL gira fuori dall'unità di servizio del pacchetto, per esempio sotto Patroni, riavviatelo subito dopo l'aggiornamento.
• Non disattivate i nuovi controlli con l'impostazione composite_type_mismatch: il progetto avverte che è un rischio per la sicurezza.
• Seguite i passaggi della sezione «Updating» dell'annuncio: ricostruite gli indici interessati (GIN, GiST con pg_trgm, B-tree su colonne bpchar) e, se usate backup incrementali, fate un nuovo backup completo.
• Se usate la versione 14 o precedenti, pianificate la migrazione: dopo la 14.25 non ci saranno più correzioni.