¿Una base de datos que lleva más de una década permitiendo ejecución remota de código? Redis, el Ferrari del "almacenamiento en memoria", acaba de estamparse contra una pared con una vulnerabilidad CVSS 10.0. Y sí, han tardado 13 años en notarlo. Ni es broma, ni tiene perdón.
CVE-2025-49844, también conocido como RediShell, ha sido descrito por la gente de Wiz como lo que es: un bug del tamaño de un hangar que permite ejecutar código nativo en el host desde un script Lua malicioso. Porque sí, Redis soporta scripts Lua por defecto, y sí, los scripts pueden escapar del sandbox si lo fuerzas bien.
¿Qué tan mal estamos hablando?
Pongámoslo fácil: si tienes acceso autenticado a una instancia Redis, puedes mandar un script Lua especialmente podrido, aprovechar un use-after-free, y plantar código en el sistema host como si fueras el dueño del cortijo. Todo desde dentro. Todo gracias a 13 años de mirar a otro lado.
El bug afecta a todas las versiones de Redis con scripting habilitado. Se parcheó recién el 3 de octubre de 2025, en las versiones 6.2.20, 7.2.11, 7.4.6, 8.0.4 y 8.2.2. Pero claro, parcharlo es solo para los que viven en el mundo feliz donde los sysadmins actualizan.
¿Y cómo se explota la joyita?
Primero necesitas estar autenticado. Tranquilo: 60.000 instancias Redis están en Internet sin contraseña. La fiesta ya está servida.
Una vez dentro, el script Lua —cocinado con cariño— engaña al recolector de basura para liberar memoria que después es reutilizada de forma corrupta. Boom: tienes ejecución remota de código. Desde ahí, lo típico: secuestrar datos, cifrar todo, lanzar cryptojacking, pivotar a otros servicios cloud... Lo que se te ocurra. Redis no discrimina.
Y no, no es que esto haya salido de un exploit 0-day supercomplejo. El fallo ha estado ahí, esperando pacientemente, desde hace 13 años, según Wiz. El tipo de bug que te hace replantearte quién audita el código en proyectos tan críticos.
¿Soluciones reales? O parches para la conciencia
-
Actualiza Redis. Fácil de decir, raro de ver en entornos reales.
-
Bloquea
EVALyEVALSHAcon listas ACL. -
No expongas Redis a Internet. Parece obvio. No lo es.
-
Autenticación fuerte. También parece obvio. También se ignora.
Pero nada de esto arregla el problema de fondo: ¿cómo demonios llegó este bug tan grotesco a pasar 13 años sin que nadie lo mirara dos veces? Redis no es un proyecto menor. Es una piedra angular del stack moderno.
El lado sucio del cuento: 330.000 razones para preocuparte
A día de hoy, hay 330.000 instancias Redis expuestas al mundo. De esas, más de 60.000 están completamente abiertas. Sin auth. Sin protección. Y ahora, con una vulnerabilidad que da acceso total al host.
Wiz lo ha dejado claro: la combinación de alta exposición, configuraciones por defecto lamentables y un fallo crítico es dinamita. Si esto no es un caso de negligencia estructural, que baje Linus Torvalds y lo vea.
Lo mejor: no hay evidencia (aún) de explotación en el mundo real. Lo peor: eso no significa que no esté ya ocurriendo en silencio, con actores que saben muy bien lo que hacen y que no necesitan llamar la atención.
Lo que nadie te cuenta sobre esto
Redis es la droga favorita de los que quieren "performance sin complicaciones". Su scripting con Lua es una de esas funcionalidades mágicas que muchos implementan sin entender del todo. Total, ¿qué puede pasar?
Pues lo que ha pasado: 13 años ejecutando código como si esto fuera una rave de ciberseguridad.
Nadie auditó bien el sandbox de Lua. Nadie se planteó que alguien lo intentaría romper. Y lo peor: Redis se volvió popular precisamente por su supuesta “simplicidad robusta”. Spoiler: ni simple, ni robusta.
Este bug es el ejemplo perfecto del tecnoptimismo suicida. Esa fe ciega en que si algo es open source y tiene logo bonito, no puede estar podrido por dentro. Redis acaba de demostrar que también los gigantes tienen pies de barro... y de código podrido.