PostgreSQL, falla nel logical decoding permette di eseguire codice come utente `postgres`

PostgreSQL ha corretto CVE-2026-6471, una vulnerabilità nel sistema di logical decoding che consente di caricare librerie condivise arbitrarie sul server database.

Per sfruttarla non serve essere superuser. L’attaccante deve però disporre di un account PostgreSQL con attributo REPLICATION, mentre il server deve essere configurato con wal_level = logical.

Una volta caricata la libreria, il codice viene eseguito all’interno del processo backend con l’identità dell’account di sistema che gestisce PostgreSQL, normalmente postgres. Le conseguenze possono quindi comprendere furto o alterazione dei dati, indisponibilità del servizio, escalation dei privilegi e persistenza sul sistema.

La vulnerabilità, denominata PostGREShell dai ricercatori di Cyera, ha un punteggio CVSS 3.1 di 7,2 ed è classificata come assenza di un controllo di autorizzazione (CWE-862). Vladimir Tokarev e Yu Kunpeng sono stati accreditati dal PostgreSQL Global Development Group per la segnalazione. Tokarev ha pubblicato un’analisi tecnica il 1° settembre.

Quali versioni di PostgreSQL devono essere aggiornate

Le release upstream che correggono CVE-2026-6471, distribuite il 13 agosto, sono:

• PostgreSQL 18.6
• PostgreSQL 17.11
• PostgreSQL 16.15
• PostgreSQL 15.19
• PostgreSQL 14.24

Sono vulnerabili le versioni precedenti di ciascuno di questi cinque rami. L’advisory del progetto riguarda infatti le serie ancora supportate, dalla 14 alla 18.

Il difetto risale però all’introduzione del logical decoding in PostgreSQL 9.4, nel 2014. Le serie anteriori alla 14 non sono trattate dall’avviso upstream corrente: chi le utilizza dovrebbe quindi pianificare la migrazione verso una versione supportata, anziché considerare l’assenza dall’elenco come prova di sicurezza.

Pacchetti corretti sono disponibili anche per Amazon RDS, Debian, SUSE e Ubuntu. L’avviso Ubuntu USN-8653-1, pubblicato il 20 agosto 2026, distribuisce queste versioni:

Ubuntu	Pacchetto corretto
26.04 LTS	postgresql-18 18.6-0ubuntu0.26.04.1
24.04 LTS	postgresql-16 16.15-0ubuntu0.24.04.1
22.04 LTS	postgresql-14 14.24-0ubuntu0.22.04.1

Ubuntu richiede il riavvio di PostgreSQL dopo il normale aggiornamento di sicurezza. Il pacchetto risolve anche numerose altre vulnerabilità, non soltanto quella nel logical decoding.

PostgreSQL 14, inoltre, terminerà la ricezione delle correzioni il 12 novembre 2026. Le organizzazioni ancora su questo ramo dovrebbero includere nel piano operativo anche il passaggio a una release successiva.

Dal nome del plugin a dlopen(): come avviene l’attacco

Il logical decoding traduce le modifiche registrate nel write-ahead log in un formato utilizzabile da sistemi esterni. Viene impiegato, per esempio, nelle pipeline di change data capture e da strumenti che trasferiscono le modifiche verso altre piattaforme.

Durante la creazione di uno slot di replicazione, anche mediante CREATE_REPLICATION_SLOT, il client può indicare il plugin di output da utilizzare. Prima della correzione, PostgreSQL non verificava adeguatamente che un utente con REPLICATION fosse autorizzato a caricare la libreria richiesta.

Il nome del plugin arrivava così alla funzione di caricamento dinamico. Il parser del protocollo di replicazione accettava nei nomi racchiusi tra virgolette separatori di directory, percorsi assoluti e sequenze di attraversamento come ../.

Il risultato era un’invocazione di dlopen() su un file scelto dall’attaccante, purché accessibile all’account del sistema operativo che esegue PostgreSQL. La libreria veniva caricata nello spazio del processo backend e il suo codice acquisiva i privilegi dell’utente postgres.

Le normali restrizioni applicate dal comando SQL LOAD agli utenti non superuser non coprivano questo percorso. Era dunque possibile aggirare una protezione già esistente passando dal protocollo di replicazione.

La disponibilità della libreria malevola dipende dalla piattaforma:

• su Windows, il percorso può puntare a una condivisione SMB controllata dall’attaccante, senza prima copiare il file sul server;
• su Linux e macOS, un caricamento analogo dalla rete richiede che sia attivo l’automount NFS;
• negli altri scenari, l’attaccante deve già disporre di un modo per scrivere la libreria sul disco del server.

Nei test di Cyera, il codice caricato ha modificato direttamente il catalogo dei ruoli, trasformando l’account di replicazione in un superuser PostgreSQL. I ricercatori hanno anche realizzato tre forme di persistenza capaci di sopravvivere al riavvio.

