Parches de seguridad de Redis tras descubrimientos de agentes de IA
Redis lanzó siete parches de seguridad el 23 de julio después de que investigadores publicaran pruebas de concepto (PoC) de ejecución remota de código (RCE) autenticada para las versiones de stock Redis 6.2.22, 7.4.9, 8.6.4 y 8.8.0. Todas las cadenas de ataque requieren el comando RESTORE. Las cadenas de Streams también necesitan EVAL y XGROUP; la cadena para 8.8.0 necesita EVAL y el módulo RedisBloom incluido. Según Redis, los fallos de memoria subyacentes pueden llevar a ejecución remota de código.
Las versiones corregidas son: Redis 6.2.23, 7.2.15 y 7.4.10 solucionan el uso después de liberación (use-after-free) compartido de NACK en Streams; Redis 8.2.8, 8.4.5 y 8.6.5 corrigen tanto el problema de Streams como las escrituras fuera de límites en RedisBloom y TDigest; Redis 8.8.1 soluciona los cargadores de RedisBloom y TDigest, mientras que la protección para Streams ya estaba presente en Redis 8.8.0. Dos de los objetivos de las PoC, Redis 6.2.22 y 7.4.9, corresponden a las actualizaciones de seguridad de mayo que Redis recomendó instalar, pero esas versiones no incluían la protección de propiedad de NACK compartido.
Se recomienda actualizar a la versión corregida para la rama desplegada. Mientras tanto, se debe revocar el permiso RESTORE de las cuentas que no lo necesiten estrictamente y bloquear el acceso de red no confiable. Restringir RESTORE corta ambos caminos de ataque divulgados. Ni las notas de la versión del 23 de julio ni los repositorios públicos de PoC revisados reportaron explotación en entornos reales hasta el 24 de julio de 2026.
Dos caminos a través de RESTORE
El camino de Redis Streams es un error de propiedad compartida. Un objeto RDB corrupto puede hacer que dos consumidores apunten al mismo registro de entrada pendiente, de modo que al eliminar ambos consumidores se libera el mismo objeto dos veces. El script publicado está diseñado para convertir la corrupción de memoria resultante en acceso arbitrario a memoria y, finalmente, invocar system(). El camino de RedisBloom es una escritura fuera de límites en el cargador TDigest del RDB. El cargador asignaba memoria a partir de un valor serializado, pero confiaba en un campo de capacidad controlado por el atacante para decidir cuántos datos cargar. El script para Redis 8.8.0 está diseñado para convertir esa discrepancia en primitivas de lectura y escritura, filtrar direcciones de Redis y libc, y llamar a system().
La cadena de Streams: uso después de liberación (use-after-free)
El primer camino está en Redis Streams. Un objeto RDB corrupto puede hacer que dos consumidores apunten al mismo registro de entrada pendiente, representado internamente como un streamNACK. Eliminar el primer consumidor libera el objeto y deja al segundo con un puntero colgante. Los scripts luego eliminan también el segundo consumidor. Un fragmento, dos liberaciones. Las notas de la versión Redis 8.6.4 citan el PR #15081, pero una revisión del código fuente por parte de The Hacker News encontró que el código etiquetado como 8.6.4 carece de la comprobación de propiedad duplicada añadida por ese cambio. La protección aparece en Redis 8.6.5, lanzado el 23 de julio. El script publicado para Redis 8.6.4 está diseñado para convertir el doble liberación en acceso arbitrario a memoria, luego envenenar una función hash de base de datos para que un GET manipulado invoque system(). Restaura el puntero y verifica si Redis sigue respondiendo.
La cadena de RedisBloom TDigest
El segundo camino reside en el cargador TDigest de RedisBloom. Asignaba sus arrays de centroides a partir de un valor de compresión serializado, pero confiaba en un campo de capacidad controlado por el atacante para decidir cuántos nodos podían cargarse. Una asignación real pequeña combinada con metadatos inflados produce una escritura fuera de límites. El script para Redis 8.8.0 está diseñado para convertir esa escritura en primitivas de lectura y escritura, filtrar direcciones de Redis y libc, y envenenar una función hash de base de datos para que un GET manipulado llame a system(). Una prueba de concepto separada publicó la misma causa raíz y una cadena RCE autenticada contra Redis 8.8.0. La corrección de julio de Redis requiere que la capacidad del TDigest cargado coincida con la asignación derivada del valor de compresión. También limita los contadores de nodos fusionados y no fusionados antes de leer los arrays.
Siete versiones, sin nuevos registros CVE
El repositorio llama al problema de Streams parte de una "familia de corrección incompleta" de CVE-2026-25589, pero Redis asigna ese CVE a la corrupción de memoria en RedisBloom durante RESTORE, no al fallo de Streams. Las notas de la versión de julio de Redis no listan ningún CVE ni puntuación CVSS para ninguna de las dos nuevas clases de errores. Al 24 de julio, búsquedas de The Hacker News no encontraron ningún registro separado del NVD para los hallazgos de julio sobre Streams o TDigest. El NVD aún listaba los registros de mayo para CVE-2026-25243 y CVE-2026-25589. Una búsqueda en el catálogo de vulnerabilidades explotadas conocidas de CISA no devolvió ninguna entrada para ninguno de los identificadores.
La divulgación sigue a otro fallo RCE en Redis descubierto por IA y parcheado en mayo. Bera Buddies se describe a sí mismo como "Investigación de Agentes de IA". Chaofan Shou dijo en X que los agentes Kimi K3 encontraron 19 zero-days de Redis en aproximadamente 90 minutos, y que otra ejecución produjo el exploit para Redis 8.8.0 en 27 minutos. Esas cifras, tiempos y el grado de autonomía declarado son auto-reportados. El registro público de Redis confirma los fallos y las correcciones, pero no valida la cantidad de zero-days afirmada ni la independencia con la que trabajaron los agentes. Redis 6.2.22 y 7.4.9 fueron las versiones objetivo de mayo; para julio, ambas necesitaban otra actualización. Se recomienda verificar la versión exacta de la rama, no solo si Redis fue "parcheado recientemente".
Deja una respuesta