PostGREShell, una falla in PostgreSQL trasforma gli account di replica in un trampolino per eseguire codice

Una vulnerabilità nel sistema di replica logica di PostgreSQL permette a un account dotato dell’attributo REPLICATION di caricare codice arbitrario nel processo del database. Il difetto, identificato come CVE-2026-6471 e chiamato PostGREShell da Cyera, ha ottenuto un punteggio CVSS 7.2.

L’attacco non richiede i privilegi iniziali di superuser PostgreSQL. Serve però un account autorizzato alla replica, una capacità spesso concessa a software di backup, server secondari, pipeline e piattaforme di monitoraggio.

Una volta caricato, il codice malevolo viene eseguito con i diritti dell’account del sistema operativo che gestisce PostgreSQL. Da questa posizione può manipolare anche i meccanismi interni del database, fino ad assegnare privilegi permanenti di superuser.

Al 4 settembre 2026 non risultano disponibili informazioni che consentano di classificare CVE-2026-6471 come vulnerabilità inclusa nel catalogo Known Exploited Vulnerabilities della CISA. Non è quindi nota alcuna scadenza CISA per la correzione.

Il punto debole è nella scelta del plugin di logical decoding

La vulnerabilità interessa il logical decoding, una funzione impiegata dalla replica logica per convertire le modifiche registrate dal database in un flusso interpretabile da applicazioni esterne.

Quando un client apre una sessione di replica logica, crea uno slot e specifica quale plugin di output deve elaborare gli eventi. PostgreSQL deve quindi individuare e caricare la libreria corrispondente.

Il problema è un controllo di autorizzazione mancante, classificato come CWE-862, Missing Authorization. Un utente non-superuser con attributo REPLICATION può indicare un file arbitrario al posto di un normale plugin autorizzato.

Secondo l’analisi tecnica di Cyera, il parser del protocollo accetta nel nome del plugin racchiuso tra virgolette doppie diversi caratteri utili a costruire un percorso:

• slash e backslash;
• punti;
• sequenze di attraversamento delle directory come ../;
• percorsi UNC utilizzati negli ambienti Windows.

Il nome arriva al loader senza una validazione sufficiente. L’attaccante può così passare un percorso completo a dlopen(), anziché limitarsi al nome di una libreria prevista dalla configurazione.

Il payload viene caricato nello stesso spazio di indirizzamento del processo PostgreSQL. Non intervengono sandbox dedicate e il codice può richiamare le API interne del database con i privilegi del processo in esecuzione.

Non basta dunque considerare attendibile un account solo perché non è superuser. In questo scenario, REPLICATION diventa una capacità di esecuzione del codice.

Dall’esecuzione nel processo alla modifica di pg_authid

Il primo impatto riguarda l’account del sistema operativo che esegue PostgreSQL. Una libreria malevola può leggere e modificare ciò che è accessibile a quel processo, oltre a interferire direttamente con il funzionamento del database.

Cyera ha descritto anche un percorso per acquisire i privilegi di superuser PostgreSQL. Il plugin può invocare funzioni interne per operare come bootstrap superuser e modificare direttamente pg_authid, il catalogo che contiene gli attributi sensibili degli account.

Impostando i relativi flag, l’aggressore può trasformare un’identità esistente in un superuser permanente. La compromissione non resta quindi confinata alla sessione di replica utilizzata per avviare l’attacco.

Con questi privilegi diventano possibili diverse operazioni:

• accesso alle tabelle di tutti i database ospitati;
• modifica di configurazioni, ruoli e oggetti;
• lettura di chiavi private raggiungibili dal processo PostgreSQL;
• scrittura di file nei percorsi accessibili all’account operativo;
• esecuzione di comandi sul sistema operativo;
• installazione di meccanismi di persistenza.

La persistenza può comprendere l’abilitazione di accessi senza password, la copia del payload in una posizione stabile e la sua registrazione per il caricamento nei nuovi processi backend. Il codice può inoltre riapplicare le modifiche ai privilegi dopo un tentativo di ripristino.

Questo rende insufficiente la sola revoca del ruolo compromesso. Se una libreria è già stata installata o registrata, occorre verificare anche il sistema operativo e i meccanismi di avvio di PostgreSQL.

