Los agentes de Kimi K3 encontraron Redis Zero-Days y construyeron un exploit RCE, dicen los investigadores – CYBERDEFENSA.MX
Redis enviado siete comunicados de seguridad el 23 de julio después de que los investigadores publicaran PoC de RCE autenticados para el stock Redis 6.2.22, 7.4.9, 8.6.4 y 8.8.0.
Las cuatro cadenas requieren RESTAURAR. Las cadenas Streams también necesitan EVAL y XGROUP; la cadena 8.8.0 necesita EVAL y el módulo RedisBloom incluido. Redis dice que la memoria subyacente Las fallas pueden conducir a la ejecución remota de código..
Redis 6.2.23, 7.2.15 y 7.4.10 corrigen el uso después de la liberación de NACK compartido de Streams; Redis 8.2.8, 8.4.5 y 8.6.5 solucionan el problema de Streams y las escrituras fuera de límites de RedisBloom y TDigest; Redis 8.8.1 corrige los cargadores RedisBloom y TDigest, mientras que la protección Streams ya estaba presente en Redis 8.8.0.
Dos objetivos de PoC, Redis 6.2.22 y 7.4.9, fueron las actualizaciones de seguridad de mayo que Redis les dijo a los usuarios que instalaran, pero esas versiones no incluían la protección de propiedad NACK compartida.
Actualice a la versión fija para la rama implementada. Hasta entonces, revoque RESTORE de las cuentas que no lo necesiten estrictamente y bloquee el acceso a la red que no sea de confianza. Restringir RESTORE corta ambos caminos revelados.
Ni las notas de la versión de Redis del 23 de julio ni el repositorios públicos de PoC revisó la explotación en estado salvaje reportada al 24 de julio de 2026.
Dos caminos a través de RESTORE
La ruta de Redis Streams es un error de propiedad compartida. Un objeto RDB corrupto puede hacer que dos consumidores apunten al mismo registro de entrada pendiente, por lo que eliminar a ambos consumidores libera el mismo objeto dos veces.
El script publicado está diseñado para convertir la corrupción de la memoria resultante en un acceso arbitrario a la memoria y, en última instancia, invocar el sistema().
La ruta de RedisBloom es una escritura fuera de límites en el cargador TDigest RDB. El cargador asignó memoria a partir de un valor serializado, pero confió en un campo de capacidad independiente controlado por el atacante al decidir cuántos datos cargar.
El script de Redis 8.8.0 está diseñado para convertir esa discrepancia en primitivas de lectura y escritura, filtrar direcciones de Redis y libc y llamar al sistema().
La cadena NACK compartida de Streams
El primer camino está en Redis Streams. Un objeto RDB corrupto puede hacer que dos consumidores apunten al mismo registro de entrada pendiente, representado internamente por un streamNACK. Quitar al primer consumidor libera el objeto y deja al segundo con un puntero colgando. Luego, los scripts también eliminan al segundo consumidor. Un trozo, dos gratis.
Notas de la versión de Redis 8.6.4 citar PR #15081. Pero una revisión de la fuente realizada por The Hacker News encontró que el etiquetado fuente 8.6.4 carece de la verificación de propiedad duplicada agregada por ese cambio. El guardia aparece en Redis 8.6.5lanzado el 23 de julio.
El script Redis 8.6.4 publicado está diseñado para convertir la doble liberación en acceso a memoria arbitrario y luego envenenar una función hash de base de datos para que un GET diseñado invoque system(). Restaura el puntero y comprueba si Redis todavía responde.
La cadena RedisBloom TDigest
La segunda ruta se encuentra en el cargador RedisBloom TDigest RDB. Asignó sus matrices de centroides a partir de un valor de compresión serializado y luego confió en un campo de capacidad separado controlado por el atacante al decidir cuántos nodos se podían cargar. Una pequeña asignación real combinada con metadatos inflados produce una escritura fuera de límites.
El Secuencia de comandos de Redis 8.8.0 está diseñado para convertir la escritura en primitivas de lectura y escritura, filtrar direcciones Redis y libc y envenenar una función hash de base de datos para que un GET diseñado llame al sistema(). A prueba de concepto separada publicó la misma causa raíz y una cadena RCE autenticada contra Redis 8.8.0.
Redis arreglo de julio requiere que la capacidad TDigest cargada coincida con la asignación derivada del valor de compresión. También limita los contadores de nodos fusionados y no fusionados antes de leer las matrices.
Siete lanzamientos, ningún nuevo registro CVE
El repositorio considera que el problema de Streams es parte de una «familia de arreglos incompletos» CVE-2026-25589, pero Redis asigna ese CVE a la corrupción de memoria de RedisBloom durante la RESTAURACIÓN, no a la falla de NACK compartido de Streams. Las notas de la versión de julio de Redis no enumeran ninguna puntuación CVE o CVSS para ninguna de las nuevas clases de errores.
Hasta el 24 de julio, las búsquedas realizadas por The Hacker News no encontraron ningún registro NVD separado para los hallazgos compartidos de NACK o TDigest de julio. NVD todavía enumera los registros de mayo para CVE-2026-25243 y CVE-2026-25589. una búsqueda de Catálogo de vulnerabilidades explotadas conocidas de CISA no devolvió ninguna entrada para ninguno de los identificadores.
La divulgación sigue a otra falla de Redis RCE descubierta por IA y corregida en mayo. Amigos de Bera se describe a sí mismo como «Investigación de agentes de IA». chaofan shou dijo en X que los agentes de Kimi K3 encontraron 19 días cero de Redis en aproximadamente 90 minutos, y dijo otra carrera produjo el exploit Redis 8.8.0 en 27 minutos.
Esos recuentos, tiempos y el grado de autonomía reclamado siguen siendo autoinformados. El registro público de Redis confirma las fallas y las soluciona. No valida el recuento de días cero reclamado ni la independencia con la que trabajaron los agentes.
Redis 6.2.22 y 7.4.9 fueron el destino de mayo. En julio, ambos necesitaban otra actualización. Verifique la versión exacta de la rama, no si Redis fue simplemente «parcheado recientemente».
