PostgreSQL: 52 CVE corrette, ma il fix richiede ricompilazione estensioni

Il PostgreSQL Global Development Group ha rilasciato il 12 novembre 2026 aggiornamenti di sicurezza che correggono 52 vulnerabilità, tra cui CVE-2026-6460, un bug di type confusion presente nel codice dal 2004 che permette esecuzione di codice remoto autenticato con punteggio CVSS 8.8. La protezione effettiva non si limita all'aggiornamento del server: richiede la ricompilazione completa di tutte le estensioni C-language contro le nuove intestazioni, altrimenti il sistema resta esposto nonostante un apt upgrade apparentemente riuscito.

Un bug di 22 anni: come la type confusion diventa RCE

Il difetto al centro di CVE-2026-6460 risiede nella gestione dei composite types. Quando un amministratore esegue ALTER TABLE ... SET DATA TYPE, PostgreSQL aggiorna il tuple descriptor che definisce la struttura dei dati, ma i dati esistenti sul disco conservano il formato originario. Questo mismatch tra descriptor e payload effettivo genera una condizione di type confusion: i vecchi byte vengono letti come se appartenessero al nuovo tipo, con conseguenze che vanno dal crash all'esecuzione di codice.

Mehmet Ince, ricercatore di sicurezza che ha pubblicato un exploit funzionante dimostrato su PostgreSQL 18.6, ha tracciato la radice del difetto al 5 maggio 2004. La tecnica specifica per l'esecuzione di codice si basa invece su una modifica successiva del 14 maggio 2015. Il ricercatore ha condiviso il proof-of-concept con provider managed — AWS, Azure, GCP, Supabase, Databricks, Ubicloud — già in agosto 2026.

L'attacco richiede privilegi CREATE: l'attaccante deve poter creare oggetti nel database. Con questi permessi, manipola i composite types per far sì che vecchi byte vengano interpretati come puntatori o metadati di altro tipo, ottenendo infine l'esecuzione di codice con i privilegi del processo server PostgreSQL. Secondo la fonte citata, il ricercatore ha dimostrato il crash "come un ruolo di login con i privilegi più bassi".

Il cambio di ABI: quando il server aggiornato non basta

Il PostgreSQL Global Development Group ha introdotto nel fix un meccanismo di attribute versioning. Il commit 245eb832f converte DatumGetHeapTupleHeader() da macro a funzione server e aggiunge heap_datum_check(), una nuova funzione di validazione che marca i composite datums e versiona quelli denominati. Questa modifica, tecnicamente necessaria per chiudere la superficie di attacco, altera l'Application Binary Interface delle estensioni C.

Le conseguenze sono binarie e asimmetriche. Le estensioni compilate contro le intestazioni precedenti, su un server aggiornato, si caricano regolarmente ma non eseguono i nuovi controlli heap_datum_check(). Il sistema sembra funzionante, la vulnerabilità resta sfruttabile. Viceversa, le estensioni ricompilate con le nuove intestazioni, su server non aggiornati, falliscono con errore undefined symbol. I package maintainer dei RPM PostgreSQL hanno messo in guardia esplicitamente: le estensioni vecchie su server nuovi "may not be protected from the vulnerabilities fixed in this release".

Questo scenario crea una falla di sicurezza insidiosa. L'amministratore che esegue sudo apt upgrade, vede "nessun aggiornamento disponibile" o il server riavviato correttamente, assume la protezione ottenuta. Le estensioni come PostGIS, pgvector, pg_cron, TimescaleDB — tutte compilate in C — continuano a operare con l'ABI vecchia, bypassando silenziosamente i controlli di sicurezza. Come riporta Byteiota: "Running sudo apt upgrade and seeing 'nothing to upgrade' does not mean you are protected".

Il perimetro delle 52 falle: RCE server-side e client vulnerabili

Oltre a CVE-2026-6460, il rilascio comprende 52 vulnerabilità con profili diversi. Secondo Corgea, 29 CVE nel titolo descrivono esecuzione di codice lato server, mentre 6 richiedono solo autenticazione senza privilegi aggiuntivi. Un'eccezione rilevante è CVE-2026-116322: secondo The Hacker News, è l'unica vulnerabilità del batch che non richiede autenticazione e permette a client non autenticati di riavviare server PostgreSQL 18.

