Il CSIRT ha segnalato il 3 novembre correzioni per alcune vulnerabilità di PostgreSQL psqlODBC, sei delle quali classificate con gravità alta. Le versioni precedenti alla 18.00.0006 risultano interessate. Il richiamo riguarda il driver utilizzato dalle applicazioni per collegarsi al database, una distinzione che cambia il punto in cui cercare e applicare l’aggiornamento.
L’avviso italiano AL06/261103/CSIRT-ITA riporta possibili modifiche ai dati ed esecuzione di codice, in determinati scenari anche senza autenticazione. I singoli difetti hanno però condizioni differenti.
Le schede della banca dati pubblicate il 2 novembre, affiancate dagli advisory dei manutentori del 3 novembre aiutano a evitare una lettura indistinta dell’allerta, come se ogni applicazione collegata a PostgreSQL presentasse automaticamente lo stesso rischio.
Un primo caso, CVE-2026-120064, coinvolge funzioni che ricevono dall’applicazione numeri di colonne o indici di righe. La documentazione segnala controlli insufficienti prima dell’impiego di quei valori come indici di array. Se l’applicazione inoltra valori non affidabili, il processo che usa il driver può essere esposto a letture o scritture fuori dai limiti previsti.
La descrizione cita più punti d’ingresso e non soltanto una singola interrogazione. Tra questi figurano SQLBindCol, SQLColAttribute e SQLSetPos. Per chi gestisce software aziendale, il passaggio utile è verificare quali applicazioni caricano psqlODBC e con quale versione: il driver può trovarsi sul sistema che esegue l’applicazione, separatamente dal server del database.
Un altro difetto, CVE-2026-120062, riguarda SQLSpecialColumns. Secondo l’advisory, la funzione inserisce nomi di tabella e schema in una query senza la protezione applicata da altre funzioni di catalogo. Un’applicazione che trasferisce nomi non affidabili a quella funzione può permettere l’esecuzione di istruzioni SQL con i privilegi della connessione utilizzata.
Per questo secondo difetto, l’advisory dei manutentori precisa l’intervallo interessato: dalla 17.00.0006 alla 18.00.0005. Le versioni precedenti gestivano già diversamente i nomi. Questa delimitazione è più precisa del riepilogo generale e riguarda quella specifica vulnerabilità, non l’insieme di tutti i problemi corretti nel driver.
Le due descrizioni condividono una versione corretta, ma mostrano percorsi diversi: gestione della memoria in un caso, costruzione della query nell’altro. È per questo che la sola verifica delle password o dei permessi del database non sostituisce il controllo della libreria installata. Le condizioni richiedono di esaminare anche come il software tratta gli input.
Per le organizzazioni italiane che acquistano gestionali da terzi, il chiarimento da ottenere dal fornitore riguarda il pacchetto realmente distribuito. Una dichiarazione generica di compatibilità con PostgreSQL non identifica la revisione del driver. Servono versione di psqlODBC, applicazioni che lo utilizzano e indicazione del pacchetto correttivo previsto per quelle installazioni specifiche.
La banca dati GitHub presenta alcune schede come non ancora revisionate e può mostrare campi riepilogativi delle versioni non compilati. La descrizione tecnica e l’avviso italiano indicano comunque esplicitamente la soglia 18.00.0006. Non bisogna interpretare un campo vuoto del riepilogo come prova che una correzione non esista o che qualsiasi versione sia equivalente.
Il bollettino non annuncia una sottrazione di dati presso un soggetto italiano identificato. Rende disponibili riferimenti per una manutenzione mirata: individuare i sistemi che impiegano il driver, confrontarne la revisione e applicare l’aggiornamento documentato. L’eventuale verifica di un incidente richiede evidenze separate rispetto alla semplice presenza di una versione vulnerabile.