PostgreSQL, falla nascosta da 22 anni permette di eseguire codice

Una vulnerabilità rimasta nascosta per oltre 20 anni nel cuore di PostgreSQL può permettere a un utente con privilegi limitati di eseguire codice arbitrario sul server che ospita il database. Il problema, identificato come CVE-2026-6460, riguarda la gestione interna dei tipi di dato e apre la strada ad attacchi di Remote Code Execution (RCE), anche senza disporre delle autorizzazioni di superutente.

La scoperta arriva dal ricercatore di sicurezza Mehmet Ince, che ha ricostruito una catena di sfruttamento partendo da una funzionalità introdotta addirittura a maggio 2004. L’attacco sfrutta anche meccanismi aggiunti nel 2015 e dimostra come una caratteristica apparentemente innocua possa trasformarsi, dopo anni di evoluzione del software, in una vulnerabilità grave.

Il 12 novembre 2026, il PostgreSQL Global Development Group ha pubblicato aggiornamenti che correggono 52 vulnerabilità e oltre 140 bug, compreso il problema di sicurezza in questione: CVE-2026-6460 ha un punteggio CVSS 8,8 e coinvolge tutte le principali versioni supportate del database open source.

PostgreSQL: come nasce una vulnerabilità di 22 anni fa

Per comprendere il problema bisogna partire da un dettaglio dell’architettura di PostgreSQL: il database utilizza una rappresentazione generica chiamata Datum per trasferire valori tra le proprie funzioni interne.

Su una piattaforma a 64 bit, Datum occupa normalmente 8 byte e può contenere direttamente un intero oppure un puntatore a una struttura più complessa, ad esempio una stringa. Il tipo effettivo del valore non risiede però nel Datum stesso: PostgreSQL lo ricava dalle informazioni associate all’espressione e dai cataloghi di sistema, come pg_type.

Il fatto è che una modifica che interviene sulla definizione del tipo può rendere incoerente l’interpretazione di un valore già costruito.

Ince ha individuato un modo per provocare il problema sfruttando i prepared statement, le istruzioni SQL che PostgreSQL può analizzare e preparare prima dell’esecuzione.

Come una vulnerabilità PostgreSQL permette di eseguire codice sul server

Il problema non si limita a provocare il blocco del database: Ince ha dimostrato che l’errore nella gestione dei tipi di dato può avere conseguenze molto più gravi. Un malintenzionato può infatti arrivare a eseguire comandi direttamente sul sistema operativo che ospita PostgreSQL!

Il meccanismo sfrutta il modo in cui il database gestisce le informazioni temporaneamente conservate nella memoria. Alcuni valori contengono riferimenti ad altre aree di memoria, che PostgreSQL utilizza per recuperare ed elaborare i dati. A causa della vulnerabilità, però, il programma può scambiare una sequenza di byte fornita dall’utente per uno di tali riferimenti.

In pratica, l’attaccante riesce a far interpretare a PostgreSQL dati manipolati come se fossero informazioni interne attendibili. Preparando opportunamente i dati, l’aggressore può quindi alterare il normale flusso di esecuzione del programma, fino a richiamare funzioni del sistema operativo che consentono l’esecuzione di comandi.

Per completare l’attacco bisogna però superare un’ulteriore protezione: ASLR (Address Space Layout Randomization), tecnologia che – com’è noto – rende imprevedibile la posizione delle informazioni e delle funzioni nella memoria del processo.

Ince ha trovato il modo di aggirare anche questo ostacolo sfruttando la stessa vulnerabilità: attraverso una particolare combinazione di tipi di dato e istruzioni SQL, è riuscito a ottenere informazioni sugli indirizzi di memoria utilizzati da PostgreSQL. Una volta conosciuti tali indirizzi, diventa possibile costruire un attacco più preciso, senza procedere per tentativi.

Perché la falla CVE-2026-6460 è pericolosa anche lato cloud?

L’aspetto più preoccupante riguarda i privilegi necessari per sfruttare la falla: l’attaccante non deve possedere un account amministrativo PostgreSQL. Anche secondo l’advisory ufficiale, sono infatti sufficienti autorizzazioni più limitate per creare oggetti nel database.

Si pensi a un’applicazione Web che utilizza PostgreSQL per conservare i dati degli utenti: se un aggressore riesce a compromettere le credenziali di un account con le autorizzazioni richieste dall’exploit, potrebbe sfruttare la vulnerabilità per passare dall’accesso al database all’esecuzione di comandi sul server.

Il problema interessa anche i database PostgreSQL gestiti nel cloud: Ince ha condiviso le proprie scoperte con diversi operatori, tra cui AWS, Microsoft, Google, Supabase e Databricks, affinché potessero valutare l’esposizione dei rispettivi servizi e predisporre le opportune contromisure.

Le verifiche hanno inoltre evidenziato altri 21 casi riconducibili a problemi analoghi in differenti componenti interni di PostgreSQL. Il dato suggerisce che la vulnerabilità non derivi soltanto da un singolo controllo mancante, ma anche da alcune caratteristiche storiche dell’architettura del database.

Come proteggere PostgreSQL?

La misura principale consiste nell’aggiornare PostgreSQL a una versione che contenga la correzione: 18.7, 17.12, 16.16, 15.20 oppure 14.25, in base al ramo utilizzato. PostgreSQL 14 ha inoltre raggiunto la fine del supporto il 12 novembre 2026; chi lo utilizza dovrebbe programmare la migrazione a una versione pienamente supportata.

Per verificare la versione installata è sufficiente eseguire la query SQL SELECT version();.

Se PostgreSQL arriva dai repository di una distribuzione Linux, conviene consultare anche gli avvisi del produttore: alcune correzioni possono essere integrate nelle versioni distribuite senza modificarne il numero principale.

Un’altra precauzione riguarda i permessi degli account applicativi: è opportuno verificare quali utenti possano creare oggetti negli schemi PostgreSQL o tabelle temporanee, eliminando le autorizzazioni superflue. Ridurre i privilegi limita le possibilità di attacco, ma non sostituisce l’installazione delle patch.

Chi utilizza PostgreSQL attraverso un provider cloud dovrebbe invece verificare che il gestore abbia applicato le correzioni ai server interessati.