Redis corrige una vulnerabilidad crítica de RCE tras 13 años: así afecta CVE-2025-49844 (“RediShell”) y qué hacer ya

Redis ha publicado parches urgentes para CVE-2025-49844, un fallo crítico (CVSS 10,0) en su motor de scripts Lua que puede permitir ejecución remota de código (RCE). El error —presente en el código desde hace 13 años— se activa con un script Lua especialmente diseñado que manipula el recolector de basura hasta provocar un use-after-free y escapar del sandbox, con capacidad de abrir shell inversas, robar credenciales y tomar el control del host. La propia Redis ha rectificado su aviso para aclarar versiones exactas ya corregidas y recomienda actualizar sin demora.

Quién está afectado

• Redis OSS/CE/Stack (con scripting Lua habilitado): están corregidas 8.2.2+, 8.0.4+, 7.4.6+, 7.2.11+ (Stack: 7.4.0-v7+ y 7.2.0-v19+).
• Redis Software (ediciones comerciales autogestionadas): parches en 7.22.2-20+, 7.8.6-207+, 7.4.6-272+, 7.2.4-138+, 6.4.2-131+.
• Redis Cloud: ya parcheado por el proveedor. Quien administre instancias por su cuenta debe actualizar a una versión fija.

Nota de contexto: algunas fuentes de terceros listan CVSS 9,8–9,9 y hablan de explotación sin privilegios. En la práctica, si una instancia no exige autenticación o expone EVAL/EVALSHA sin control, el ataque se vuelve trivial; en entornos bien protegidos, el atacante necesita autenticarse y poder ejecutar scripting.

Qué hacer ahora (plan de 10 minutos)

1. Identificar versión

• En el host: redis-server --version (busque v=8.2.2, etc.).
• En contenedores: docker exec -it <redis> redis-server --version.

2. Actualizar

• Linux (paquetes del sistema): use el repo oficial de Redis o del sistema y suba a una de las versiones fijas anteriores.
• Contenedores: tire una imagen nueva (tag parcheado) y redepliegue.
• Entornos comerciales (Software): aplique el build recomendado por Redis.

3. Mitigar si no puede actualizar hoy

• Bloquee Lua temporalmente con ACL (Redis ≥ 6): ACL SETUSER default -@scripting (Revoca EVAL y EVALSHA para el usuario por defecto.)
• O renombre comandos en redis.conf (método heredado): rename-command EVAL "" rename-command EVALSHA ""
• Refuerce acceso: active autenticación, protected-mode yes, liste IPs de confianza (bind/firewall) y TLS si procede.

Señales de compromiso (qué buscar)

Redis no ha reportado explotación en su nube, pero recomienda revisar:

• Conexiones desde IPs desconocidas o tráfico ingress/egress anómalo.
• Uso inesperado de scripting (EVAL, EVALSHA, FUNCTION *) o scripts desconocidos cargados.
• Crash del servidor con trazas que apuntan al motor Lua.
• Ejecución de comandos del sistema por el usuario redis-server.
• Cambios no explicados en ficheros de datos/configuración.

Medidas de hardening recomendadas

• Autenticación obligatoria y mínimos permisos (ACL por rol; niegue @scripting salvo a identidades de confianza).
• Segmentación de red (sin Redis expuesto a Internet; acceso sólo desde apps/hosts autorizados).
• Supervisión de comandos sensibles y alertas ante EVAL/EVALSHA/FUNCTION.
• Inventario continuo y parches en todas las instancias (incluidas dev/test).
• Backups verificados y rotación de credenciales si detecta actividad sospechosa.

Qué pasó y por qué es importante

La vulnerabilidad, bautizada “RediShell”, se documentó públicamente a inicios de octubre con un timeline que arranca en Pwn2Own y culmina en la publicación de parches. El hallazgo demuestra que un bug antiguo puede mantenerse latente en una pieza crítica de infraestructura hasta que un cambio de contexto (uso extendido de Lua y exposición de instancias) lo vuelve explotable a gran escala. Por volumen de despliegues y por el número de instancias expuestas en Internet sin autenticación, la prioridad es parchear o mitigar cuanto antes.

---

FAQ

¿Puedo “desactivar Lua” sin actualizar?
Sí, como mitigación temporal. Use ACL para retirar la categoría @scripting (o renombre EVAL/EVALSHA). Aun así, la solución real es actualizar a una versión corregida.

¿Afecta a todas las ramas de Redis?
Afecta a todas las que soportan Lua. Están parcheadas OSS/CE/Stack a partir de 8.2.2 / 8.0.4 / 7.4.6 / 7.2.11 y Redis Software en los builds indicados.

¿Necesita el atacante credenciales?
Depende del expuesto y de las ACL. Si Redis está abierto o con credenciales débiles y permite scripting, el ataque puede ser no autenticado en la práctica. En entornos correctos, se requiere usuario con permisos de scripting.

Uso Redis en Linux de distro: el paquete estable aún no trae 8.2.2.
Use repositorios oficiales de Redis o contenedores con tag parcheado. Mientras tanto, bloquee Lua, limite acceso por red y monitorice actividad.