Un account di backup PostgreSQL può ora eseguire codice sul server. Applica la patch CVE-2026-6471.

Postgres ha rilasciato una correzione il 13 agosto per un bug presente nel codice dal 2014. CVE-2026-6471 consente a qualsiasi account con l'attributo REPLICATION — il tipo di account con privilegi limitati usato dallo strumento di backup o dalla replica in sola lettura — di caricare una libreria condivisa arbitraria nel processo del database ed eseguire codice come l'utente del sistema operativo proprietario di Postgres. Il bollettino ufficiale lo descrive in modo esplicito: la decodifica logica può eseguire dlopen su un file arbitrario, scelto dal client di replica, senza alcun controllo di autorizzazione. Cyera Research, che lo ha segnalato insieme a Yu Kunpeng, lo chiama PostGREShell.

I meccanismi vale la pena capirli, perché spiegano la correzione. Quando un client di replica apre uno slot di decodifica logica, nomina un output plugin e Postgres lo carica come codice compilato nel proprio processo. Per un normale SQL LOAD, Postgres limita gli utenti non superuser a una directory di plugin controllata. Il percorso di replica saltava questo controllo, quindi il nome del plugin poteva essere qualsiasi percorso su disco. Su Windows la situazione è peggiore: il loader accetta un percorso UNC, quindi un attaccante può puntarlo a una DLL sul proprio share SMB senza mai dover depositare un file sul target.

Ecco la parte che si è persa in parte della copertura. Il CVSS ufficiale è 7,2, alto ma non critico, e il motivo è proprio lì nel vettore: PR:H. È necessario un account che già possiede REPLICATION. Non si tratta di una falla non autenticata esposta all'internet aperto. Allora perché preoccuparsi? Perché nei sistemi reali questi account sono ovunque e nessuno li considera pericolosi. Ogni replica in streaming, ogni job di backup, ogni pipeline di change-data-capture, ogni agente di monitoraggio che segue il write-ahead log viene eseguito con un ruolo REPLICATION. Sono l'impianto operativo, e le tubature tendono ad avere credenziali deboli, longeve e ampiamente condivise.

Durante le revisioni di sicurezza cloud troviamo ripetutamente la stessa configurazione: un utente di replica la cui password è presente in tre file env e una variabile Terraform, riutilizzata tra staging e prod, raggiungibile da più parti della rete di quanto chiunque avesse previsto. Da sola sembra un risultato a bassa severità, un account di servizio con troppi privilegi. Questo CVE trasforma esattamente quell'account in esecuzione di codice remoto sull'host del database. La lezione non riguarda davvero Postgres. È che le credenziali di servizio «a basso privilegio» rimangono tali solo finché qualcuno non trova un primitivo che le promuove.

La correzione è un nuovo parametro del server, output_plugin_libraries, aggiunto da Jacob Champion. È una allowlist. Per impostazione predefinita consente solo i due plugin inclusi con Postgres, pgoutput e test_decoding, quindi un client di replica non può più nominare una libreria arbitraria. Se si usa un decoder di terze parti come decoderbufs (utenti Debezium, questo riguarda voi), è necessario aggiungerlo esplicitamente dopo l'aggiornamento altrimenti la replica logica si interrompe. Sulle versioni 17 e successive, pg_upgrade --check rifiuta di procedere se la allowlist del nuovo cluster non include i plugin utilizzati dagli slot esistenti. Questa è una protezione utile e un aspetto da pianificare nella migrazione.

Cosa fare questa settimana

1. Aggiornare a 18.6, 17.11, 16.15, 15.19 o 14.24. I rami più vecchi hanno superato il fine vita e non riceveranno questa correzione, quindi se si utilizza la versione 13 o precedente, considerarlo un ulteriore motivo per migrare.
2. Controllare chi possiede REPLICATION. Farne un inventario reale, non una supposizione. Qualsiasi account umano con l'attributo dovrebbe probabilmente perderlo, e ogni account di servizio che lo mantiene ha bisogno di una secret ruotata e univoca.
3. Bloccare SMB e NFS in uscita dagli host del database. Il percorso DLL remoto su Windows dipende dalla raggiungibilità dello share di file dell'attaccante da parte del database. Il server Postgres non ha motivo di aprire connessioni SMB in uscita, quindi eliminarle al firewall.
4. Se si imposta output_plugin_libraries manualmente, elencare esattamente i decoder utilizzati e nient'altro.

Una cosa da verificare e una da ignorare. La ricerca sulle minacce di Cyera ha trovato 114 plugin Postgres dannosi su VirusTotal: trojan, miner, reverse shell. È un promemoria che il caricamento dei plugin è un obiettivo popolare, ma nessuno di questi campioni è stato collegato allo sfruttamento di questo specifico CVE, quindi non leggerlo come prova di essere stati compromessi. Vale la pena ignorare: l'inquadratura «dodici anni senza patch». La falla era reale per molto tempo, ma sfruttarla richiede comunque un account REPLICATION, e se questi erano stati mantenuti bloccati non si era mai così esposti come il titolo suggerisce.

Trascorriamo molto tempo dove l'hardening dei database incontra la policy di rete, dagli stack PHP e Docker su AWS alle regole Cloudflare e firewall che decidono cosa può raggiungere un host compromesso. Il pattern che coglie le squadre di sorpresa è quasi sempre un account interno troppo fidato unito a un egress che nessuno ha bloccato. Se una credenziale di replica dimenticata con una password condivisa suona come qualcosa presente nella tua infrastruttura, parliamone.