Redis envió siete versiones de seguridad el 23 de julio después de que los investigadores publicaran PoC RCE certificados para Redis 6.2.22, 7.4.9, 8.6.4 y 8.8.0.
Se requiere RESTORE para las cuatro cadenas. Las cadenas de flujos también requieren EVAL y XGROUP. Las cadenas 8.8.0 requieren el módulo RedisBloom incluido con EVAL. Redis dice que la falla de memoria subyacente podría conducir a la ejecución remota de código.
Redis 6.2.23, 7.2.15 y 7.4.10 corrigen el uso de NACK compartido de transmisión después del lanzamiento. Redis 8.2.8, 8.4.5 y 8.6.5 solucionan el problema de Streams y las escrituras fuera de límites de RedisBloom y TDigest. Redis 8.8.1 corrige los cargadores RedisBloom y TDigest, pero la protección Streams ya estaba presente en Redis 8.8.0.
Dos objetivos de PoC, Redis 6.2.22 y 7.4.9, fueron actualizaciones de seguridad de mayo que Redis pidió a los usuarios que instalaran, pero estas versiones no incluían la protección de propiedad NACK compartida.
Actualice a la versión corregida de la rama implementada. Hasta entonces, revoque las RESTAURACIONES de las cuentas que no las requieran estrictamente y bloquee el acceso a la red que no sea de confianza. Restringir RESTORE bloquea ambas rutas expuestas.
Ni las notas de la versión de Redis del 23 de julio ni el repositorio público de PoC han revisado ningún exploit real informado hasta el 24 de julio de 2026.
Dos caminos a través de RESTORE
Las rutas de Redis Streams son un error de propiedad compartida. Si un objeto RDB se daña, dos consumidores pueden apuntar al mismo registro de entrada pendiente, por lo que si elimina a ambos consumidores, el mismo objeto se liberará dos veces.
El script publicado está diseñado para convertir la corrupción de la memoria resultante en accesos arbitrarios a la memoria y, en última instancia, llama al sistema().
La ruta de RedisBloom está escrita fuera del alcance del cargador TDigest RDB. El cargador asignó memoria a partir de un valor serializado, pero se basó en un campo de capacidad separado controlado por el atacante para determinar cuántos datos cargar.
El script de Redis 8.8.0 está diseñado para traducir esta discrepancia en primitivas de lectura y escritura, filtrar direcciones de Redis y libc y llamar al sistema().
Cadena NACK para compartir transmisiones
La primera ruta está dentro de la secuencia de Redis. Cuando un objeto RDB se daña, dos consumidores pueden apuntar al mismo registro de entrada pendiente, representado internamente por un streamNACK. Al eliminar el primer consumidor se libera el objeto y el segundo consumidor aún mantiene el puntero colgante. A continuación, el script también elimina al segundo consumidor. 1 trozo, 2 gratis.
Las notas de la versión de Redis 8.6.4 citan el PR #15081. Sin embargo, una revisión de la fuente realizada por The Hacker News encontró que a la fuente etiquetada 8.6.4 le faltaba la verificación de propiedad duplicada agregada por ese cambio. Este guardia aparece en Redis 8.6.5, lanzado el 23 de julio.
El script Redis 8.6.4 publicado está diseñado para convertir dobles liberaciones en accesos arbitrarios a la memoria, envenenar la función hash de la base de datos y hacer que un GET diseñado llame al sistema(). Restaure los punteros y verifique si Redis aún responde.
Cadena RedisBloom TDigest
La segunda ruta está en el cargador RedisBloom TDigest RDB. Confiamos en otro campo de capacidad controlado por el atacante para asignar la matriz de centroides a partir de los valores de compresión serializados y determinar la cantidad de nodos que se podían cargar. La combinación de pequeñas asignaciones reales y metadatos inflados provoca escrituras fuera de límites.
El script de Redis 8.8.0 está diseñado para convertir escrituras en primitivas de lectura y escritura, filtrar direcciones de Redis y libc y envenenar la función hash de la base de datos para que un GET diseñado llame al sistema(). Otra prueba de concepto expuso la misma causa raíz y la cadena RCE autenticada en Redis 8.8.0.
La corrección de julio para Redis requiere que la capacidad TDigest cargada coincida con la asignación derivada del valor de compresión. Además, limite los contadores de nodos fusionados y no fusionados antes de leer la matriz.
7 lanzamientos, sin nuevos registros CVE
Aunque el repositorio se refiere al problema de Streams como parte de la «familia de arreglos incompletos» de CVE-2026-25589, Redis asigna el CVE a una corrupción de memoria de RedisBloom durante RESTORE en lugar de a una falla NACK compartida en Streams. Las notas de la versión de julio de Redis no enumeran las puntuaciones CVE o CVSS para ninguna de las nuevas clases de errores.
Hasta el 24 de julio, una búsqueda realizada por The Hacker News no encontró registros NVD separados para los hallazgos compartidos de NACK o TDigest de julio. NVD continuó enumerando los registros de mayo para CVE-2026-25243 y CVE-2026-25589. Una búsqueda en el catálogo de vulnerabilidades conocidas y explotadas de CISA no arrojó entradas para ninguno de los identificadores.
Esta divulgación sigue a otra falla de Redis RCE descubierta por AI y corregida en mayo. Bera Buddies se describe a sí mismo como «investigación de agentes de IA». Chaofan Shou le dijo a X que el agente Kimi K3 descubrió 19 días cero de Redis en aproximadamente 90 minutos, y otra ejecución produjo un exploit de Redis 8.8.0 en 27 minutos.
El número, el momento y el grado de autonomía reclamados siguen siendo autodeclarados. El registro público de Redis confirma defectos y los soluciona. No hay verificación del recuento de días cero reclamado ni de la independencia con la que operaron los agentes.
Redis 6.2.22 y 7.4.9 fueron los destinos de mayo. En julio, ambos requirieron otra actualización. Verifique la versión exacta de la rama, no solo si Redis está «parcheado recientemente».
Source link
