Kimi K3 trova zero-day Redis, NodeBB corregge otto falle scoperte dall’IA

🛡️ Executive Summary

• Due catene basate su RESTORE sfruttano corruzioni della memoria in Redis Streams e RedisBloom per ottenere potenzialmente l’esecuzione remota di codice.
• NodeBB corregge otto vulnerabilità che espongono pannello amministrativo, messaggi privati, categorie riservate, post e funzioni di federazione.
• Redis deve essere aggiornato alla release corretta del proprio ramo; gli amministratori NodeBB devono installare almeno la versione 4.14.2.

Gli agenti di sicurezza basati sull’intelligenza artificiale stanno passando dalla ricerca sperimentale di bug alla scoperta di vulnerabilità sfruttabili nei grandi progetti open source. Ricercatori che utilizzano Kimi K3 hanno pubblicato catene di remote code execution contro diverse versioni di Redis, inducendo il progetto a distribuire sette aggiornamenti di sicurezza. Parallelamente, Aikido ha comunicato di avere trovato in sei ore otto falle ad alta gravità in NodeBB, alcune capaci di esporre messaggi privati, categorie riservate e funzioni amministrative. I risultati mostrano il potenziale dell’automazione, ma impongono cautela: vulnerabilità e patch sono verificabili, mentre autonomia, tempi e numero complessivo delle scoperte restano in parte dichiarazioni dei ricercatori.

Redis corregge due catene di corruzione della memoria

Le vulnerabilità Redis riguardano due percorsi distinti che richiedono un accesso autenticato con il permesso di eseguire il comando RESTORE, utilizzato per caricare nel database oggetti serializzati nel formato RDB. La prima catena colpisce Redis Streams attraverso un errore nella gestione condivisa degli oggetti streamNACK, strutture che rappresentano i messaggi consegnati ma non ancora confermati dai consumatori. Un file RDB appositamente corrotto può indurre due consumer a puntare allo stesso record; la rimozione del primo libera l’oggetto, mentre il secondo conserva un riferimento pendente e può provocare un secondo rilascio della stessa memoria. Il proof of concept trasforma la double-free in primitive di lettura e scrittura arbitrarie, fino a manipolare una funzione hash interna e richiamare system(). La seconda catena interessa invece il loader TDigest di RedisBloom: l’allocazione viene calcolata usando il valore di compressione serializzato, ma il caricamento dei centroidi si affida a un campo capacity separato e controllabile dall’attaccante. Dichiarando una capacità superiore allo spazio realmente allocato, il payload genera una scrittura fuori dai limiti e la converte in esecuzione di codice. Il rischio si inserisce nel quadro delle precedenti vulnerabilità Redis con possibilità di RCE, confermando che i comandi di importazione dei dati devono essere considerati operazioni altamente privilegiate.

Sette release chiudono falle diverse in base al ramo utilizzato

Redis ha pubblicato il 23 luglio 2026 sette release correttive, ma la versione da installare dipende dal ramo in produzione. Redis 6.2.23, 7.2.15 e 7.4.10 correggono il problema di ownership condivisa nei Streams; le versioni 8.2.8, 8.4.5 e 8.6.5 includono sia la protezione Streams sia le correzioni per le scritture fuori limite nei loader RedisBloom e TDigest. Redis 8.8.1 sistema i loader RedisBloom e TDigest, mentre la protezione Streams risultava già presente nella versione 8.8.0. La situazione richiede attenzione perché Redis 6.2.22 e 7.4.9 erano già stati indicati come aggiornamenti di sicurezza nel mese di maggio, ma non contenevano il controllo necessario per impedire la duplicazione della proprietà del streamNACK. Essere “aggiornati di recente” non garantisce quindi la protezione: occorre verificare il numero esatto della release installata. In attesa dell’upgrade, gli amministratori devono revocare RESTORE agli account che non ne hanno una necessità operativa, impedire l’accesso da reti non fidate e limitare anche EVAL, XGROUP e l’uso dei moduli coinvolti. Non risultano al momento attacchi osservati pubblicamente, ma la disponibilità di exploit dimostrativi riduce drasticamente il tempo a disposizione per intervenire.

Kimi K3 avrebbe trovato 19 zero-day in circa novanta minuti

Il gruppo Bera Buddies, che si presenta come laboratorio di ricerca sugli agenti AI, sostiene che sistemi basati su Kimi K3 abbiano individuato 19 vulnerabilità zero-day in Redis in circa novanta minuti e sviluppato in una sessione successiva l’exploit contro Redis 8.8.0 in 27 minuti. Il dato dimostrerebbe una capacità notevole di analisi del codice, costruzione di input corrotti e trasformazione di crash in primitive sfruttabili. Tuttavia, il registro pubblico di Redis conferma l’esistenza delle falle e delle relative correzioni, non il numero complessivo di zero-day dichiarati né il grado di autonomia con cui gli agenti avrebbero completato il lavoro. Non è chiaro quanto abbiano inciso prompt umani, selezione dei target, harness predisposti, debugging manuale e scarto dei risultati non validi. La distinzione è importante perché la scoperta assistita dall’IA non equivale necessariamente a una ricerca completamente autonoma. Il caso dimostra comunque che i modelli possono comprimere attività tradizionalmente molto costose, come lettura di grandi codebase, generazione di casi limite e iterazione sui crash. Dopo che Cursor aveva mostrato come un repository clonato potesse trasformarsi in un vettore di esecuzione, Redis sposta il dibattito sul lato opposto: gli agenti non sono soltanto una nuova superficie da proteggere, ma strumenti capaci di produrre ricerca offensiva a velocità crescente.

