Análisis de la vulnerabilidad RCE CVE-2026-23479 en Redis y mitigaciones

Foto del autor

CyberSecureFox Editorial Team

Publicado:

El 5 de mayo Redis publicó correcciones para cinco vulnerabilidades de clase RCE, la más grave de las cuales — CVE-2026-23479 — obtuvo una puntuación de CVSS 8.8 según NVD (v3.1). Es un error de tipo use-after-free (CWE-416), presente en todas las ramas estables de Redis desde la versión 7.2.0 — más de dos años. Ya hay un exploit público disponible, aunque por ahora no se han registrado casos de explotación en ataques reales. Todos los administradores de instancias de Redis deben actualizar a las versiones 7.2.14, 7.4.9, 8.2.6, 8.4.3 o 8.6.3 y, si no es posible actualizar de inmediato, limitar los privilegios ACL y el acceso de red al servidor.

Esencia técnica de la vulnerabilidad

La vulnerabilidad se encuentra en la función unblockClientOnKey() del archivo src/blocked.c. Esta función se llama al reactivar un comando bloqueado por un evento de clave. Pasa el comando encolado a través de processCommandAndResetClient() y luego continúa utilizando el mismo puntero a la estructura del cliente. El problema es que processCommandAndResetClient() puede liberar el cliente como efecto secundario — esto se indica explícitamente en el comentario del encabezado de la función. El código que la invoca ignora el valor de retorno y accede a memoria que ya ha sido liberada.

Según los investigadores, el bug surgió como resultado de la interacción de dos commits. Un refactor en enero de 2023 (PR #11012) añadió una llamada sin comprobación. Un cambio en marzo de 2023 (PR #11568) añadió un acceso adicional a la estructura del cliente tras esa llamada. Ninguno de los commits por separado creaba la vulnerabilidad: peligrosa se volvió precisamente su combinación, que pasó a estar disponible públicamente con la versión 7.2.0.

Redis valora la vulnerabilidad con CVSS 4.0 en 7.7, lo que es inferior a la puntuación de NVD. La discrepancia se explica por las diferencias entre las metodologías de evaluación de las versiones 3.1 y 4.0, y no por un desacuerdo sobre la gravedad.

Cadena de explotación publicada

Ya se ha publicado una descripción técnica completa del exploit. Según se indica, la cadena de ataque consta de tres etapas:

  • Filtración de la dirección de la heap. Un script Lua de una sola línea (EVAL "return tostring(redis.call)" 0) devuelve un puntero a la heap, necesario para los cálculos posteriores.
  • Suplantación de la estructura del cliente. El atacante manipula los límites de memoria del cliente, bloquea un cliente «inflado» sobre un stream, después restablece los límites y lo despierta. Redis libera al cliente bloqueado en mitad del procesamiento, y un comando SET en pipeline ocupa de inmediato la ranura liberada con una estructura de cliente falsa.
  • Sobrescritura del puntero de función. El mecanismo estándar de contabilización de memoria en updateClientMemoryUsage() realiza un acceso fuera de los límites del array con un decremento, usando campos controlados por el atacante. El objetivo es la Global Offset Table (GOT): redirigir strcasecmp() a system(). El siguiente comando que Redis analice se ejecuta como comando de shell.

Según los investigadores, la imagen oficial de Docker de Redis se distribuye con RELRO parcial, dejando la GOT accesible para escritura en tiempo de ejecución. ASLR y PIE no ayudan, ya que la escritura se realiza en relación con una variable global con un desplazamiento fijo definido en la fase de compilación.

Requisitos de explotación y alcance de la amenaza

La cadena completa del exploit requiere una sesión autenticada con privilegios para CONFIG SET, EVAL, comandos de streams (XREAD/XADD) y los básicos SET/GET. En términos de ACL de Redis, esto corresponde a las categorías @admin, @scripting, @stream, @read y @write. El usuario por defecto posee todos estos privilegios.

La vulnerabilidad fue descubierta por el equipo Team Xint Code. La empresa Theori describe Xint Code como una herramienta de seguridad autónoma basada en IA, diseñada para encontrar errores en bases de código de gran tamaño. Es un caso llamativo: dos commits crearon la vulnerabilidad, esta pasó por múltiples rondas de revisión de código durante dos años, y al final no fue una persona, sino una herramienta automatizada, la que la encontró en el marco de una competición de hacking.

Redis ha declarado que no dispone de evidencias de explotación en sus propios entornos ni en los de sus clientes. En el momento de la publicación no se habían recibido informes de explotación en ataques reales. Sin embargo, la publicación de la cadena técnica completa incrementa de forma considerable el riesgo de explotación posterior.

Recomendaciones prácticas

La prioridad es actualizar de inmediato. Instale las versiones corregidas correspondientes a su serie:

  • Redis 7.2 → 7.2.14
  • Redis 7.4 → 7.4.9
  • Redis 8.2 → 8.2.6
  • Redis 8.4 → 8.4.3
  • Redis 8.6 → 8.6.3

Según el proveedor, Redis Cloud ya ha sido actualizado. Los servicios gestionados de otros proveedores se actualizan según sus propios calendarios: confirme el estado con su proveedor.

Si no es posible actualizar de inmediato:

  • Elimine el acceso directo a Redis desde Internet; colóquelo detrás de TLS.
  • Separe los privilegios ACL: ningún rol debe poseer simultáneamente @admin, CONFIG y @scripting.
  • Prohíba la categoría @scripting si no se utilizan scripts Lua: esto bloquea la primera etapa de la cadena (la filtración de la dirección de la heap).
  • Bloquear CONFIG rompe la cadena concreta publicada, pero no elimina el error básico de use-after-free.
  • Rote todas las credenciales compartidas de Redis.

Priorice las instancias accesibles desde Internet, las cuentas de aplicación compartidas y cualquier rol que combine acceso a CONFIG, scripts y streams.

CVE-2026-23479 es una de las cinco vulnerabilidades de clase RCE reveladas en el mismo paquete de actualizaciones de Redis y el segundo fallo reciente de tipo use-after-free en Redis relacionado con Lua scripting. La existencia de un PoC público, junto con el despliegue masivo de Redis, hace que la ventana para una actualización segura sea extremadamente estrecha. Actualice ahora las instancias afectadas a las versiones menores corregidas, y no después de que aparezcan los primeros informes de ataques.


CyberSecureFox Editorial Team

El equipo editorial de CyberSecureFox cubre noticias de ciberseguridad, vulnerabilidades, campañas de malware, actividad de ransomware, AI security, cloud security y security advisories de proveedores. Los materiales se preparan a partir de official advisories, datos de CVE/NVD, alertas de CISA, publicaciones de proveedores e informes públicos de investigadores. Los artículos se revisan antes de su publicación y se actualizan cuando aparece nueva información.

Deja un comentario

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.