Redis ha parcheado un uso después de la liberación en el código del cliente de bloqueo que permite a los usuarios autenticados ejecutar comandos arbitrarios del sistema operativo en la máquina que aloja la base de datos. La falla fue descubierta por una herramienta de inteligencia artificial autónoma creada para detectar errores en grandes bases de código.
La falla, rastreada como CVE-2026-23479, se introdujo en Redis 7.2.0 y pasó desapercibida durante más de dos años, existiendo en todas las ramas estables hasta la corrección del 5 de mayo. NVD tiene una calificación CVSS 3.1 de 8,8. Redis aparece como 7.7 para CVSS 4.0. Esto fue informado por Team Xint Code y ahora se ha publicado la documentación técnica completa.
La huella de la nube empeora esto aún más. Según el análisis de Wiz publicado con el artículo sobre el exploit, Redis está presente en la mayoría de los entornos de nube y la mayoría de esas instancias se ejecutan sin contraseña. El exploit requiere una sesión autenticada, pero en las implementaciones predeterminadas el usuario predeterminado ya tiene todos los privilegios necesarios en la cadena.
La falla existe en unblockClientOnKey() en src/blocked.c y ocurre cuando un evento clave activa un comando bloqueado. Esta función envía comandos en cola a través de ProcessCommandAndResetClient() y continúa usando el mismo puntero de cliente. El problema es que esta función puede liberar al cliente como efecto secundario, y el propio comentario del encabezado de la función lo dice. La persona que llama ignora el valor de retorno y lee la estructura liberada de todos modos (uso después de la liberación (CWE-416)).
Según el análisis de Wiz, se necesitaron dos confirmaciones para crear el error. La refactorización de enero de 2023 (PR #11012) agregó llamadas no marcadas. Desde entonces, los cambios realizados en marzo de 2023 (PR #11568) han agregado acceso de cliente. Ninguno de los dos era peligroso por sí solo. Ambos estaban generalmente disponibles en 7.2.0 y han sobrevivido a múltiples revisiones de seguridad.
La cadena comienza filtrando una dirección de montón. A partir de ahí, libera al cliente, introduce un cliente falso en la misma memoria y sobrescribe el puntero de función obligando a la propia memoria de Redis a contabilizarse contra sí misma.
La versión publicada se ejecutará 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 ajusta el límite de memoria del cliente, estaciona el cliente inflado en la transmisión y lo activa con el límite reducido. Redis libera a los clientes bloqueados a mitad de la llamada y el SET canalizado reutiliza inmediatamente las ranuras liberadas 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 un campo controlado por el atacante. Esto tiene como objetivo redirigir strcasecmp() en system() a la tabla de compensación global. Los siguientes comandos que analiza Redis se ejecutan como comandos de shell.
Usar la imagen oficial de Redis Docker facilita el último paso. Solo se incluye un RELRO parcial y se puede escribir en GOT en tiempo de ejecución. ASLR y PIE no sirven aquí ya que las escrituras son globalmente relativas con compensaciones fijas en el momento de la compilación.
Una cadena completa requiere una sesión autenticada con CONFIG SET, EVAL, comandos de transmisión (XREAD/XADD) y SET/GET básicos que se asignan a las categorías de ACL @admin, @scripting, @stream y @read/@write.
El usuario predeterminado tiene todos estos privilegios y, en la mayoría de las implementaciones, estos privilegios se agrupan en una única aplicación compartida o función de operador. Rechazar CONFIG rompe por completo esta cadena en particular, pero no el uso después de la liberación subyacente.
El equipo Xint Code demostró un RCE funcional en ZeroDay.Cloud 2025, la competencia de piratería de Wiz en Londres en diciembre pasado. Theori describe Xint Code como una herramienta de seguridad de IA autónoma creada para detectar errores en grandes bases de código.
Redis dijo que no había evidencia de explotación en su propio entorno o en el de sus clientes y que no había informes activos disponibles públicamente en el momento de la publicación. La cadena técnica completa ahora está disponible públicamente, lo que aumenta el riesgo de explotación posterior.
Actualice a una versión menor parcheada de la serie: 7.2.14, 7.4.9, 8.2.6, 8.4.3 o 8.6.3. Todo lanzado el 5 de mayo. Las actualizaciones menores dentro de la serie están destinadas a visitas sin cita previa. Los servicios administrados de Redis se actualizan según su propio cronograma, y Redis dice que Redis Cloud ya lo ha hecho.
BranchAffectedFixed 7.2.x7.2.0 ~ 7.2.137.2.14 7.4.x7.4.0 ~ 7.4.87.4.9 8.2.x8.2.0 ~ 8.2.58.2.6 8.4.x8.4.0 ~ 8.4.28.4.3 8.6.x8.6.0 ~ 8.6.28.6.3
Si aún no puede parcharlo, aísle Redis de la Internet pública, colóquelo detrás de TLS, ajuste sus ACL para que ningún rol tenga @admin, CONFIG y @scripting, y deniegue @scripting si no usa Lua. Esto evita fugas de etapa 1.
Prefiera instancias expuestas a Internet, credenciales de aplicaciones compartidas y roles que combinen CONFIG, script y acceso a transmisiones. Rote las credenciales de Redis ampliamente compartidas entre ellos.
CVE-2026-23479 es una de las cinco fallas de Redis de clase RCE reveladas el mes pasado y sigue a la falla de RediShell de 2025 en Redis, otro uso después de la liberación certificado relacionado con los scripts de Lua. Esto también es lo que capturó la herramienta de IA. Dos confirmaciones incrustaron el archivo y permaneció oculto durante dos años en una de las bases de datos implementadas con más frecuencia hasta que salió a la luz a través de un concurso de piratería. La revisión del código nunca se realizó.
Source link