NodeBB esponeva messaggi privati, categorie e pannello amministrativo

Aikido ha dichiarato di avere utilizzato agenti di pentest AI per analizzare il codice sorgente di NodeBB, piattaforma open source per forum basata su Node.js, individuando otto vulnerabilità in circa sei ore. Una delle falle permetteva a un normale utente registrato di modificare direttamente la propria homepage impostandola sull’indirizzo del pannello amministrativo: il controllo era applicato soltanto nell’interfaccia browser e poteva essere aggirato inviando la richiesta al backend. L’accesso risultava in gran parte limitato alla lettura, ma poteva esporre log degli errori, elenchi di utenti esportati dagli amministratori e alcune configurazioni del sito.

Due vulnerabilità non richiedevano invece alcun account: una consentiva di impersonare un utente e leggere i suoi messaggi privati uno alla volta, mentre un’altra permetteva di accedere ai contenuti delle categorie riservate. Una falla trasversale nel sistema di templating consentiva inoltre di inserire marcatori interpretati durante la seconda fase di traduzione delle pagine, creando collegamenti capaci di eseguire codice nel browser del visitatore. Gli altri problemi permettevano di appropriarsi di post esistenti, manipolare i voti e sfruttare server federati malevoli per introdurre contenuti attivi. Tutte le versioni precedenti alla 4.14.0 risultano coinvolte in almeno una parte dei problemi, mentre l’aggiornamento raccomandato è NodeBB 4.14.2.

La federazione amplia la superficie ma non spiega tutte le falle

Cinque delle otto vulnerabilità interessano il codice di federazione con il Fediverse, che permette ai forum NodeBB di interagire con servizi come Mastodon. Le nuove installazioni della versione 4 abilitano questa funzione per impostazione predefinita, mentre gli ambienti aggiornati dalla versione 3 la mantengono disattivata salvo intervento dell’amministratore. Disabilitare la federazione riduce quindi una parte della superficie, ma non elimina le tre vulnerabilità estranee a quel componente. Le correzioni sono state distribuite gradualmente: quattro sono arrivate a maggio, due a giugno e il rifacimento più ampio del sistema di rendering è entrato nella versione 4.14.0 del 9 luglio, modificando 325 file. L’aggiornamento può richiedere verifiche su temi e plugin personalizzati, perché il nuovo trattamento dei template modifica il modo in cui testi e traduzioni vengono inseriti nelle pagine. Nessuna delle otto falle possiede al momento un identificatore CVE e non risultano campagne di sfruttamento attivo. Esiste però una vulnerabilità federata separata, CVE-2026-58593, che consente a un server esterno di pubblicare contenuti e inviare messaggi impersonando account locali, compreso quello amministrativo. La sequenza conferma quanto i percorsi secondari siano pericolosi: i controlli di autorizzazione funzionavano sull’interfaccia principale, ma venivano omessi su API, funzioni federate o richieste costruite manualmente.

L’IA accelera la scoperta ma aumenta anche il carico sui maintainer

Redis e NodeBB mostrano un cambiamento strutturale nella sicurezza open source. Gli agenti possono esaminare rapidamente funzioni correlate, generare input anomali, confrontare percorsi di autorizzazione e costruire exploit dimostrativi, aumentando la probabilità di trovare errori che erano rimasti nel codice per anni. Lo stesso vantaggio può però produrre grandi quantità di segnalazioni incomplete, duplicate o non riproducibili, trasferendo sui maintainer il costo della validazione. NodeBB dichiara di non premiare nei propri bug bounty report generati interamente dall’IA, pur correggendo le vulnerabilità valide comunicate direttamente. Il problema non riguarda l’origine del risultato, ma la qualità delle prove: ogni segnalazione deve includere una versione affetta, una catena riproducibile, l’impatto concreto e una verifica della patch. Per le organizzazioni, l’indicazione operativa resta più semplice. Redis deve essere aggiornato alla release corretta del ramo utilizzato e RESTORE va limitato agli account indispensabili; NodeBB deve raggiungere almeno la versione 4.14.2, controllando compatibilità di temi e plugin. L’automazione sta riducendo il tempo necessario per trovare le falle, ma riduce nello stesso modo la finestra tra divulgazione e sfruttamento: la gestione delle patch deve quindi muoversi alla stessa velocità degli agenti che analizzano il codice.