Il privilegio richiesto non è superuser, ma resta sensibile

Il vettore completo assegnato alla falla è CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H. Indica un attacco eseguibile da remoto, di bassa complessità e senza interazione dell’utente, ma subordinato a privilegi elevati.

La classificazione PR:H può sembrare in contrasto con il fatto che l’account non debba essere amministratore. In realtà descrive un prerequisito specifico: l’attributo REPLICATION deve essere già stato concesso.

Questo privilegio viene spesso assegnato ad account tecnici usati da server standby, soluzioni di backup, piattaforme CDC e sistemi di monitoraggio. La compromissione di una di queste credenziali può quindi trasformarsi in esecuzione di codice sul sistema operativo.

Non risultano proof-of-concept pubblici nei repository esaminati al 4 settembre. Alla stessa data, CVE-2026-6471 non compariva nel catalogo CISA Known Exploited Vulnerabilities e non aveva una scadenza KEV associata.

Non vi sono dunque elementi pubblici che attestino uno sfruttamento attivo. L’impatto resta comunque rilevante, soprattutto dove gli account di servizio sono condivisi, poco monitorati o autorizzati a collegarsi da reti estese.

La patch introduce una whitelist per i plugin di output

La correzione aggiunge il parametro server:

output_plugin_libraries

Il valore predefinito autorizza due librerie:

pgoutput, test_decoding

Dopo l’aggiornamento, plugin di terze parti come wal2json e decoderbufs devono essere inseriti esplicitamente nella whitelist. In caso contrario, gli slot che li utilizzano non potranno avviare correttamente il logical decoding.

Prima di installare la patch, gli amministratori possono individuare i plugin già associati agli slot con:

SELECT DISTINCT plugin
FROM pg_replication_slots
WHERE plugin IS NOT NULL;

La query restituisce i plugin utilizzati con successo almeno una volta. Non intercetta necessariamente tutte le integrazioni configurate ma non ancora attivate.

Dopo aver aggiornato PostgreSQL, ogni plugin legittimo non compreso nel valore predefinito deve essere aggiunto a output_plugin_libraries. La configurazione può quindi essere ricaricata con:

pg_ctl reload

oppure:

SELECT pg_reload_conf();

La sola modifica del parametro non richiede un riavvio. Restano valide eventuali istruzioni più restrittive della distribuzione, come il riavvio previsto dall’aggiornamento Ubuntu.

PostgreSQL ha preferito una whitelist alla semplice estensione delle regole di LOAD. Quest’ultima soluzione avrebbe obbligato a installare tutti i plugin esterni sotto $libdir/plugins, interrompendo numerose configurazioni esistenti.

Esiste anche un limite operativo ancora aperto. pg_createsubscriber crea slot con pgoutput senza controllare il nuovo parametro: --dry-run può riuscire, mentre l’operazione reale può fallire se la whitelist esclude il plugin. Al 4 settembre, una patch segnalata da Hayato Kuroda di Fujitsu risultava ancora in revisione.

Nelle migrazioni da PostgreSQL 17 o release successive, la whitelist del nuovo cluster deve inoltre essere configurata prima di eseguire:

pg_upgrade --check

In caso contrario, il controllo può fallire quando gli slot esistenti dipendono da plugin non autorizzati.

Controlli immediati, mitigazioni e segnali da cercare

Se la patch non può essere applicata subito, gli amministratori dovrebbero revocare REPLICATION agli account privi di una necessità documentata e restringere in pg_hba.conf gli indirizzi autorizzati alle connessioni di replicazione.

È inoltre opportuno bloccare dai server database il traffico SMB in uscita sulla porta 445 e quello NFS sulla porta 2049, quando non necessari. autofs dovrebbe essere disabilitato sui sistemi che non ne fanno uso.

Dopo l’aggiornamento, i tentativi di caricare plugin esclusi dalla whitelist producono nei log un errore contenente:

may not be used as an output plugin

La presenza del messaggio può indicare una configurazione legittima non ancora adeguata, ma anche un tentativo di caricare una libreria non autorizzata. Va quindi correlata con account, indirizzo sorgente e nome del file richiesto.

L’analisi dovrebbe comprendere anche:

• account dotati dell’attributo REPLICATION;
• slot elencati in pg_replication_slots;
• plugin associati agli slot;
• modifiche inattese al catalogo dei ruoli;
• nuove forme di persistenza create dall’utente operativo del database;
• connessioni SMB o NFS anomale originate dal server PostgreSQL.

La priorità resta installare una release corretta. La whitelist riduce l’esposizione senza imporre una riorganizzazione completa dei plugin, ma richiede un inventario accurato per evitare interruzioni nelle pipeline di replica e change data capture.