Il 4 settembre 2026 la società di sicurezza dei dati Cyera ha pubblicato i dettagli di CVE-2026-6471, ribattezzata PostGREShell: una falla di autorizzazione mancante nel meccanismo di logical decoding di PostgreSQL che consente a un account con il solo attributo REPLICATION di eseguire codice arbitrario sul server, diventare superuser permanente e installare una backdoor stabile nel database.

Il punteggio CVSS assegnato è 7.2, quindi "alto" ma non critico. È proprio questo numero, come vedremo, la parte più fuorviante della vicenda.

Come funziona

PostgreSQL usa un protocollo di replica dedicato per sincronizzare le repliche di un database primario. Per usarlo serve un account con l'attributo REPLICATION: è l'account che viene consegnato a qualsiasi strumento di backup, a qualsiasi pipeline di change data capture, a qualsiasi sonda di monitoraggio che debba leggere il flusso delle modifiche.

Quando un client crea uno slot di replica logica, indica il nome di un output plugin che PostgreSQL carica per formattare il flusso di eventi. Per evitare abusi, i non-superuser dovrebbero poter caricare plugin solo da una directory controllata dall'amministratore.

Cyera ha scoperto che il nome del plugin viene passato direttamente al loader, senza validazione né sanitizzazione, e finisce dentro dlopen(), la funzione C usata per caricare librerie condivise. Il parser del protocollo di replica accetta praticamente qualsiasi carattere all'interno di un nome di plugin fra virgolette doppie: barre, barre rovesciate, punti, sequenze ../ di path traversal e persino percorsi UNC di Windows.

Il risultato è che l'attaccante può far caricare al server qualunque file, che viene eseguito con i privilegi dell'utente di sistema postgres. Il codice caricato via dlopen() gira nello stesso spazio di indirizzamento di PostgreSQL, senza sandbox e senza controlli sulle chiamate alle API interne: il server si fida di qualsiasi codice sia stato caricato.

Da lì la catena si chiude in fretta. Il plugin malevolo invoca una funzione interna per diventare bootstrap superuser nella sessione, poi scrive direttamente su pg_authid — la tabella di catalogo che definisce chi è superuser — e mette a true tutti i flag di privilegio. A quel punto l'attaccante legge ogni tabella di ogni database, esegue comandi di sistema operativo, legge chiavi private e scrive file ovunque il processo postgres possa scrivere. Cyera documenta anche i meccanismi di persistenza: abilitazione delle connessioni senza password, copia del plugin in una posizione stabile, registrazione per il ricaricamento in ogni nuovo backend e riapplicazione automatica del flag di superuser anche se qualcuno lo revoca.

Sono interessate tutte le versioni dalla 9.4 alla 18, cioè ogni release pubblicata dal 2014 in poi. Le correzioni sono nelle versioni 18.6, 17.11, 16.15, 15.19 e 14.24.

Perché quel 7.2 è ingannevole

Il punteggio è contenuto perché l'attacco richiede un account autenticato con l'attributo REPLICATION. Formalmente è corretto: non è una RCE non autenticata. Nella pratica quotidiana, però, l'attributo REPLICATION è esattamente il privilegio che nessuno guarda.

Nelle access review aziendali si cerca chi è amministratore. Si guarda rolsuper, si guarda l'appartenenza ai gruppi, si guarda chi ha i permessi di scrittura sulle tabelle sensibili. L'attributo REPLICATION non compare quasi mai in quelle liste, perché non è percepito come un privilegio amministrativo: è "l'utenza del backup", una credenziale tecnica creata una volta durante l'installazione, scritta nel file di configurazione dello strumento di backup, e da lì mai più toccata. Non viene ruotata, spesso non è nominativa, quasi mai è vincolata a un indirizzo IP specifico in pg_hba.conf.

C'è un secondo dettaglio operativo che merita attenzione, e che cambia molto la valutazione del rischio. Per sfruttare la falla l'attaccante deve poter indicare un file caricabile raggiungibile dall'account di sistema che esegue il server. Su Linux questo significa di norma incatenare la credenziale di replica a una primitiva di scrittura su disco: una directory di upload dell'applicazione che gira sullo stesso host, una condivisione montata, un COPY TO verso un percorso scrivibile. Su Windows, invece, l'accettazione dei percorsi UNC toglie di mezzo questo passaggio: il file può stare su una condivisione remota controllata dall'attaccante, e non serve alcuna scrittura preventiva sul server. Chi ha PostgreSQL su Windows — configurazione tutt'altro che rara nelle installazioni di gestionali italiani — ha una superficie di attacco sensibilmente più semplice da percorrere.