Anche gli strumenti client sono interessati. Corgea documenta falle in pg_dump (CVE-2026-116318, CVE-2026-116330), pg_restore (CVE-2026-116314), reindexdb e vacuumdb. CVE-2026-116318 è una SQL injection in pg_dump: nomi di constraint non quotati tramite fmtId() vengono iniettati direttamente nell'output del dump. Il commit 9e4cde7927 mostra la correzione. Per CVE-2026-116330, il commit GitHub 17e57d06cd3a3966143502626a2f5c7534f8309c rende le chiavi \restrict protettive nel formato tar di pg_dump.

Cosa fare adesso

• Aggiornare alle versioni corrette: 18.7, 17.12, 16.16, 15.20, oppure 14.25 come ultimo rilascio prima dell'end-of-life di PostgreSQL 14.
• Ricompilare tutte le estensioni C-language — PostGIS, pgvector, pg_cron, TimescaleDB e altre installate localmente — contro le nuove intestazioni del server aggiornato.
• Verificare esplicitamente le immagini container e i repository di pacchetti gestiti: i provider cloud applicano patch su schedule propri, e le immagini ufficiali possono non includere estensioni ricompilate.
• Pianificare la migrazione da PostgreSQL 14: il branch è end-of-life, 14.25 è l'ultimo aggiornamento di sicurezza disponibile, non ne arriveranno altri.

Il progetto PostgreSQL ha aggiunto un nuovo parametro composite_type_mismatch ma ha avvisato esplicitamente contro il suo uso per disabilitare i controlli di sicurezza. Nessun workaround alternativo è documentato per sistemi che non possono essere aggiornati immediatamente.

Perché questo rilascio è un caso di studio

Il caso di CVE-2026-6460 illustra un problema strutturale della sicurezza nei sistemi modulari. La modularità estesa — estensioni di terze parti compilate nel linguaggio nativo del server — crea una superficie di attacco che i meccanismi di aggiornamento standard non coprono. Il package manager del sistema operativo aggiorna il binario principale, ma non ha visibilità né controllo sulle estensioni installate via CREATE EXTENSION o compilate manualmente.

La discrepanza tra "server aggiornato" e "sistema protetto" genera una falsa sensazione di sicurezza che può persistere per settimane, finché un audit o un test di penetrazione non rivela l'estensione vulnerabile ancora in esecuzione. I team DevOps che operano in ambienti containerizzati devono inoltre verificare che le immagini di base ricostruite includano effettivamente la ricompilazione, non solo il pull del pacchetto PostgreSQL.

Nessuna exploitation in-the-wild è confermata al momento della pubblicazione; secondo la fonte citata, CISA valuta l'exploitation come "none". Tuttavia, la disponibilità di un exploit pubblico e la notifica ai provider managed già da agosto 2026 amplificano la finestra di rischio per gli ambienti non ancora aggiornati.

"Using a tuple descriptor that does not match the 'shape' of a composite datum can lead to crashes, spurious errors and can be used for exploits. This commit introduces a new safety layer... composite datums are marked as such and named composite datums are versioned" — Commit 245eb832f (via Corgea)

Domande frequenti

Un semplice apt upgrade protegge il mio server?

No. L'aggiornamento del pacchetto PostgreSQL installa il server corretto, ma le estensioni C-language esistenti conservano l'ABI vecchia e non eseguono i nuovi controlli di sicurezza. La ricompilazione è necessaria per la protezione effettiva.

Quali estensioni richiedono ricompilazione?

Tutte le estensioni scritte in C, che secondo le fonti citate includono comunemente PostGIS, pgvector, pg_cron e TimescaleDB. Il criterio non è il nome ma il linguaggio di implementazione: le estensioni in SQL o PL/pgSQL non sono interessate dal cambio di ABI.

PostgreSQL 14 è ancora supportato?

No. PostgreSQL 14 ha raggiunto l'end-of-life con il rilascio 14.25; non riceverà ulteriori aggiornamenti di sicurezza. Le organizzazioni su questo branch devono pianificare la migrazione a PostgreSQL 15 o successivi.

Fonti

• thehackernews.com
• news.lavx.hu
• simplysecuregroup.com
• corgea.com
• byteiota.com
• news.lavx.hu
• news.lavx.hu
• cisa.gov
• github.com