Redis tiene parcheado un uso después de la liberación en su código de cliente de bloqueo que permite a un usuario autenticado ejecutar comandos arbitrarios del sistema operativo en la máquina que aloja la base de datos. La falla fue encontrada por una herramienta de inteligencia artificial autónoma diseñada para detectar errores en grandes bases de código.
Seguimiento como CVE-2026-23479la falla se introdujo en Redis 7.2.0 y permaneció en todas las ramas estables hasta las correcciones del 5 de mayo, sin que nadie se diera cuenta durante más de dos años. NVD lo califica con 8,8 según CVSS 3,1; Redis lo enumera como 7.7 en CVSS 4.0. Fue informado por Team Xint Code, y una completa técnica escribir ahora es público.
La huella de la nube empeora esto. El análisis de Wiz, publicado con el informe del exploit, coloca a Redis en una gran mayoría de entornos de nube, y la mayoría de esas instancias se ejecutan sin contraseña. El exploit necesita una sesión autenticada, pero en una implementación predeterminada, el usuario predeterminado ya posee todos los privilegios que requiere la cadena.
El defecto vive en desbloquearClientOnKey() en src/bloqueado.cque se activa cuando un evento clave activa un comando bloqueado. La función envía el comando en cola a través de procesoCommandAndResetClient()luego sigue usando el mismo puntero de cliente. El problema: esa función puede liberar al cliente como efecto secundario, y su propio comentario en el encabezado lo dice. La persona que llama ignora el valor de retorno y lee la estructura liberada de todos modos, un uso después de la liberación (CWE-416).
Según el análisis de Wiz, el error requirió dos confirmaciones para crearse. Una refactorización de enero de 2023 (PR #11012) agregó la llamada no marcada. Un cambio de marzo de 2023 (PR #11568) agregó más acceso de cliente después. Ninguno de los dos era peligroso por sí solo. Juntos, alcanzaron la disponibilidad general en 7.2.0 y sobrevivieron a múltiples rondas de revisión de seguridad.
La cadena comienza filtrando una dirección de montón. A partir de ahí, libera a un cliente e introduce uno falso en la misma memoria, luego convierte la propia memoria de Redis en contra de sí misma para sobrescribir un puntero de función.
La versión publicada se ejecuta en tres etapas.
- Primero, un script Lua de una línea (EVAL «return tostring(redis.call)» 0) pierde un puntero de montón.
- En segundo lugar, el atacante prepara los límites de memoria del cliente, estaciona un cliente inflado en una secuencia, luego elimina los límites y lo activa. Redis libera al cliente bloqueado en mitad de la llamada y un SET canalizado recupera inmediatamente el espacio liberado con una estructura de cliente falsa.
- En tercer lugar, la contabilidad de memoria de rutina de Redis en updateClientMemoryUsage() realiza una disminución fuera de los límites utilizando campos controlados por el atacante, dirigidos a la tabla de compensación global para redireccionar strcasecmp() a system(). El siguiente comando que Redis analiza se ejecuta como un comando de shell.
La imagen oficial de Redis Docker facilita el último paso. Se envía solo con RELRO parcial, lo que permite que GOT se pueda escribir en tiempo de ejecución. ASLR y PIE no ayudan aquí, ya que la escritura es relativa a un global cuyo desplazamiento se fija en el momento de la compilación.
La cadena completa necesita una sesión autenticada con CONFIG SET, EVAL, comandos de transmisión (XREAD/XADD) y SET/GET básico, que se asigna a las categorías ACL @admin, @scripting, @stream y @read/@write.
El usuario predeterminado los tiene todos y, en la mayoría de las implementaciones, estos privilegios se agrupan en una única aplicación compartida o función de operador. Negar CONFIG por completo rompe esta cadena específica, aunque no el uso después de la liberación subyacente.
El equipo Xint Code demostró el funcionamiento del RCE en ZeroDay.Nube 2025la competencia de piratería de Wiz en Londres el pasado diciembre. teoría describe Código Xint como una herramienta de seguridad de IA autónoma creada para detectar errores en grandes bases de código.
Redis dijo que no tenía evidencia de explotación en su propio entorno o en el de sus clientes, y hasta el momento de esta publicación no ha aparecido ningún informe público al respecto. La cadena técnica completa ahora es pública, lo que aumenta el riesgo de explotación posterior.
Actualice al parche menor para su serie: 7.2.14, 7.4.9, 8.2.6, 8.4.3 u 8.6.3, todos lanzados el 5 de mayo. Las actualizaciones menores dentro de una serie deben ser inmediatas. Los servicios administrados de Redis se actualizan según sus propios cronogramas y Redis dice que Redis Cloud ya está listo.
| Rama | Afectado | Fijado |
|---|---|---|
| 7.2.x | 7.2.0 a 7.2.13 | 7.2.14 |
| 7.4.x | 7.4.0 a 7.4.8 | 7.4.9 |
| 8.2.x | 8.2.0 a 8.2.5 | 8.2.6 |
| 8.4.x | 8.4.0 a 8.4.2 | 8.4.3 |
| 8.6.x | 8.6.0 a 8.6.2 | 8.6.3 |
Si aún no puede parchear: mantenga Redis fuera de la Internet pública y detrás de TLS, ajuste las ACL para que ningún rol mantenga juntos a @admin, CONFIG y @scripting, y deniegue @scripting si no usa Lua, lo que elimina la fuga de la Etapa 1.
Priorice las instancias expuestas a Internet, las credenciales de aplicaciones compartidas y cualquier función que combine CONFIG, secuencias de comandos y acceso a transmisiones. Mientras lo hace, rote las credenciales de Redis ampliamente compartidas.
CVE-2026-23479 fue uno de cinco fallas de Redis de clase RCE revelado el mes pasado, y sigue a la falla RediShell 2025 de Redis, otro uso después de la liberación autenticado que involucra secuencias de comandos Lua. También es el que detectó una herramienta de inteligencia artificial. Dos confirmaciones lo colocaron, dos años lo ocultaron y permaneció en una de las bases de datos más implementadas hasta que un concurso de piratería lo sacó a la luz. La revisión del código nunca lo hizo.
