Un agente de IA encontró 19 zero-days en Redis en unos 90 minutos

Un investigador afirma que agentes de IA construidos sobre el modelo Kimi K3 de Moonshot AI encontraron 19 vulnerabilidades zero-day en Redis, uno de los almacenes de datos en memoria más desplegados de internet, y convirtieron al menos dos en exploits funcionales de ejecución remota de código autenticada, con una cadena de exploit producida en unos 27 minutos. Redis publicó siete versiones de seguridad el 23 de julio en respuesta. Las cifras principales las declara el propio investigador y no se han verificado de forma independiente, pero las vulnerabilidades y los parches son reales y constan en el registro.

Qué se encontró realmente

La investigación abarcó compilaciones estándar de Redis 6.2.22, 7.4.9, 8.6.4 y 8.8.0, y encadenó dos fallos distintos de seguridad de memoria hasta obtener exploits funcionales:

• Un double-free de «shared-NACK» en los streams. Un objeto RDB corrupto puede hacer que dos consumidores distintos de un stream apunten al mismo registro de entrada pendiente. Al eliminar ambos consumidores, ese registro compartido se libera dos veces: un double-free clásico, pero alcanzado a través del propio formato de replicación/persistencia de Redis y no de un paquete de red malformado. Según la información publicada, el exploit resultante envenena una función hash de la base de datos para que una llamada GET manipulada invoque system(), es decir, ejecución arbitraria de comandos.
• Un desbordamiento de heap en el módulo TDigest de RedisBloom incluido. El cargador RDB de TDigest reserva memoria dimensionada para un valor serializado y luego confía en un campo de capacidad distinto, controlado por el atacante, para decidir cuántos datos carga realmente en ese búfer: un desajuste clásico de reservar un tamaño y confiar en otro que produce una escritura fuera de límites, aprovechable para filtrar direcciones de memoria de Redis y de libc y sortear el ASLR.

Ambos fallos requieren autenticación para alcanzarse: no son RCE sin autenticación detectables escaneando internet. Pero un número enorme de despliegues reales de Redis funcionan con una autenticación débil o predeterminada, o son accesibles desde un host adyacente ya comprometido, que es exactamente el nivel de acceso que dan por hecho estos exploits.

La afirmación sobre el agente de IA

El investigador Chaofan Shou dijo en X que los agentes de Kimi K3, con solo la instrucción general de buscar problemas de corrupción de memoria, clonaron el código fuente de Redis, le aplicaron fuzzing y depuraron los fallos con GDB, sacando a la luz 19 zero-days en unos 90 minutos de tiempo de agente, y que el exploit para Redis 8.8.0 en concreto se produjo en 27 minutos. Es un plazo realmente rápido para una clase de vulnerabilidad (double-frees en la deserialización RDB, fallos de confianza entre campos) que normalmente exige a un investigador humano días de fuzzing manual y triaje de fallos para aislarla y convertirla en arma.

Conviene precisar qué está verificado de verdad. Las vulnerabilidades son reales: las propias notas de parche de Redis confirman los fallos y las correcciones. El número de 19, los tiempos de 27 y 90 minutos y el grado de autonomía del agente los declara el investigador y no los ha reproducido ni auditado de forma independiente ningún tercero. En el momento de escribir esto, ninguno de los dos fallos tiene una entrada publicada en la NVD, y el catálogo de vulnerabilidades explotadas conocidas de CISA no incluye ninguno: es investigación divulgada, no (todavía) evidencia de explotación en la práctica.

Estado de los parches

Redis publicó correcciones en ambas ramas activas el 23 de julio de 2026: 6.2.23, 7.2.15 y 7.4.10 (double-free de los streams) y 8.2.8, 8.4.5, 8.6.5 y 8.8.1 (ambos problemas, RedisBloom incluido). Cabe destacar que las versiones de seguridad de mayo que corregían un problema anterior relacionado, incluidas la 6.2.22 y la 7.4.9, versiones a las que se pidió expresamente a los usuarios que actualizaran, seguían sin la protección de propiedad que cierra este double-free concreto, lo que significa que los equipos que parchearon diligentemente en mayo siguen expuestos hasta que apliquen esta segunda ronda.

Qué significa para los equipos de seguridad

• Vuelve a parchear Redis, aunque lo parchearas en mayo. Entre las versiones afectadas hay algunas que se publicaron como corrección de un fallo anterior relacionado. «Ya actualizamos» no es una suposición segura sin comprobar la versión de parche concreta frente a los avisos de Redis del 23 de julio.
• Que solo sea con autenticación no significa que el riesgo sea bajo por defecto. Si la autenticación de Redis es débil, compartida o accesible desde una carga de trabajo adyacente comprometida (algo habitual en la práctica), «requiere autenticación» se convierte en «no requiere casi nada».
• La investigación de vulnerabilidades asistida por IA cambia las cuentas de tu ventana de parcheo. Se sostenga o no la cifra exacta de 27 minutos, la dirección es real: las canalizaciones agénticas de fuzzing y triaje abaratan encontrar fallos de seguridad de memoria en infraestructura de código abierto muy desplegada. La distancia entre «existe un fallo» y «alguien lo convierte en arma» se está acortando tanto para los defensores como para los atacantes.
• Lee la investigación de seguridad autodeclarada como leerías un benchmark de un fabricante. Las CVE y los parches subyacentes se pueden confirmar de forma independiente en las propias notas de versión de Redis. Las afirmaciones concretas sobre la productividad del agente de IA aún no se han verificado de forma independiente: trata las dos mitades de la historia con niveles de confianza distintos.

Lee la noticia completa en Cybersecurity News →

Los estudios Threat Model y Cyber War Room de PlayCISO plantean escenarios como este: una dependencia muy desplegada, un parche fácil de aplicar a medias y una decisión sobre la rapidez con la que tu organización vuelve a parchear de verdad. Mira cómo aborda PlayCISO los escenarios de gestión de parches y de riesgo de dependencias →