PostgreSQL corregge una falla vecchia di 12 anni, AWS patcha cinque vulnerabilità

🛡️ Executive Summary

• PostgreSQL corregge CVE-2026-6471, falla presente dal 2014 che permette a un ruolo REPLICATION di caricare librerie arbitrarie ed eseguire codice sul server.
• AWS chiude due nuovi problemi nei server MCP per PostgreSQL e DynamoDB, capaci rispettivamente di superare il read-only e generare codice malevolo.
• Altri tre advisory riguardano Amazon EFS CSI Driver, ion-java e il vecchio hotpatch Log4j, con rischi di cancellazione dati, DoS e root locale.

Una vulnerabilità rimasta nel logical decoding di PostgreSQL per circa dodici anni e cinque nuovi bollettini AWS concentrano un ciclo di patch particolarmente rilevante per database, Kubernetes e infrastrutture AI. CVE-2026-6471 consente a un utente non superuser ma dotato del privilegio REPLICATION di far caricare a PostgreSQL un file arbitrario come plugin di decoding e ottenere così esecuzione di codice con l’account del server. AWS interviene invece su postgres-mcp-server, DynamoDB MCP Server, Amazon EFS CSI Driver, ion-java e log4j-cve-2021-44228-hotpatch. Nessuno dei bollettini AWS descrive sfruttamento attivo, ma più casi mostrano ancora una volta quanto modalità “read-only”, generatori di codice e componenti infrastrutturali debbano essere considerati veri confini di sicurezza.

PostgreSQL CVE-2026-6471 permette a REPLICATION di caricare codice arbitrario

La falla più importante è CVE-2026-6471 nel logical decoding di PostgreSQL, valutata CVSS 7,2. Il problema deriva da un controllo di autorizzazione mancante nella scelta dell’output plugin utilizzato dal logical decoding. Un utente che non possiede privilegi da superuser ma dispone dell’attributo REPLICATION può indicare come plugin un file visibile all’account del sistema operativo che esegue PostgreSQL. Il server tenta quindi di caricarlo tramite dlopen(): se il file è una libreria controllata dall’attaccante, il risultato è esecuzione di codice con i privilegi dell’account PostgreSQL sul sistema operativo. La debolezza è stata introdotta con l’infrastruttura del logical decoding risalente a PostgreSQL 9.4, nel 2014, ma è stata corretta soltanto nelle release 18.6, 17.11, 16.15, 15.19 e 14.24 pubblicate il 13 agosto. Non è quindi una RCE senza autenticazione: l’attaccante deve già possedere un account database con REPLICATION, privilegio elevato che proprio per questo dovrebbe essere assegnato a pochissimi ruoli. Il caso si aggiunge alle precedenti vulnerabilità PostgreSQL e Aurora che hanno mostrato quanto ruoli apparentemente circoscritti possano diventare vettori di escalation.

Leggi anche: CISA, AWS, MLflow e Copilot: nuove falle tra exploit, DoS e furto dati

La correzione restringe i plugin che il processo di replica può caricare

PostgreSQL ha reagito introducendo un controllo esplicito sui plugin utilizzabili dalle connessioni di replica. La documentazione aggiornata prevede ora il parametro output_plugin_libraries, che definisce la lista delle librerie consentite per il logical decoding; per le subscription native viene utilizzato pgoutput. L’effetto è importante perché il confine non dipende più esclusivamente dal privilegio REPLICATION: anche un ruolo autorizzato alla replica non può caricare liberamente qualunque libreria visibile al processo del database. Il problema era particolarmente delicato negli ambienti nei quali REPLICATION veniva assegnato a operatori, servizi o account tecnici senza considerarli equivalenti a un accesso potenzialmente capace di raggiungere il sistema operativo. PostgreSQL 14 è inoltre prossimo alla fine del supporto, prevista per il 12 novembre 2026, quindi chi utilizza ancora quella major deve non soltanto installare almeno la 14.24 ma pianificare la migrazione a una versione successiva.

postgres-mcp-server supera il read-only con SQL costruito dentro contenuti affidati all’agente

Il bollettino AWS 2026-101 riguarda CVE-2026-85787 in awslabs postgres-mcp-server prima della versione 1.1.7. Il server MCP include una validazione SQL destinata a impedire operazioni incompatibili con la modalità di sola lettura, ma l’elenco degli input vietati risultava incompleto. Secondo AWS, un attore non autenticato capace di inserire SQL appositamente costruito nel contenuto successivamente elaborato da un utente autenticato attraverso il server MCP può riuscire a modificare dati oltre il perimetro read-only previsto. È un dettaglio decisivo: non si tratta di un endpoint PostgreSQL esposto direttamente a Internet, ma del tipico problema agentico nel quale input non affidabile raggiunge un tool dotato di privilegi reali. AWS raccomanda l’aggiornamento alla 1.1.7 e soprattutto l’uso di un ruolo PostgreSQL dedicato con privilegi minimi, evitando superuser, rds_superuser e master user. Per una configurazione realmente read-only, il database deve concedere solo CONNECT, USAGE e SELECT e forzare transazioni di sola lettura. Il principio era già emerso nelle falle dei server MCP AWS che permettevano di superare modalità read-only o scrivere fuori dai percorsi autorizzati: la policy applicativa non può sostituire il controllo imposto direttamente dal database.

DynamoDB MCP genera codice CDK malevolo attraverso nomi manipolati