Le versioni vulnerabili e le release da installare

La vulnerabilità riguarda PostgreSQL. La descrizione NVD indica come vulnerabili le versioni precedenti alle seguenti release correttive, ciascuna nel proprio ramo:

Ramo PostgreSQL	Prima versione corretta
18	18.6
17	17.11
16	16.15
15	15.19
14	14.24

SecurityWeek colloca il perimetro interessato tra PostgreSQL 9.4 e 18 e riferisce che Cyera ha verificato il problema anche sulla versione 18.2. Si tratta quindi di una debolezza presente in release distribuite a partire dal 2014.

Una riga riepilogativa associata alla scheda CVE riporta la formulazione più ristretta postgresql postgresql < 14.24. Questa indicazione contrasta però con il dettaglio dell’advisory, che elenca esplicitamente correzioni anche per i rami 15, 16, 17 e 18.

Per la gestione operativa devono quindi essere considerate vulnerabili:

• le versioni 18 precedenti alla 18.6;
• le versioni 17 precedenti alla 17.11;
• le versioni 16 precedenti alla 16.15;
• le versioni 15 precedenti alla 15.19;
• le versioni 14 precedenti alla 14.24.

Per i rami dalla 9.4 alla 13 non è indicata una release correttiva specifica. Le organizzazioni che li utilizzano devono tenerne conto nel piano di aggiornamento, evitando di interpretare l’assenza di una patch elencata come assenza della vulnerabilità.

Perché gli account REPLICATION sono il bersaglio principale

Il vettore CVSS è CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H. L’attacco è raggiungibile via rete, presenta complessità bassa e non richiede interazione da parte di un utente.

Il requisito PR:H indica la necessità di privilegi elevati. Nel caso di PostGREShell, tuttavia, non significa che l’aggressore debba essere già amministratore del database: deve controllare un account con attributo REPLICATION.

Queste credenziali possono trovarsi nei sistemi di backup, nei secret delle pipeline, nei server secondari o nelle configurazioni degli strumenti di osservabilità. Un’organizzazione potrebbe quindi averle protette meno rigorosamente rispetto agli account esplicitamente classificati come amministrativi.

Le conseguenze riguardano sia installazioni locali sia database raggiungibili attraverso reti aziendali o infrastrutture cloud. Per sfruttare la falla servono comunque credenziali adeguate e la possibilità di avviare o utilizzare una sessione di logical replication.

Non sono stati pubblicati indicatori di compromissione specifici, come hash, nomi di payload o indirizzi di rete. Non è inoltre noto se la vulnerabilità sia già impiegata in attacchi reali.

Aggiornamento, audit dei ruoli e ricerca dei caricamenti anomali

La misura principale consiste nell’installare PostgreSQL 18.6, 17.11, 16.15, 15.19 o 14.24, in base al ramo utilizzato. Non è stato indicato un workaround ufficiale alternativo alla patch.

Gli amministratori dovrebbero poi censire tutti gli account dotati di REPLICATION e verificare che il privilegio sia giustificato da un’esigenza operativa documentata. Dove non serve, va rimosso.

L’attività di rilevamento può concentrarsi su:

• creazione o utilizzo insolito di slot di replica logica;
• sessioni di replica provenienti da indirizzi o sistemi inattesi;
• nomi di plugin contenenti separatori di percorso, ../ o percorsi UNC;
• caricamento di librerie da directory non previste;
• modifiche anomale ai ruoli e agli attributi conservati in pg_authid;
• variazioni alle regole di autenticazione, comprese connessioni senza password;
• file nuovi o modificati nelle directory accessibili al processo PostgreSQL;
• configurazioni che causano il caricamento persistente di librerie nei nuovi backend.

Se emergono segnali di sfruttamento, la risposta non dovrebbe limitarsi al cambio delle password. Occorre considerare compromessi il database, l’account operativo di PostgreSQL e tutti i segreti leggibili da quel processo.

La rotazione delle credenziali va accompagnata dalla verifica delle librerie caricate, dei file modificati, dei ruoli superuser e delle impostazioni di autenticazione. Solo dopo questa bonifica l’aggiornamento può chiudere il vettore senza lasciare attivi i meccanismi di persistenza già installati.