Cosa è successo

Il 23 luglio 2026 Redis ha pubblicato in una sola giornata sette release di sicurezza per le sue diverse linee di prodotto. La spinta è arrivata dalla diffusione pubblica di proof-of-concept che ottengono esecuzione di codice (RCE) sull'host a partire da versioni considerate sicure: gli exploit prendevano di mira proprio Redis 6.2.22, 7.4.9, 8.6.4 e 8.8.0, cioè in parte gli aggiornamenti che a maggio erano stati indicati come la correzione da installare.

Le nuove falle riguardano due classi di bug finora non coperte. La prima è nel percorso degli Stream di Redis: un bug di shared ownership in cui un oggetto RDB corrotto può far puntare due consumer allo stesso pending-entry record, così che la rimozione di entrambi liberi due volte lo stesso oggetto (un classico double-free). La seconda è nel caricatore RDB di TDigest dentro il modulo RedisBloom, una scrittura fuori dai limiti (out-of-bounds write). Lo script pubblicato dimostra come trasformare la corruzione di memoria risultante in accesso arbitrario alla memoria e, in ultima analisi, nell'invocazione di system(). Al momento della pubblicazione Redis non ha assegnato né un identificativo CVE né un punteggio CVSS, e al 24 luglio non risultavano sfruttamenti in rete. Va sottolineato che le catene richiedono un utente autenticato con il permesso di eseguire i comandi coinvolti.

Il dettaglio che cambia le regole: gli zero-day li ha trovati un'IA

La parte più significativa di questa vicenda non è la singola falla, ma come è stata scoperta. Secondo i ricercatori, alcuni di questi bug sono stati individuati da agenti di intelligenza artificiale autonomi basati sul modello Kimi K3: in circa 90 minuti gli agenti avrebbero trovato una serie di zero-day in Redis, con un'esecuzione successiva che ha prodotto un exploit funzionante per la 8.8.0 in 27 minuti. Non è un episodio isolato: già a maggio un'altra RCE in Redis (CVE-2026-23479) era stata individuata con l'ausilio di strumenti automatici di analisi.

Il senso è chiaro. La ricerca di vulnerabilità sta diventando automatizzabile e rapidissima, e questo vale per chi difende quanto per chi attacca. La finestra tra la scoperta di una falla e la disponibilità di un exploit funzionante — storicamente misurata in settimane — si sta comprimendo a ore o minuti. È lo stesso fenomeno che avevamo osservato, sul fronte offensivo, con gli attacchi comparsi appena 20 ore dopo un avviso di sicurezza su Langflow.

Perché "richiede autenticazione" non è una scusa per rimandare

La tentazione, leggendo "post-autenticazione", è archiviare la notizia come poco urgente. Sarebbe un errore. Redis nasce per stare dentro reti fidate e moltissime installazioni riflettono ancora questa filosofia: nessuna password, oppure una password debole condivisa, ACL permissivi che lasciano a chiunque comandi potenti come RESTORE, e — troppo spesso — porte esposte oltre il perimetro previsto. In questo scenario "autenticato" significa poco: basta una credenziale trapelata, un'applicazione compromessa che parla con Redis, o un'istanza raggiungibile dalla rete interna perché la corruzione di memoria si traduca in controllo completo dell'host che ospita il servizio.

Cosa significa per le aziende italiane

Redis è ovunque: caching, gestione delle sessioni, code di messaggi, rate limiting. È uno di quei componenti "dietro le quinte" che raramente entrano nel programma di vulnerability management, proprio perché nessuno li considera esposti. È esattamente questa invisibilità il rischio. Molte aziende italiane non hanno un inventario aggiornato delle proprie istanze Redis, comprese quelle avviate rapidamente per un progetto e mai dismesse.

Il messaggio strategico è duplice. Da un lato serve igiene di configurazione: Redis non va mai esposto su Internet e va protetto con autenticazione forte e ACL restrittivi. Dall'altro, l'accelerazione impressa dall'IA alla scoperta delle falle impone di accorciare i tempi di patch e di trattare anche i componenti infrastrutturali "silenziosi" come asset da monitorare. Chi ragiona ancora in finestre di aggiornamento trimestrali si troverà sistematicamente in ritardo.

Cosa fare subito

  • Aggiornare all'ultima release disponibile per ciascuna serie mantenuta di Redis: gli aggiornamenti di maggio non contengono le protezioni introdotte il 23 luglio.
  • Revocare il comando RESTORE (e gli altri comandi non necessari) dagli account che non ne hanno realmente bisogno, tramite le ACL di Redis: la sola restrizione di RESTORE chiude entrambe le catene divulgate.
  • Non esporre Redis su Internet: vincolare il servizio all'interfaccia di loopback o a una rete privata, attivare autenticazione robusta e, dove possibile, TLS.
  • Segmentare la rete in modo che solo i servizi applicativi legittimi possano raggiungere le istanze Redis.
  • Inventariare tutte le istanze, comprese quelle "shadow" avviate per test e mai spente, e verificarne configurazione ed esposizione (uno scan interno e una verifica su Shodan/Censys aiutano).
  • Monitorare l'esecuzione di comandi anomali e i riavvii inattesi del processo redis-server, possibili segnali di tentativi di sfruttamento.