Kimi K3 ha trovato 19 zero-day in Redis in 90 minuti

Redis ha pubblicato il 23 luglio sette versioni correttive che coprono tutti i rami supportati, dal 6.2 all'8.8, per due difetti di corruzione della memoria che il progetto descrive come potenzialmente sfruttabili per l'esecuzione di codice da remoto. Entrambi passano dal comando RESTORE, quello che ricostruisce una chiave a partire da un oggetto serializzato. Nessuna delle due catene funziona senza credenziali valide sull'istanza.

Le versioni da installare sono 6.2.23, 7.2.15 e 7.4.10 per i rami più vecchi, dove viene chiuso il solo difetto negli Stream. Sui rami 8.2, 8.4 e 8.6 servono rispettivamente 8.2.8, 8.4.5 e 8.6.5, che chiudono sia quel difetto sia le scritture fuori dai limiti dell'area allocata nei moduli RedisBloom e TDigest. La 8.8.1 interviene solo sui due moduli, perché la protezione sugli Stream era già presente nella 8.8.0.

Redis 6.2.22 e 7.4.9 erano le versioni indicate a maggio come approdo sicuro dopo il precedente ciclo di correzioni, e figurano fra i quattro bersagli per cui sono stati pubblicati codici dimostrativi funzionanti. Secondo la verifica sul codice condotta da The Hacker News, le note di rilascio della 8.6.4 citavano la modifica che avrebbe dovuto introdurre il controllo di proprietà, mentre il sorgente etichettato con quel numero ne era privo. La guardia compare per la prima volta nella 8.6.5.

Due strade che partono dallo stesso comando

Il primo difetto sta negli Stream: un oggetto RDB manipolato può far puntare due consumatori allo stesso record di voci pendenti, la struttura interna streamNACK. La rimozione del primo consumatore libera l'oggetto e lascia al secondo un puntatore penzolante; rimuovendo anche il secondo, la stessa area viene liberata due volte. Da lì i codici pubblicati trasformano la corruzione in accesso arbitrario alla memoria e alterano una funzione di hash del database, in modo che una normale GET finisca per invocare system().

Il secondo è una scrittura fuori dai limiti nel caricatore RDB della struttura TDigest, dentro RedisBloom. Il caricatore dimensionava gli array dei centroidi a partire dal valore di compressione serializzato, ma poi si fidava di un campo di capacità separato e controllabile dall'attaccante per decidere quanti nodi caricare: allocazione piccola, metadati gonfiati, scrittura oltre il confine. La correzione di luglio impone che la capacità dichiarata coincida con l'allocazione derivata dal valore di compressione, e limita i contatori dei nodi prima che gli array vengano letti. Anche qui la catena pubblicata arriva a costruire primitive di lettura e scrittura, a ricavare gli indirizzi di Redis e della libc e a chiamare system().

Tutte le catene richiedono RESTORE; quelle sugli Stream anche EVAL e XGROUP, quella contro la 8.8.0 anche EVAL e il modulo RedisBloom caricato. Per chi non può aggiornare subito, la mitigazione immediata è togliere RESTORE agli account che non ne hanno stretto bisogno e chiudere l'accesso di rete non fidato. Revocare quel singolo comando taglia entrambi i percorsi divulgati.

Sette rilasci, nessun identificativo nuovo

Le note di rilascio di luglio non assegnano alcun CVE né punteggio CVSS ai due difetti. Il repository che ha pubblicato i codici dimostrativi inquadra il problema degli Stream come parte di una famiglia di correzioni incomplete legata a CVE-2026-25589, ma Redis associa quell'identificativo alla corruzione di memoria in RedisBloom durante RESTORE, mentre il difetto di proprietà condivisa negli Stream resta senza numero proprio.

I due difetti arrivano da Bera Buddies, che si presenta come gruppo di ricerca su agenti IA. Chaofan Shou ha dichiarato su X che agenti basati su Kimi K3 hanno individuato 19 zero-day in Redis in circa novanta minuti, e che una seconda esecuzione ha prodotto l'exploit contro la 8.8.0 in ventisette. Conteggi, tempi e grado di autonomia restano dichiarazioni degli autori: il registro pubblico di Redis conferma i difetti e le correzioni, ma non il numero di zero-day né quanto gli agenti abbiano lavorato senza supervisione. È il secondo episodio in pochi mesi, dopo la falla RCE corretta a maggio e anch'essa attribuita a una scoperta assistita da IA.

Al 24 luglio non risultavano segnalazioni di sfruttamento attivo, né nelle note di rilascio né nei repository dei codici dimostrativi esaminati. L'aggiornamento va fatto sulla versione corretta del proprio ramo, e la verifica riguarda il numero esatto installato: dopo questo ciclo, sapere che Redis è stato aggiornato di recente non è più una garanzia. Chi era rimasto alle release di maggio si trova nell'elenco dei bersagli con codice funzionante già pubblico.