En mayo de 2026, los desarrolladores de Redis corrigieron una vulnerabilidad crítica de ejecución remota de código (RCE) tras la autenticación, denominada DarkReplica (CVE-2026-23631). Este fallo permitía a los atacantes obtener el control total del servidor host de Redis, aprovechando la potencia de sus motores de Lua para ejecutar lógica personalizada directamente en la base de datos.

En mayo de 2026, los desarrolladores de Redis corrigieron una peligrosa vulnerabilidad de ejecución remota de código post-autenticación, apodada DarkReplica (CVE-2026-23631), que permitía a los atacantes obtener el control total de un host de Redis.

Redis proporciona potentes motores Lua del lado del servidor, lo que permite a los administradores ejecutar lógica personalizada directamente en la base de datos.

Existen dos motores de este tipo: el motor de scripting más antiguo y el motor de funciones más reciente, que almacena librerías y las sincroniza entre nodos.

DarkReplica se dirige al motor de funciones durante la replicación. Un atacante que pueda autenticarse en una instancia de Redis puede instruir a ese servidor para que se convierta en una réplica de un maestro controlado por el atacante utilizando el comando SLAVEOF.

Cuando la réplica se sincroniza, el servidor puede cargar un nuevo contexto de función desde el archivo RDB (volcado de Redis) entrante.

Vulnerabilidad RCE de Redis

El problema fue descubierto durante un esfuerzo de investigación de ZeroDay.Cloud 2025 y demostró cómo las funciones complejas y las interacciones inesperadas pueden conducir a riesgos críticos.

Redis maneja las funciones Lua de larga ejecución cediendo periódicamente el control para procesar eventos; así es como funciona FUNCTION KILL.

Pero procesar eventos de replicación mientras una función lenta está pausada abre un vacío legal: el manejador de replicación libera el motor Lua en ejecución y lo reemplaza con un nuevo contexto sin evitar que la función pausada se reanude.

La función pausada continúa entonces ejecutándose con sus objetos relacionados y su lua_State liberados, produciendo una condición de uso posterior a la liberación (use-after-free).

Explotar esa condición es complejo pero práctico. Los investigadores crearon primitivas para filtrar direcciones de memoria heap, forzar asignaciones deterministas de heap y crear objetos Lua falsos.

Al ejecutar el código vulnerable dentro de corrutinas y rociar cuidadosamente el área de memoria de Lua, recuperaron el control de la VM de Lua y produjeron primitivas de lectura/escritura.

Desde ahí, redirigieron los punteros de función internos para llamar a funciones de libc. Finalmente, invocaron comandos del sistema, logrando la ejecución remota de código completa en el host.

La vulnerabilidad afectó a muchas series de versiones mantenidas de Redis y fue parcheada el 5 de mayo de 2026, en las versiones 7.2.x, 7.4.x, 8.2.x, 8.4.x y 8.6.x.

Debes actualizar a las versiones corregidas inmediatamente y auditar las instancias de Redis expuestas.

Debido a que la explotación requiere autenticación y un trabajo avanzado de memoria, el riesgo es mayor para los servidores mal configurados que permiten credenciales débiles o inexistentes, o para entornos donde los atacantes puedan obtener credenciales válidas.

El incidente resalta que las funciones complejas de scripting en proceso y de replicación aumentan la superficie de ataque, subrayando la importancia de una sincronización y gestión del ciclo de vida cuidadosas.

Debes actualizar Redis, aplicar controles de red y una autenticación fuerte, y monitorizar cualquier cambio inesperado en la configuración o funcionalidad del agente.

El investigador publicó la descripción técnica completa y el exploit. Los proveedores y las herramientas de seguridad en la nube ofrecen ahora avisos para detectar las instalaciones afectadas.