Redis corrige RCE crítico CVE-2026-23479 que estuvo invisible durante dos años y fue descubierto por una herramienta autónoma de IA
Vulnerabilidad use-after-free con CVSS 8.8 estuvo en el flujo de desbloqueo de clientes desde la versión 7.2.0, de agosto de 2023. El bug fue encontrado por una herramienta autónoma de bug bounty.
Redis publicó el 4 de junio cinco avisos de seguridad para el servidor de caché más utilizado en aplicaciones empresariales, destacando la CVE-2026-23479, vulnerabilidad de ejecución remota de código en el camino de desbloqueo de clientes. El bug recibió un CVSS 3.1 de 8.8 y un CVSS 4.0 de 7.7, y estuvo presente desde la versión 7.2.0, lanzada en agosto de 2023. Pasó más de dos años sin ser detectado.
El descubrimiento provino de una herramienta autónoma de bug bounty asistida por IA, según Team Xint Code, que demostró una cadena completa de explotación. La función vulnerable es unblockClientOnKey(), en src/blocked.c. La lógica que reejecutable comandos bloqueados no maneja el error de processCommandAndResetClient y continúa usando un puntero de cliente ya liberado. El exploit publicado comienza con un script Lua que filtra un puntero de heap, manipula la memoria del cliente para forzar el use-after-free y termina sobrescribiendo un puntero de función en la Tabla de Desplazamiento Global para redirigir la ejecución a system().
La explotación no es trivial, pero el impacto sí
La explotación requiere una sesión autenticada contra el servidor Redis y la capacidad de emitir comandos bloqueantes como BLPOP o XREAD. En entornos correctamente segmentados, esto limita el vector a atacantes que ya tienen credenciales válidas. Para Cassio Goldschmidt, ex-líder de producto de seguridad de Symantec y actualmente en una consultoría de seguridad de aplicaciones, este es un escenario común en ataques post-acceso inicial, donde el atacante ya obtuvo credenciales de aplicación por phishing o por una clave AWS expuesta en un repositorio.
En la mayoría de las implementaciones de producción, Redis se encuentra en redes internas y es accedido por cuentas de servicio con permisos amplios. Las versiones afectadas van de 7.2.x a 8.6.x, lo que cubre prácticamente todo Redis en producción que recibió actualizaciones desde 2023. Las versiones corregidas son 7.2.14, 7.4.9, 8.2.6, 8.4.3 y 8.6.3.
Otras cuatro CVEs en el mismo aviso
Además de la CVE-2026-23479, Redis abordó en el mismo aviso CVE-2026-25243, CVE-2026-25588, CVE-2026-25589 y CVE-2026-23631. Ninguna alcanza el mismo CVSS, pero tres de ellas también afectan al servidor principal y requieren un parche coordinado. La combinación hace que la ventana actual sea uno de los eventos de remediación más relevantes del año para los equipos de plataforma, comparable al aviso de Atlassian de enero, que afectó a Confluence Data Center.
La forma en que la vulnerabilidad fue encontrada importa tanto como la falla en sí. El flujo unblockClientOnKey es exactamente el tipo de camino de borde que escapa de la auditoría humana: depende de una secuencia inusual de comandos, del tiempo entre hilos y del manejo de errores poco ejercitado en fuzzers tradicionales. El grupo de Xint Code describe en su informe una ejecución autónoma que cubrió meses de auditoría en horas. "El costo marginal de auditar código abierto ha caído de forma desproporcionada para quienes operan estas herramientas", escribió el equipo.
Qué cambia para los equipos de plataforma
Redis Inc. distribuye el servidor core bajo licencia RSAL y SSPL desde 2024, pero la mayor parte de las instalaciones corporativas ejecutan imágenes construidas internamente o paquetes mantenidos por equipos de plataforma. Esto significa que el ciclo de remediación no pasa por un proveedor único; cada clúster necesita ser actualizado por su propio equipo, a la velocidad de su propia gestión de cambios. Para Goldman Sachs, Itaú, UBS y cualquier banco que mantiene cientos de instancias Redis para caché de sesiones y colas de procesamiento, esto representa semanas de ventana abierta.
La implicación operacional aparece en tres frentes. Operadores de SaaS B2B con Redis multi-tenant necesitan aplicar parches antes de que credenciales comprometidas de un cliente se conviertan en RCE en el host completo. Equipos de plataforma en bancos y retail necesitan acelerar la liberación de imágenes corregidas, bajo el desafío conocido de que BLPOP y XREAD son primitivas de colas ampliamente utilizadas en producción. Los proveedores administrados, incluidos AWS ElastiCache, Google Memorystore y Azure Cache for Redis, aún no han publicado un cronograma público de aplicación automática, y los clientes que ejecutan versiones autogestionadas deben hacerlo por su cuenta.
El caso ofrece un nuevo dato para los CISOs que están eligiendo dónde colocar sus presupuestos para herramientas autónomas de seguridad. Team Xint Code mostró que el camino es viable para la detección de zero-day en código maduro. El contrapunto pertinente, planteado por Tavis Ormandy en Google Project Zero a lo largo de 2025, es que estas herramientas aún requieren una validación humana significativa antes de convertirse en un informe aceptado por upstream. La próxima semana mostrará si otros mantenedores reciben el mismo tipo de divulgación coordinada de Xint para otros proyectos críticos.