Una IA ganó un concurso de hackers: durante dos años nadie se percató de una vulnerabilidad en Redis.

En Redis se encontró un error peligroso que permaneció sin detectarse durante más de dos años y ahora recibió una descripción pública detallada. La vulnerabilidad permite a un usuario con acceso a la base de datos ejecutar comandos del sistema operativo en el servidor donde se ejecuta Redis. El problema fue detectado por una herramienta autónoma basada en inteligencia artificial, creada para buscar errores en grandes bases de código.

La vulnerabilidad CVE-2026-23479 (CVSS:2.0/AV:N/AC:L/Au:S/C:C/I:C/A:C — 9.0 (High)) apareció en Redis 7.2.0 y afectó a todas las ramas estables hasta las correcciones publicadas el 5 de mayo. El hallazgo lo informó Team Xint Code, y la descripción técnica completa ya está publicada.

La situación se complica por la popularidad de Redis en la infraestructura en la nube. Según Wiz, Redis se encuentra en la mayoría de los entornos en la nube, y muchas instancias funcionan sin contraseña. Para atacar hace falta acceder al sistema, pero con la configuración estándar el usuario por defecto ya tiene todos los privilegios necesarios para la cadena de explotación.

El error está en la función unblockClientOnKey() en el archivo src/blocked.c. La función se activa cuando un evento sobre una clave despierta un comando bloqueado. Redis pasa el comando en espera a processCommandAndResetClient(), y luego continúa usando el mismo puntero al cliente. El problema es que la función invocada puede liberar la memoria del cliente, como se indica explícitamente en el comentario de su definición. El código llamante ignora el valor devuelto y vuelve a acceder a la estructura ya liberada.

Según Wiz, la vulnerabilidad apareció por dos cambios en el código. En enero de 2023, cuando se revisaron partes del código, se añadió una llamada sin comprobar el resultado. En marzo de 2023 otro cambio añadió accesos adicionales al cliente después de esa llamada. Por separado, ambos cambios no crearon una situación peligrosa, pero juntos llegaron a Redis 7.2.0 y pasaron varias comprobaciones de seguridad.

La cadena de ataque comienza con una filtración de una dirección en memoria. Luego el atacante libera la estructura del cliente y coloca en su lugar una estructura falsa. A continuación, el mecanismo normal de contabilización de memoria de Redis se usa contra el propio servidor para sobrescribir un puntero a función.

La variante publicada del ataque se desarrolla en tres etapas. Primero, un script corto en Lua revela un puntero en memoria. Después, el atacante ajusta los límites de memoria del cliente, pone al cliente inflado en espera sobre una corriente de datos, reduce los límites y lo despierta. Redis libera al cliente bloqueado durante la ejecución de la llamada, y el siguiente comando SET ocupa inmediatamente el espacio liberado con la estructura falsa. En la etapa final, al actualizar la contabilización de memoria, Redis escribe fuera del área prevista y redirige la llamada strcasecmp() a system(). A partir de ese momento, el siguiente comando que procese Redis se ejecuta como un comando de la shell.

La imagen oficial de Redis para Docker facilita la parte final del ataque. En ella solo está habilitada la protección RELRO parcial, por lo que la tabla global de desplazamientos permanece escribible en tiempo de ejecución. La aleatorización del espacio de direcciones y un ejecutable posicionalmente independiente no protegen en este caso, porque la escritura se hace relativa a un objeto global con un desplazamiento fijo en la versión compilada.

Para el ataque completo se necesita una sesión con permisos para CONFIG SET, EVAL, los comandos de flujo XREAD y XADD, y los comandos básicos SET y GET. En términos de listas de control de acceso de Redis, son las categorías @admin, @scripting, @stream, @read y @write. El usuario por defecto tiene todas estas capacidades, y en muchos entornos esos permisos se agrupan en una única función compartida de aplicación u operador. Prohibir CONFIG rompe la cadena publicada, pero no elimina el propio error de acceso a memoria liberada.

Team Xint Code demostró la ejecución funcional del código en ZeroDay.Cloud 2025, la competición de hacking de Wiz que se celebró en Londres en diciembre de 2025.

Redis afirmó que no observa indicios de que la vulnerabilidad se esté explotando en sus entornos ni entre sus clientes. En el momento de la publicación tampoco había informes abiertos de ataques en condiciones reales. Pero la descripción técnica completa ya está disponible, por lo que el riesgo de reutilización de la cadena por otros atacantes ha aumentado.

Se recomienda a los usuarios de Redis actualizar a la versión corregida de su rama: 7.2.14, 7.4.9, 8.2.6, 8.4.3 o 8.6.3. Todas las versiones se publicaron el 5 de mayo. Las pequeñas actualizaciones dentro de una misma rama se pueden instalar sin migraciones complejas. Los servicios gestionados en la nube se actualizan según su propio calendario, y Redis Cloud, según Redis, ya recibió la corrección.

Si no es posible aplicar la actualización pronto, Redis no debería estar accesible desde internet abierto. Es mejor proteger el acceso con TLS y separar los privilegios de modo que una sola función no combine @admin, CONFIG y @scripting. Si no se usa Lua, conviene desactivar la categoría @scripting: eso elimina la primera etapa del ataque publicado que filtra la dirección en memoria.

En primera instancia conviene revisar las instancias de Redis accesibles desde internet, las credenciales compartidas de las aplicaciones y las funciones que simultanean CONFIG, scripts de Lua y acceso a flujos de datos. Es preferible reemplazar contraseñas compartidas y claves de acceso.

CVE-2026-23479 se convirtió en una de las cinco vulnerabilidades de Redis con riesgo de ejecución remota de código reveladas el mes pasado. Apareció también poco después de RediShell, otro fallo de Redis de 2025 relacionado con accesos a memoria liberada y scripts de Lua. En este nuevo caso es especialmente destacable que el error no se detectó durante una revisión de código habitual, sino mediante una herramienta autónoma basada en inteligencia artificial: dos correcciones crearon el problema, estuvo dos años en uno de los almacenes de datos más extendidos y solo afloró en una competición de hacking.