Benvenuto su Hackerpunk — Hacking News Live 24h, la fonte in tempo reale per tutte le news di cybersecurity, cybercrime e Deep AI. Aggiorniamo costantemente le nostre notizie 24 ore su 24 con report tecnici, indagini digitali e analisi sugli attacchi più recenti.
PostgreSQL corregge 52 vulnerabilità, tra cui un bug risalente a 22 anni fa che consente l’esecuzione di codice da remoto (RCE) con autenticazione Swati Khandelwal 13 novembre 2026 Vulnerabilità / Sicurezza dei database Una vulnerabilità di tipo confusion in PostgreSQL consente a un utente del database in grado di creare oggetti di eseguire codice sul server. Gli aggiornamenti rilasciati ieri risolvono questo problema, insieme ad altri 51 difetti di sicurezza.
La protezione completa da questo difetto richiede anche la ricostruzione di tutte le estensioni in linguaggio C installate sul server.
La vulnerabilità, identificata come CVE-2026-6460, ha un punteggio CVSS di 8,8. Qualsiasi codice eseguito in questo modo dispone dei diritti dell’utente del sistema operativo che esegue PostgreSQL. Sono interessate tutte le versioni precedenti a 18. 7, 17. 12, 16. 16, 15. 20 e 14. 25. Il PostgreSQL Global Development Group, che pubblica le versioni del database, non ha segnalato alcun attacco che abbia sfruttato la vulnerabilità.
Anche la valutazione della CISA nel record CVE indica che non si sono verificati casi di sfruttamento della vulnerabilità.
. Il difetto riguarda i tipi compositi, ovvero tipi costituiti da campi denominati, ciascuno con il proprio tipo di dati. Il tipo di un campo può essere modificato mentre i valori precedenti di quel tipo sono ancora conservati in altre parti del server. Il server potrebbe quindi leggere un vecchio valore come se avesse il nuovo tipo. La correzione, descritta nelle note di rilascio del progetto, aggiunge controlli di versione in modo che il server possa rilevare un valore che non corrisponde più al suo tipo.
Il ricercatore di sicurezza Mehmet Ince ha descritto un exploit funzionante per la vulnerabilità, dimostrato su PostgreSQL 18. 6, in un articolo tecnico pubblicato questa settimana. Il suo metodo consiste nel preparare una query che contiene un valore, modificare il tipo di uno dei campi del valore e quindi eseguire la query. Il documento include l’SQL che fa crashare un server non aggiornato in questo modo e una seconda fase che divulga gli indirizzi di memoria.
Non include l’SQL per il passaggio finale, che fa eseguire al server un comando
. Ha scritto di poter «innescare questo crash con un ruolo di accesso con i privilegi più bassi». L’avviso di sicurezza del progetto descrive l’autore dell’attacco solo come una persona in grado di creare oggetti, senza specificare quali privilegi ciò comporti. Red Hat, che distribuisce i pacchetti PostgreSQL, afferma nella sua valutazione CVE che un utente malintenzionato necessita di un accesso al database con la possibilità di creare o modificare oggetti.
Nessuna di queste fonti specifica se un account con soli privilegi predefiniti possa superare il crash per eseguire il codice. Ince fa risalire l’origine della falla al 5 maggio 2004, quando PostgreSQL ha acquisito la possibilità di modificare il tipo di una colonna. La sua tecnica per eseguire il codice si basa su una modifica successiva apportata il 14 maggio 2015.
Inoltre, ha adattato l’exploit per i servizi PostgreSQL gestiti e ha condiviso privatamente le proof of concept con i loro team di sicurezza nel mese di agosto.
. I provider con cui ha lavorato includono AWS (Aurora e RDS), Microsoft (Azure PostgreSQL), Google (AlloyDB), Supabase, Databricks e Ubicloud. Il resoconto non indica lo stato attuale delle patch di ciascun servizio. Il progetto riconosce il merito a più di una dozzina di segnalatori per CVE-2026-6460, incluso il ricercatore, e gli attribuisce il merito per altre cinque vulnerabilità nella stessa versione. Il progetto assegna a 32 dei 52 difetti un punteggio di 8,8, il più alto della release.
In base ai punteggi nel suo indice di vulnerabilità, solo un difetto nel server non richiede né un login né alcuna azione da parte dell’utente. Tale vulnerabilità, CVE-2026-116322, consente a un client non autenticato di attivare il riavvio dei server PostgreSQL 18. Diverse altre correzioni riguardano gli strumenti client. Un archivio appositamente creato può far sì che pg_restore esegua il codice con i privilegi dell’utente che lo esegue.
Un server di origine compromesso può far sì che psql esegua il codice tramite lo script di ripristino nell’output tar di pg_dump.