Cosa significa per le aziende italiane

PostgreSQL è diventato negli ultimi anni il database predefinito di buona parte del software gestionale, dei portali della pubblica amministrazione, dei geoportali, delle piattaforme di e-learning e degli applicativi verticali distribuiti dalle software house italiane. È il motore che sta sotto ad applicazioni che l'utente finale non associa mai a "un database": è invisibile, e proprio per questo è raramente inventariato come asset a sé stante.

Da consulente, il problema che mi aspetto di trovare nella maggior parte delle realtà non è la patch: è che nessuno sa quante istanze PostgreSQL ha in casa e quali di queste hanno la replica logica attiva. La replica logica non è più una configurazione esotica da grande banca: è diventata infrastruttura ordinaria, usata da strumenti di backup, da connettori verso data warehouse, da integrazioni CRM e da sincronizzazioni cloud installate dal fornitore applicativo senza che il cliente ne conosca i dettagli. Il percorso vulnerabile esiste quasi ovunque giri PostgreSQL.

C'è poi il tema dei servizi gestiti. Chi usa PostgreSQL come servizio su un cloud pubblico dipende dalla finestra di manutenzione del fornitore per la minor version, e non può applicare la patch autonomamente: l'unica azione possibile è verificare la versione effettiva e sollecitare l'aggiornamento. Va detto che su questi servizi il profilo di rischio è diverso, perché l'attaccante ha molta meno libertà nel piazzare un file caricabile sul filesystem del server. Il rischio si concentra dunque sulle istanze auto-gestite: le macchine virtuali su hosting nazionali, i server on-premise nei CED aziendali, i container in cui il database convive con l'applicazione.

Il contesto normativo

Per i soggetti in perimetro NIS2, l'articolo 21 del recepimento italiano (D.lgs. 138/2024) richiede misure di gestione del rischio che includono esplicitamente la gestione delle vulnerabilità e il controllo degli accessi. Un privilegio che consente l'escalation a superuser di un database, assegnato a utenze tecniche mai riesaminate, è precisamente il tipo di carenza che un'ispezione contesta: non perché la patch non sia stata applicata in ventiquattr'ore, ma perché manca il processo che avrebbe permesso di sapere dove intervenire.

Sul fronte GDPR, un superuser su un database che contiene dati personali significa perdita di riservatezza e di integrità sull'intero contenuto. Se lo sfruttamento viene accertato, si apre l'articolo 33 con le 72 ore per la notifica al Garante, e la ricostruzione dell'accaduto è complicata dal fatto che il codice caricato via dlopen() gira dentro il processo del database: i log applicativi non lo vedono.

Per gli operatori finanziari soggetti a DORA, la falla ricade nella gestione delle vulnerabilità e nel controllo dei fornitori ICT: se il database è amministrato da un terzo, la verifica della versione e dell'inventario degli account di replica va richiesta contrattualmente, non presunta.

Cosa fare subito

  • Verificare la versione di ogni istanza (SELECT version();) e aggiornare almeno a 18.6, 17.11, 16.15, 15.19 o 14.24. Le versioni 9.4-13 non sono più supportate: vanno migrate, non "monitorate".
  • Inventariare gli account di replica: SELECT rolname FROM pg_roles WHERE rolreplication;. Per ciascuno stabilire chi lo usa, quale strumento lo ha configurato e se serve davvero.
  • Rimuovere l'attributo REPLICATION da ogni utenza che non lo richiede, a partire dalle utenze applicative e di monitoraggio a cui è stato dato "per comodità".
  • Restringere le connessioni di replica in pg_hba.conf a indirizzi IP specifici, imponendo scram-sha-256 o l'autenticazione a certificato. La replica non deve essere raggiungibile dalla rete utenti.
  • Controllare gli slot esistenti: SELECT slot_name, plugin, active FROM pg_replication_slots;. Un valore anomalo nella colonna plugin, in particolare uno che contenga barre, punti o percorsi, è un indicatore di compromissione da approfondire subito.
  • Verificare pg_authid alla ricerca di ruoli con rolsuper a true che non dovrebbero averlo, e attivare un allarme sulle modifiche a questa tabella.
  • Cercare file .so o .dll inattesi nella directory dei dati e nelle directory dei plugin, confrontandoli con un'installazione pulita della stessa versione.
  • Per i database gestiti da terzi o in cloud: chiedere formalmente la minor version in esercizio e la data di applicazione della patch, e conservare la risposta.