CVE-2026-23479: el fallo use-after-free de Redis que podría convertir tu servidor en una puerta de ejecución remota

Un nuevo exploit para Redis, registrado como CVE-2026-23479, ha vuelto a poner el foco sobre cómo fallos sutiles en código maduro pueden convertirse en puertas de ejecución remota en entornos productivos. El problema, introducido en la rama 7.2.0 y presente en las ramas estables durante más de dos años hasta los parches del 5 de mayo, es un clásico use-after-free (CWE-416) en la gestión de clientes bloqueados que permite a un atacante con credenciales apropiadas tomar control del servidor Redis en determinados escenarios.

La naturaleza técnica del fallo reside en una función que despierta comandos bloqueados y reenvía la ejecución sin comprobar si la llamada que procesa el comando ha liberado la estructura de cliente. Ese acceso posterior a la memoria ya liberada es la puerta que abre una cadena de explotación de tres etapas: fuga de puntero de heap vía una llamada EVAL, colocación de una estructura de cliente falsa en la memoria reutilizada, y manipulación de la contabilidad de memoria para sobrescribir un puntero de librería (GOT) y redirigir una función a system(), logrando así RCE. El exploit publicado demuestra que con las funciones EVAL, CONFIG SET, XREAD/XADD y operaciones básicas SET/GET—todas contenidas en privilegios por defecto—es posible ejecutar comandos arbitrarios en el host.

Las métricas de severidad no son unívocas: la NVD lo puntúa 8.8 bajo CVSS 3.1 (NVD CVE-2026-23479) mientras Redis aplica su propia valoración con CVSS 4.0 en 7.7, pero el vector real de riesgo lo define la exposición de Redis en la nube y las configuraciones por defecto. Análisis publicados por investigadores y equipos de seguridad señalan que una gran proporción de despliegues en la nube ejecutan Redis sin contraseña o con credenciales compartidas entre aplicaciones, lo que convierte este fallo en un riesgo práctico mucho mayor que una mera puntuación en un CVSS.

Hay aspectos de ingeniería que merecen atención editorial: el bug resultó de la combinación accidental de dos cambios separados en código (ver los pull requests históricos en el repositorio de Redis, por ejemplo PR #11012 y PR #11568), ninguno peligroso por sí solo. Esa concatenación, y su permanencia tras varias revisiones de seguridad, es una llamada de atención sobre las limitaciones de las revisiones tradicionales y el valor añadido que ofrecen análisis dinámicos y fuzzing específicos para memoria.

La presencia del contenedor oficial de Redis complica el panorama: la imagen Docker oficial deriva en una reducción de mecanismos de protección en tiempo de ejecución (RELRO parcial), dejando la Global Offset Table modificable en entorno containerizado y facilitando la etapa final del exploit. Dado que el ataque escribe relativamente a una variable global conocida en tiempo de enlace, mitigaciones como ASLR/PIE en muchos despliegues no bastan por sí solas.

Acciones concretas y priorizadas para administradores: actualice inmediatamente a las versiones parcheadas 7.2.14, 7.4.9, 8.2.6, 8.4.3 u 8.6.3 publicadas el 5 de mayo; si no puede parchear de inmediato, retire instancias del acceso público, obligue TLS, segmente privilegios ACL para que ningún rol combine @admin, CONFIG y @scripting, y considere negar @scripting si no utiliza Lua (esto evita la fuga inicial que facilita el exploit). Además, rote credenciales compartidas, priorice la revisión de instancias expuestas a internet y verifique el calendario de parches de sus servicios gestionados (Redis Cloud y otros pueden ya haber aplicado correcciones). Consulte la página oficial de seguridad de Redis para avisos y releases: https://redis.io/topics/security.

También es imprescindible instrumentar detección: busque patrones inusuales como EVAL frecuentes desde cuentas de servicio, cambios de configuración inesperados (CONFIG SET), uso intensivo o extraño de streams XADD/XREAD, y procesos secundarios que indiquen ejecución de comandos del sistema. A efectos forenses, recolecte logs y snapshots de memoria cuando sospeche compromiso, y analice si hay rotaciones o accesos inusuales desde cuentas que antes compartían privilegios elevados.

Finalmente, este hallazgo tiene lecciones más amplias para la industria: un error crítico puede nacer de la interacción de dos cambios aparentemente inocuos y permanecer oculto durante años, y las herramientas automatizadas—incluidas las de origen AI que cazan patrones de bug en grandes bases de código—están jugando ya un papel real en descubrir vectores sofisticados. El mensaje para equipos de desarrollo y seguridad es claro: priorizar pruebas de memoria, revisiones enfocadas en patrones de liberación/reuso y controles de seguridad por defecto menos permisivos reduce la probabilidad de que problemas similares lleguen a producción.