Redis ha corregido una peligrosa vulnerabilidad de ejecución remota de código (RCE) que permaneció oculta durante más de dos años en una de las bases de datos en memoria más utilizadas del mundo. El fallo, identificado como CVE-2026-23479, permitía que usuarios autenticados ejecutaran comandos arbitrarios del sistema operativo en el servidor que alojaba la instancia vulnerable de Redis.
Lo que hace especialmente relevante este descubrimiento es que la vulnerabilidad no fue detectada mediante auditorías tradicionales o revisiones de código manuales, sino por una herramienta autónoma de inteligencia artificial diseñada para analizar grandes bases de código en busca de errores de seguridad complejos.
El hallazgo vuelve a poner sobre la mesa el creciente papel de la IA en la investigación de vulnerabilidades y demuestra cómo errores aparentemente inocuos pueden permanecer ocultos durante años incluso en proyectos ampliamente auditados y desplegados en millones de entornos empresariales y en la nube.
CVE-2026-23479: una vulnerabilidad crítica de uso después de liberar memoria
La vulnerabilidad CVE-2026-23479 corresponde a un error de tipo Use-After-Free (CWE-416), una de las categorías de fallos de corrupción de memoria más peligrosas en aplicaciones desarrolladas en C.
Según los análisis publicados por los investigadores, el problema se encuentra en la función:
unblockClientOnKey()
ubicada dentro del archivo:
src/blocked.c
Esta función se activa cuando Redis desbloquea clientes que estaban esperando la disponibilidad de determinados recursos o eventos.
El problema surge porque la función invoca internamente:
processCommandAndResetClient()
Sin embargo, esta llamada puede liberar la estructura del cliente durante su ejecución como efecto secundario.
A pesar de ello, el código continúa utilizando el mismo puntero posteriormente, generando una condición clásica de uso después de liberar memoria.
Este tipo de vulnerabilidades puede permitir que un atacante manipule estructuras internas del programa y obtenga control sobre la ejecución del proceso.
Cómo nació el fallo y por qué permaneció oculto durante años
La investigación de Wiz reveló que la vulnerabilidad no apareció debido a un único error de programación.
En realidad, fue el resultado de dos modificaciones aparentemente inofensivas introducidas durante 2023.
El primer cambio llegó mediante la solicitud de incorporación:
PR #11012
publicada en enero de 2023.
Posteriormente, una segunda modificación introducida mediante:
PR #11568
en marzo de 2023 añadió nuevos accesos a estructuras de clientes después de la llamada vulnerable.
Individualmente, ninguno de los cambios representaba un problema evidente.
Sin embargo, la combinación de ambos creó una condición explotable que terminó llegando a Redis 7.2.0 y permaneció presente en todas las ramas estables posteriores.
Durante más de dos años, el fallo sobrevivió a múltiples revisiones de código, auditorías internas y evaluaciones de seguridad.
El papel de la inteligencia artificial en el descubrimiento
Uno de los aspectos más destacados de este caso es que la vulnerabilidad fue descubierta por Team Xint Code, una herramienta autónoma basada en inteligencia artificial diseñada para identificar errores complejos dentro de grandes proyectos de software.
La tecnología fue presentada durante el evento ZeroDay.Cloud 2025 celebrado en Londres y forma parte de una nueva generación de sistemas de análisis automatizado capaces de encontrar patrones difíciles de detectar para los revisores humanos.
La detección de CVE-2026-23479 representa un ejemplo práctico de cómo la inteligencia artificial está comenzando a desempeñar un papel relevante en la investigación ofensiva y defensiva de ciberseguridad.
Cómo funciona la cadena de explotación
Los investigadores demostraron una cadena completa de explotación capaz de transformar el fallo de memoria en una ejecución remota de código totalmente funcional.
La explotación se desarrolla en tres etapas principales.
Fase 1: filtración de direcciones de memoria
El atacante utiliza un sencillo script Lua:
Esta operación permite obtener información sobre direcciones internas de memoria utilizadas por Redis.
Con ello se supera una de las barreras más importantes para explotar vulnerabilidades modernas: la aleatorización de memoria.
Fase 2: reutilización de memoria liberada
Posteriormente, el atacante manipula límites de memoria asociados a clientes bloqueados utilizando comandos relacionados con Streams.
Mediante una secuencia cuidadosamente diseñada de operaciones XREAD, XADD y SET, Redis libera una estructura de cliente mientras continúa utilizando referencias hacia ella.
En ese momento se introduce una estructura falsa controlada por el atacante que ocupa la misma ubicación de memoria previamente liberada.
Fase 3: secuestro del flujo de ejecución
La etapa final aprovecha la función:
updateClientMemoryUsage()
para realizar escrituras fuera de límites controladas.
Estas escrituras permiten modificar punteros críticos utilizados por Redis y redirigir llamadas legítimas del programa hacia funciones del sistema operativo.
En la demostración presentada por los investigadores, una llamada a:
strcasecmp()
fue redirigida hacia:
system()
lo que permitió ejecutar comandos arbitrarios directamente sobre el servidor comprometido.
El impacto en entornos cloud es especialmente preocupante
La gravedad de esta vulnerabilidad aumenta considerablemente debido a la enorme adopción de Redis en entornos cloud.
Según datos publicados por Wiz, Redis se encuentra presente en la mayoría de las infraestructuras modernas desplegadas en proveedores de nube pública.
Más preocupante aún es que una gran cantidad de instancias continúan funcionando sin autenticación robusta o utilizando configuraciones excesivamente permisivas.
Aunque la explotación requiere autenticación previa, muchas implementaciones otorgan al usuario predeterminado acceso completo a comandos administrativos, scripting y gestión avanzada del servidor.
Esto facilita enormemente la explotación en entornos mal configurados.
¿Qué versiones están afectadas?
La vulnerabilidad afecta a:
- Redis 7.2.0 y versiones posteriores dentro de la misma rama.
- Varias ramas estables mantenidas hasta mayo de 2026.
Redis publicó correcciones de seguridad el 5 de mayo de 2026.
Las versiones seguras son:
- Redis 7.2.14
- Redis 7.4.9
- Redis 8.2.6
- Redis 8.4.3
- Redis 8.6.3
Los usuarios deben actualizar inmediatamente a una de estas versiones o superiores.
Medidas de mitigación recomendadas
Si no es posible aplicar los parches de forma inmediata, los expertos recomiendan implementar varias medidas defensivas.
Restringir acceso desde Internet
Redis nunca debería exponerse directamente a Internet pública.
Utilizar TLS
Las conexiones deben protegerse mediante cifrado para evitar accesos no autorizados.
Revisar ACL y privilegios
Los roles que combinan permisos de:
- CONFIG
- @admin
- @scripting
- Streams
deben revisarse cuidadosamente.
Deshabilitar Lua cuando no sea necesario
La eliminación de permisos asociados a scripting Lua bloquea la primera etapa de la cadena de explotación.
Rotar credenciales compartidas
Las organizaciones deberían renovar credenciales utilizadas por múltiples aplicaciones o equipos.
Redis y el creciente desafío de las vulnerabilidades avanzadas
CVE-2026-23479 se suma a una serie de vulnerabilidades críticas que han afectado recientemente al ecosistema Redis, incluyendo el conocido fallo RediShell descubierto en 2025.
Sin embargo, este caso destaca por un motivo adicional: fue una herramienta de inteligencia artificial la que logró identificar un error que había pasado desapercibido durante más de dos años en uno de los proyectos de código abierto más utilizados del mundo.
La vulnerabilidad demuestra cómo pequeños cambios aparentemente inocuos pueden combinarse para generar escenarios de ejecución remota de código extremadamente peligrosos. También evidencia que la inteligencia artificial está comenzando a transformar la forma en que se descubren vulnerabilidades, acelerando tanto las capacidades defensivas como las ofensivas en el panorama actual de la ciberseguridad.
Para las organizaciones que utilizan Redis en producción, la actualización inmediata a versiones corregidas y la revisión de configuraciones de acceso deben considerarse una prioridad crítica para evitar posibles compromisos futuros.
Fuente: The Hacker News