CVE-2026-85654, descritta nel bollettino AWS 2026-097, interessa invece awslabs.dynamodb-mcp-server dalla 2.0.10 alla 2.1.5. Il problema risiede nel generatore CDK e nella mancata neutralizzazione di caratteri speciali all’interno del template. In determinate condizioni un attore capace di controllare nomi di tabelle, indici o attributi contenuti nel file dynamodb_data_model.json può far generare codice che, una volta distribuita l’applicazione, esegue istruzioni arbitrarie sull’host. La patch è nella 2.1.6. Chi non può aggiornare immediatamente deve esaminare manualmente il modello dati prima di lanciare il generatore ed evitare file provenienti da fonti non affidabili. La vulnerabilità mostra un altro rischio specifico degli agenti di coding: un dato apparentemente descrittivo può attraversare il modello, entrare in un generatore di infrastruttura e trasformarsi in codice eseguito realmente durante il deployment. È la stessa classe di confine fragile evidenziata dal tool poisoning MCP e dall’esfiltrazione tramite agenti AI analizzati da Microsoft.

Amazon EFS CSI può cancellare directory di filesystem non autorizzati

Il bollettino AWS 2026-099 riguarda CVE-2026-85781 nell’Amazon EFS CSI Driver fino alla versione 3.4.0. La falla si manifesta soltanto quando il controller utilizza l’opzione non predefinita --delete-access-point-root-dir=true. Durante la cancellazione di un volume, il driver non verificava che l’access point EFS indicato nel volumeHandle appartenesse realmente al filesystem indicato nello stesso riferimento. Un utente Kubernetes autenticato e autorizzato a creare PersistentVolume poteva quindi costruire un handle manipolato e indurre il controller a cancellare ricorsivamente directory appartenenti a un EFS che l’utente non avrebbe avuto il diritto di modificare. AWS sottolinea che Amazon EFS non è vulnerabile: i controlli del servizio funzionano come previsto, mentre il problema è nel CSI Driver. La correzione è disponibile nella 3.4.1; in alternativa AWS consiglia di disabilitare l’opzione, restringere l’RBAC per la creazione dei PersistentVolume e limitare il ruolo IAM del controller ai filesystem strettamente necessari. La vulnerabilità conferma quanto i controller Kubernetes e i componenti cloud con privilegi trasversali possano trasformare un errore di validazione in accesso a risorse appartenenti ad altri workload.

ion-java 1.12.0 non aveva corretto completamente il DoS precedente

CVE-2026-85786, descritta nel bollettino AWS 2026-100, è particolarmente interessante perché rappresenta una correzione incompleta di CVE-2026-75936. La libreria ion-java, implementazione Java del formato Amazon Ion, era vulnerabile a una memory-amplification denial of service provocata dall’espansione di dati altamente compressi. La versione 1.12.0 aveva introdotto la possibilità di disabilitare la decompressione automatica GZIP, ma il meccanismo non chiudeva completamente il problema. Tutte le release precedenti alla 1.12.1 restano quindi vulnerabili e AWS non fornisce workaround alternativi. È significativo perché la prima coppia di falle ion-java era stata già analizzata il mese scorso: CVE-2026-75935 e CVE-2026-75936 potevano amplificare la memoria attraverso lunghezze dichiarate e decompressione GZIP. Chi aveva considerato la 1.12.0 come baseline sicura deve quindi aggiornare nuovamente.

Il vecchio hotpatch Log4Shell può diventare una privilege escalation root

L’ultimo caso chiude simbolicamente un cerchio iniziato nel 2021. Il bollettino AWS 2026-098 corregge CVE-2026-85656 in log4j-cve-2021-44228-hotpatch, lo strumento AWS creato durante l’emergenza Log4Shell per iniettare un Java agent nelle JVM già in esecuzione e neutralizzare JndiLookup senza riavviare il processo. Nelle versioni Amazon Linux fino alla 1.3-8.amzn2, un utente locale può sfruttare un processo Java il cui percorso dell’eseguibile contiene newline appositamente inserite e provocare una OS command injection con privilegi root. La release corretta è 1.3-9.amzn2, installabile anche tramite yum update --advisory ALAS2-2026-3784. Non è quindi il ritorno di Log4Shell né una RCE remota nel framework Log4j: è una vulnerabilità nel tool privilegiato creato per mitigarla. Il fatto che uno strumento d’emergenza del 2021 richieda ancora manutenzione nel 2026 mostra la lunga coda di rischio prodotta dalle contromisure introdotte sotto pressione.

Continua con:

• AWS corregge root su FPGA Developer Kit e command injection in CodeCatalyst
• WordPress, Fortinet, AWS e OpenSSL colpiti da nuove vulnerabilità critiche

Database, agenti e controller mostrano lo stesso errore: fidarsi troppo del contesto

Le sei vulnerabilità hanno vettori differenti e non devono essere confuse in un’unica scala di urgenza. CVE-2026-6471 richiede un ruolo PostgreSQL con REPLICATION; EFS CSI necessita di un’opzione non predefinita e privilegi Kubernetes per creare PersistentVolume; la falla Log4j hotpatch richiede accesso locale; ion-java produce un denial of service; i due problemi MCP dipendono invece dalla possibilità di far arrivare input costruiti dentro workflow gestiti da un utente o da un agente. Il denominatore comune è però netto: un componente privilegiato attribuisce troppo valore di fiducia a un input che proviene da un livello meno affidabile. Le baseline minime sono PostgreSQL 18.6/17.11/16.15/15.19/14.24, postgres-mcp-server 1.1.7, DynamoDB MCP Server 2.1.6, EFS CSI Driver 3.4.1, ion-java 1.12.1 e log4j hotpatch 1.3-9.amzn2. In assenza di indicazioni di sfruttamento attivo da parte dei vendor, la risposta corretta non è l’allarmismo, ma patching rapido e riduzione preventiva dei privilegi: quando database, agenti e controller lavorano con autorizzazioni elevate, la sicurezza deve essere imposta nel punto finale di esecuzione e non affidata soltanto alla bontà del contenuto che arriva dall’alto.