AI autonoma trova RCE in Redis: CVE-2026-23479
Xint Code, tool AI autonomo, ha scoperto CVE-2026-23479, RCE use-after-free in Redis persistita per oltre due anni. Patch disponibili, nessuna evidenza exploit.
Contenuto

Il 3 giugno 2026 la comunità della sicurezza registra un passaggio di testimone. CVE-2026-23479, vulnerabilità use-after-free nel codice di sblocco client di Redis, è stata identificata da Xint Code, tool AI autonomo sviluppato da Team Xint Code/Theori. Il bug ha attraversato oltre due anni di revisioni umane — dalla versione 7.2.0 del gennaio 2023 fino alle patch del 5 maggio 2026 — e permette esecuzione di codice remota su istanze con autenticazione valida. La dimostrazione di exploit funzionante è avvenuta a ZeroDay.Cloud 2025 a Londra nel dicembre 2025.
- Xint Code, descritto dalla sua casa di sviluppo come "autonomous AI security tool built to hunt bugs in large codebases", ha individuato autonomamente una vulnerabilità use-after-free in Redis persistita per oltre due anni senza essere rilevata da audit umani.
- Il bug risiede in
unblockClientOnKey()insrc/blocked.c: la funzione ignora il return value diprocessCommandAndResetClient(), che può liberare il client come side effect, proseguendo poi con un puntatore invalido. - La catena di exploit richiede privilegi @admin, @scripting, @stream, @read/@write — tutti posseduti dall'utente default di Redis, rendendo critiche le distribuzioni senza password o con credenziali condivise.
- Le patch coprono le serie 7.2.14, 7.4.9, 8.2.6, 8.4.3, 8.6.3; Redis Cloud è stato aggiornato automaticamente; secondo il vendor non emergono evidenze di exploit in-the-wild.
Il meccanismo: perché il codice umano ha fallito per 26 mesi
La vulnerabilità ha origine in due commit distinti. La prima, PR #11012 del gennaio 2023, introduce in unblockClientOnKey() una chiamata a processCommandAndResetClient() senza verificarne il valore di ritorno. La seconda, PR #11568 del marzo 2023, aggiunge ulteriore accesso alla struttura client dopo quella stessa chiamata. Il problema è documentato persino nel commento di intestazione della funzione chiamata, che avverte esplicitamente della possibilità di liberazione del client.
Questa configurazione crea una condizione use-after-free precisa: quando un evento su key risveglia un comando bloccato, il flusso di sblocco procede con un puntatore a memoria già restituita al gestore heap. La stabilità dell'exploit è raggiunta attraverso una catena in tre stadi. Il primo stadio ottiene un leak del puntatore heap via Lua EVAL. Il secondo prepara il terreno con tecniche di grooming memoria per costruire una struttura client fittizia. Il terzo stadio sfrutta un decremento out-of-bounds in updateClientMemoryUsage() per sovrascrivere la Global Offset Table.
L'immagine Docker ufficiale Redis presenta RELRO parziale, non full RELRO. Questa scelta di build consente la scrittura della GOT a runtime, facilitando la redirezione di strcasecmp() verso system(). ASLR e PIE sono presenti ma risultano aggirabili a causa della stabilità degli offset globali nella configurazione containerizzata.
"The flaw lives in unblockClientOnKey() in src/blocked.c, which fires when a key event wakes a blocked command. The function dispatches the queued command through processCommandAndResetClient(), then keeps using the same client pointer. The problem: that function can free the client as a side effect, and its own header comment says so." — The Hacker News, analisi tecnica
Le metriche di rischio: divergenza tra NVD e vendor
NVD assegna a CVE-2026-23479 un punteggio CVSS 3.1 di 8.8, classificazione HIGH, con vettore CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. Redis attribuisce invece un CVSS 4.0 di 7.7, con vettore CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. La discrepanza riflette diverse valutazioni sulla complessità dell'attacco: il modello 4.0 del vendor integra la sofisticazione della catena exploit, mentre il punteggio 3.1 dell'NVD enfatizza la rete come vettore e l'impatto completo su confidenzialità, integrità e disponibilità.
La vulnerabilità è una di cinque flaw di classe RCE divulgate da Redis nel maggio 2026, un volume insolito che solleva interrogativi sulla maturità dei processi di review nel progetto open source.
Xint Code: cosa sappiamo e cosa rimane opaco
Xint Code è posizionato da Theori come strumento autonomo di ricerca vulnerabilità su codebase di grandi dimensioni. Il tool ha identificato CVE-2026-23479 e ne ha prodotto una dimostrazione di exploit funzionante presentata a ZeroDay.Cloud 2025. Il dossier non specifica il grado effettivo di autonomia — se il sistema ha isolato il bug senza intervento umano o se i ricercatori hanno guidato il processo di triage e refinement.
Mancano dettagli sull'architettura, sul training e sulla copertura del tool. Non è nota la data esatta di scoperta, precedente al dicembre 2025, né la tempistica di comunicazione al vendor. Questi limiti rendono prematura una valutazione definitiva sulla replicabilità del risultato in contesti di codebases diverse da Redis.
Cosa fare adesso
Le azioni seguenti sono quelle documentate dalle fonti primarie e dal vendor:
- Patchare immediatamente le istanze self-managed alle versioni 7.2.14, 7.4.9, 8.2.6, 8.4.3 o 8.6.3 per l'osservabilità open source; per le distribuzioni commerciali Redis Software le versioni corrette includono 8.0.10-64, 7.22.2-79, 7.8.6-253, 7.4.6-279, 7.2.4-153.
- Verificare che le istanze Redis Cloud siano state aggiornate automaticamente dal provider; il vendor conferma il completamento dell'operazione senza azione richiesta agli utenti.
- Valutare la presenza di utenti default senza password o con credenziali condivise, configurazione che espande la superficie di attacco a causa dell'assegnazione completa dei privilegi @admin, @scripting, @stream, @read/@write all'account predefinito.
- Rimuovere l'esposizione diretta su internet delle istanze self-managed che non necessitano di accesso remoto, dato che il vettore di attacco è di rete e l'autenticazione — quando presente — spesso risulta banale.
Perché questo segnale è più forte del singolo bug
La persistenza di oltre due anni di questo use-after-free — in un progetto con audit regolari e una comunità attiva — misura il limite della revisione umano-oculata su codebase che superano le centinaia di migliaia di linee. La scoperta da parte di Xint Code non aggiunge semplicemente un CVE a un database: dimostra che tool di analisi automatica possono attraversare il rumore dei falsi positivi e produrre risultati tecnicamente validi su bug che richiedono comprensione di side effect non locali.
Per il settore della sicurezza, l'implicazione è duplice. Da un lato, la scalabilità della ricerca vulnerabilità guadagna un acceleratore che i team umani non possono replicare in volume. Dall'altro, emerge una pressione sui vendor per ridefinire i tempi e i metodi di disclosure: quando un tool autonomo produce exploit dimostrati, chi detiene la responsabilità di coordinazione diventa una domanda aperta.
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.
Fonti
- https://thehackernews.com/2026/06/autonomous-ai-tool-finds-2-year-old-rce.html
- https://nvd.nist.gov/vuln/detail/CVE-2026-23479
- https://redis.io/blog/security-advisory-cve202623479-cve202625243-cve-2026-25588-cve202625589-cve-2026-23631/
- https://www.wiz.io/blog/github-rce-vulnerability-cve-2026-3854
- https://nvd.nist.gov/vuln
- https://nvd.nist.gov/vuln/search
- https://nvd.nist.gov/vuln/categories
- https://nvd.nist.gov/vuln/data-feeds
- https://nvd.nist.gov/vuln/vendor-comments