El parche no funcionó: nuevos exploits vuelven a vulnerar la seguridad de Redis
Los desarrolladores pensaron que habían cerrado la brecha, pero los hackers sortearon fácilmente los parches.
Incluso la corrección aplicada no siempre cierra por completo la brecha antigua, y el conjunto publicado de exploits de demostración mostró ejecución remota de comandos en Redis 6.2.22, 7.4.9, 8.6.4, 8.8.0 y 8.8.1. Parte del código elude las correcciones publicadas anteriormente para CVE-2026-25243 и CVE-2026-25589. Ambas vulnerabilidades tienen una puntuación de 8.8 en la escala CVSS 3.1.
En las versiones 6.2.22, 7.4.9 y 8.6.4 el ataque utiliza una liberación doble de una zona de memoria al procesar acuses de recibo negativos compartidos en los grupos de consumidores de Redis Streams. Tal fallo permite corromper la estructura de memoria del proceso y lograr la ejecución de un comando en el servidor. El exploit presentado funciona a pesar de la corrección de CVE-2026-25243.
Para Redis 8.8.0 los autores aprovecharon un error independiente de desbordamiento de memoria en la estructura TDigest del módulo integrado RedisBloom. Otro exploit afecta a las estructuras TopK en Redis 8.8.0 y 8.8.1 y elude la corrección incompleta de CVE-2026-25589. Tras limpiar parte de los punteros, la función de eliminación seguía accediendo a elementos fuera del área de memoria asignada.
Para ejecutar el código, el atacante necesita poder enviar los comandos EVAL, RESTORE y XGROUP. Los exploits para la rama 8.8 también requieren el módulo RedisBloom integrado. Las demostraciones dependen de la disposición de los objetos en memoria, por lo que los autores las probaron en contenedores oficiales recientes sin conexiones ni comandos externos.
Durante las pruebas, los exploits ejecutaron de forma consistente el comando especificado en las versiones compatibles. Los autores califican el código como no destructivo; sin embargo, tras su ejecución permanecen claves de servicio y estructuras dañadas en la base. Desplazamientos incorrectos para una compilación no oficial también pueden provocar que Redis termine de forma abrupta.
El conjunto se publicó únicamente para pruebas autorizadas. Los autores recomiendan ejecutar las demostraciones en instancias recientes e aisladas, calcular por separado los desplazamientos para compilaciones no oficiales y no conservar el estado de Redis 8.8.0 tras explotar el error en TDigest.