Redis: el parche llevaba 164 días publicado

El 16 y 17 de octubre, unos señuelos registraron intentos repetidos contra un fallo de Redis. El parche de ese fallo se publicó el 5 de mayo. Entre una fecha y la otra hay 164 días. Del retraso ya sabemos todos bastante; lo que vale la pena mirar es qué información tenía delante, durante esos 164 días, quien decidió que eso podía esperar. Eran dos notas de severidad y una ficha oficial. Las dos notas no se pueden comparar entre sí, y la ficha sigue hoy igual que el 6 de mayo.

Qué se rompe exactamente

El fallo es CVE-2026-25243 y vive en el comando RESTORE, el que reconstruye una clave a partir de un valor serializado. La descripción del NVD, tal cual: «el comando RESTORE no valida correctamente los valores serializados. Un atacante autenticado con permiso para ejecutar RESTORE puede proporcionar una carga útil serializada manipulada que desencadena un acceso a memoria no válido y puede conducir a la ejecución remota de código». Está clasificado como CWE-122, desbordamiento de búfer en el montón. La misma tanda de mayo traía otros cuatro: dos usos después de liberar —uno en el flujo de desbloqueo de clientes, otro en Lua— y dos variantes del mismo RESTORE cuando intervienen los módulos RedisTimeSeries y RedisBloom.

La mitigación oficial, también literal, cabe en una línea: «restringir el acceso al comando RESTORE con reglas ACL». Red Hat lo dice con más filo: limitar la ejecución de RESTORE «exclusivamente a usuarios administrativos y de alta confianza». Es la parte útil del aviso, y volveremos a ella.

Un apunte antes de seguir, porque lo encontramos al contrastar las fuentes y no lo hemos visto escrito en ningún sitio: el registro del CVE describe este fallo como un acceso a memoria no válido en RESTORE, pero los créditos del propio aviso de Redis atribuyen el mismo identificador a otra cosa —un double-free encontrado por Emil Lerner y, además, un desbordamiento de enteros y una lectura fuera de límites en VectorSets, de Joseph Surin—. Es el mismo número para hallazgos que no son el mismo hallazgo. No cambia lo que tienes que hacer, pero sí conviene saberlo si algún día intentas casar un identificador con una línea de código.

Dos notas que no se pueden restar

El mismo CVE lleva dos puntuaciones distintas según quién firme:

La tentación es leer eso como un desacuerdo: unos dicen que es difícil de explotar y otros que es fácil. No lo es, y la diferencia importa. El 7,7 está calculado en CVSS 4.0 y el 8,8 en CVSS 3.1, que son dos reglamentos distintos en los que la casilla AC no significa lo mismo. En la 3.1, la complejidad del ataque mezclaba dos cosas: las defensas que hay que sortear y las condiciones del despliegue que tienen que darse. La 4.0 las separó: dejó en AC solo lo primero —«evadir o sortear condiciones de seguridad ya existentes», del tipo ASLR o DEP— y se sacó lo segundo a una métrica nueva, AT.

Mira entonces el vector entero del 7,7: AV:N/AC:H/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H. Ese AT:N significa «el ataque funciona en la mayoría de instancias». Es decir: quien puso el 7,7 dijo lo mismo que el NVD sobre lo único que te afecta —que no hacen falta condiciones raras para que esto funcione en tu casa— y marcó AC:H porque, siendo un desbordamiento en el montón, hay que pelearse con las protecciones de memoria. Para un fallo de ese tipo, en el reglamento de la 4.0, esa es la respuesta correcta. No hay dos opiniones sobre el mundo: hay dos escalas.

Y aquí está el problema de verdad, que no es de Redis ni del NVD sino tuyo y nuestro: esos dos números acaban en la misma columna de la misma hoja de cálculo, y alguien la ordena de mayor a menor. En la mayoría de los sitios por los que pasamos, el criterio escrito dice algo como «se parchea en 15 días lo que supere 9,0». Un 7,7 no entra. Un 8,8 tampoco, en muchos. Nadie mira de qué versión del estándar sale cada cifra, entre otras cosas porque la herramienta que las agrega tampoco lo dice. Un punto y un decimal deciden la ventana de mantenimiento, y resulta que ese punto y ese decimal son, en buena parte, un cambio de reglamento de 2023.

Si lo que buscabas era la casilla que sí predice si te van a atacar, en CVSS 4.0 existe y se llama E, madurez del exploit. En este CVE está sin definir, E:X. Nadie la rellenó.

La ficha que nadie volvió a tocar

Hay un tercer documento, y es el que peor ha envejecido. El 6 de mayo —un día después de publicarse el parche— CISA dejó registrada su valoración SSVC de este CVE con tres casillas: exploitation: none, automatable: no y technicalImpact: total. Traducido: no se ve explotación, no esperamos que se automatice a escala, pero si entran se lo llevan todo.

Las tres casillas eran defendibles el 6 de mayo. La que hoy ya no se sostiene es la primera, porque lo que registraron los señuelos en octubre es exactamente explotación intentada. Y esto es lo que nos parece importante: esa ficha sigue con fecha de 6 de mayo. No es un indicador en vivo, es una foto —y una foto de hace cinco meses, tomada un día después de que existiera el parche, que es el momento de la vida de un CVE en el que menos se sabe sobre él—. Si tu proceso consulta esa casilla y confía en que alguien la actualice, tu proceso tiene una dependencia que nadie te ha prometido cumplir. Ya le dedicamos un post a lo rápido que caducan estas etiquetas: en aquel caso de vCenter, «sin explotación conocida» duró cinco días.

«Autenticado» hace menos trabajo del que crees

«Autenticado» es la palabra que tranquiliza a todo el mundo al leer el aviso, y en un Redis real hace muchísimo menos trabajo del que sugiere. Empecemos por lo que no es opinión: la ficha oficial del comando RESTORE lo clasifica en las categorías ACL @keyspace, @write, @slow y @dangerous. Que esté en @write quiere decir que cualquier identidad a la que hayas concedido +@write puede ejecutar RESTORE por definición, no por descuido. Si tu aplicación escribe en Redis, tu aplicación puede llamar a RESTORE.

Añade a eso cómo son las instalaciones de verdad. En la mayoría que nos encontramos, «autenticación» significa una sola contraseña en requirepass, la misma para todo el que se conecte, sobre el usuario default, que viene con permisos sobre todo. Las ACL con usuarios separados existen desde Redis 6 y son estupendas, pero seguían sin estrenar en bastantes sitios donde hemos mirado, porque nadie las pidió y porque el servicio ya funcionaba. Así que «requiere autenticación» acaba describiendo a cualquiera que alcance ese puerto con la contraseña que está en el fichero de configuración de tu aplicación, en la variable de entorno de un contenedor o en un repositorio de hace tres años.

La buena noticia está en la cuarta categoría de esa lista. Si en su día aplicaste el modismo que el propio manual de Redis pone como ejemplo —+@all -@dangerous— ya estás mitigado contra esto sin haberte enterado, porque RESTORE cae dentro de @dangerous. Es la clase de decisión que se toma un martes cualquiera, cuesta diez minutos y rentabiliza cinco meses después.

No, no tienes que saltar a la 8.6.3

Casi toda la cobertura que hemos leído resume el arreglo así: «afecta a todo lo anterior a 8.6.3, actualiza a 8.6.3». Si corres una rama 7.x y te lo crees, acabas de convertir un parche de mantenimiento en un salto de versión mayor, con su ventana, sus pruebas y su riesgo.

Lo justo es decir que esa cobertura no se lo inventó: lo copió del registro del CVE. El aviso de GitHub que sirve de fuente al identificador dice, literalmente, «esto está parcheado en la versión 8.6.3», y el NVD lo recoge con un rango que marca como vulnerable todo lo anterior a 8.6.3. Según ese rango, una 7.2.14 —que está parcheada— figura como vulnerable. Quien repite «sube a 8.6.3» está citando bien una fuente que se queda corta. Las seis ramas corregidas aparecen en un sitio distinto: en la tabla del aviso del blog de Redis, que es el documento que casi nadie abre porque el identificador ya le llevó a otro.

Aquí están las seis. Lo único que tienes que hacer es quedarte en la tuya:

Es una diferencia práctica enorme. «Actualiza a 8.6.3» es un proyecto; «pasa de 7.2.13 a 7.2.14» es un martes por la tarde. Y cuando el consejo que circula convierte lo segundo en lo primero, el resultado previsible no es que la gente haga el proyecto: es que no haga nada.

Tu parche no lo publica Redis: lo publica tu distribución

Hay un segundo escalón que la pregunta «¿qué versión corro?» se salta entera. Casi nadie compila Redis: lo instala del repositorio de su sistema. Y ahí los números no se parecen a los de arriba. Para este único CVE, Red Hat ha publicado quince erratas distintas (RHSA), porque cada línea de producto va por su lado: el paquete corregido en Red Hat Enterprise Linux 9 es redis-6.2.22-1.el9_8, y conviven con él módulos redis:6 y redis:7 con sus propias fechas y sus propias ventanas de soporte extendido.

Y un detalle que se le escapa a casi toda la cobertura: en esas mismas fichas, Red Hat sigue este CVE también contra el paquete valkey. Si en su día te fuiste a la bifurcación para salir del cambio de licencia, el código que heredaste venía con esto dentro. No es un reproche a nadie —es que una bifurcación hereda la base de código entera, lo bueno y lo otro—, pero sí es un recordatorio de que el inventario no puede decir «Redis» y quedarse tan ancho. Tiene que decir qué paquete, de qué repositorio, en qué versión y quién lo actualiza.

Esto no es un caso raro. Cuando contamos dónde viven de verdad los fallos que se explotan, la respuesta incomoda: solo uno de cada ocho fallos explotados está en un aparato. El resto son piezas del montaje de tus aplicaciones —gestores de contenido, repositorios, servidores de documentos, bases de datos en memoria— que nadie siente suyas porque no tienen una pegatina con el nombre de un fabricante en la parte delantera de un rack.

Si tu disparador es el KEV, sigues esperando

Mucha gente sensata tiene escrito que se actúa cuando un fallo entra en el catálogo KEV de CISA, el de vulnerabilidades explotadas conocidas. Es un criterio defendible y nos parece mil veces mejor que no tener ninguno. Pero conviene saber qué te deja fuera: descargamos el catálogo mientras escribíamos esto —versión 2026.10.16, 1.748 entradas— y CVE-2026-25243 no está, con los señuelos ya registrando intentos.

Hay algo más en ese catálogo que merece la pena. Si buscas «Redis» como fabricante, sale una sola entrada en casi cuatro años: CVE-2022-0543, añadida el 28 de marzo de 2022, y el producto con el que figura es «Debian-specific Redis Servers». Aquel fallo no lo puso Redis, lo puso el empaquetado de una distribución.

Y hay un segundo Redis en el catálogo que no encuentras buscando Redis, porque está dentro de un Cisco: CVE-2022-20821, añadido el 23 de mayo de 2022, cuya descripción dice que el chequeo de salud de IOS XR «abre el puerto TCP 6379 por defecto» y que un atacante puede conectarse a la instancia de Redis que corre en ese contenedor. Nadie compró ahí un Redis ni lo apuntó en ninguna hoja. Venía dentro. Las dos veces que esto ha llegado al catálogo de explotación conocida, el problema no estaba en el código de Redis sino en la capa que lo empaqueta, lo despliega o lo enciende sin preguntar —que es justamente la capa que el inventario se salta—.

Según el relato: borró la base y borró sus huellas

Queda un detalle del relato de los señuelos, y es el que convierte esto en un asunto de continuidad además de seguridad. Conviene decir con precisión qué se reporta: intentos, no una ejecución de código confirmada. Dentro de esos intentos, cada pasada terminaba vaciando el espacio de claves, llevándose por delante los datos y, de paso, sus propias huellas. Si tu Redis es un caché de verdad, eso es un mal rato y una tormenta de peticiones contra la base de datos de atrás. Si además guarda sesiones, colas o estado —y guarda más de lo que la gente cree—, eso es una caída con gente mirando una pantalla.

Un atacante que se lleva sus huellas te deja con tus registros como única manera de reconstruir qué pasó. Cuánto duran y dónde están suele preguntarse el peor día; el aviso llegó 47 días tarde y tus registros duran 30 va justo de esa cuenta atrás.

Las cinco comprobaciones

Esto es lo que nosotros ejecutamos para cerrar el asunto. No lleva media hora y vale igual aunque tu rama ya esté parcheada, porque cuatro de las cinco no van de este CVE: van de lo siguiente.

1. Qué corres de verdad. redis-server --version y, desde dentro, INFO server. Anota las dos cosas: la versión que dice Redis y la versión del paquete de tu distribución. No son lo mismo y la segunda es la que te parchea.
2. Cuántas identidades hay. ACL LIST y ACL WHOAMI. Si la respuesta es un solo usuario default con permisos sobre todo, ya sabes lo que vale la palabra «autenticado» en tu casa.
3. Quítale RESTORE a quien no lo use. Es la mitigación que publica el propio fabricante, y es una línea: ACL SETUSER miapp -restore para el caso puntual, o ACL SETUSER miapp on >clave ~app:* +@all -@dangerous si prefieres cortar de raíz toda la categoría. Las aplicaciones de negocio no suelen llamar a RESTORE jamás: lo usan las herramientas de migración y copia, que no son tu API. Antes de aplicarlo, mira en los registros si alguien lo está usando.
4. Quién llega al puerto. CONFIG GET bind y CONFIG GET protected-mode, y después compruébalo desde fuera, no en el papel. Un Redis que solo escucha donde debe convierte este fallo en un problema interno, que es una categoría muy distinta.
5. Quién es el dueño. Un nombre y un apellido al lado de la palabra «Redis» en una hoja, con la fecha de la última actualización. Si esa casilla está vacía, las cuatro comprobaciones anteriores volverán a estar sin hacer dentro de seis meses.

Quién tiene la culpa de los 164 días

Casi nadie, y ése es el asunto. Redis publicó el arreglo el mismo día del aviso y para seis ramas. CISA rellenó una ficha razonable con lo que se sabía el 6 de mayo. El NVD hizo su trabajo y puntuó en el estándar que usa. Nadie mintió, nadie llegó tarde, y aun así el resultado fueron 164 días. Las piezas estaban todas bien; lo que no funciona es cómo encajan: dos escalas que se leen como si fueran una, una ficha con fecha que se consulta como si fuera un indicador en vivo, y un número que acaba decidiendo una ventana de mantenimiento sin que nadie recuerde de dónde salió.

Nosotros no vendemos licencias de Redis ni de nadie, así que podemos decir lo evidente: la respuesta a esto no se compra, se escribe. Es saber qué piezas de datos y aplicaciones sostienen tu negocio, tenerlas en un inventario con dueño y versión, y decidir el acceso a cada una antes de que haga falta, que es la parte de ciberseguridad que no aparece en ningún folleto porque no es un producto. Lo que sí vendemos es el trabajo de mantenerlo vivo cuando el equipo de dentro está ocupado sacando el producto adelante.

La pregunta con la que cerramos no es si estás parcheado. Es más barata de responder y dice más: ¿cuántas aplicaciones distintas se conectan hoy a tu Redis con la misma contraseña? Si para contestarla tienes que abrir tres repositorios, ya tienes la respuesta y no es sobre Redis.

Fuentes y método: la descripción del fallo, la fecha de publicación (5 de mayo de 2026), el CWE-122, los dos vectores CVSS en desacuerdo (7,7 en CVSS 4.0 con AC:H desde el CNA; 8,8 en CVSS 3.1 con AC:L como puntuación primaria del NVD), la ficha SSVC de CISA del 6 de mayo de 2026 y la lista de paquetes afectados —incluido valkey— y de las quince erratas RHSA proceden del registro de CVE-2026-25243 en el NVD, consultado vía su API el 20 de octubre de 2026. Las seis ramas corregidas y las versiones de los módulos, así como la mitigación por ACL, salen del aviso de seguridad de Redis del 5 de mayo de 2026 y de las notas de la versión 8.6.3. El impacto «Important» y la redacción de la mitigación de Red Hat, de su ficha del CVE. La ausencia en el KEV y la única entrada de Redis del catálogo (CVE-2022-0543, 28-03-2022) las comprobamos descargando el catálogo KEV de CISA el 20 de octubre de 2026: versión 2026.10.16, 1.748 entradas. La explotación del 16 y 17 de octubre —señuelos de Defused, mismo atacante cinco veces con temporizador, vaciado del espacio de claves— está tomada de una fuente secundaria, el artículo de securityonline.info que cita la publicación de Defused; no la hemos verificado de forma independiente y la damos como lo que es, un reporte de terceros. No tenemos telemetría propia de estos intentos. Las definiciones de AC, AT y E en CVSS 4.0 están tomadas del documento de especificación de FIRST. Las categorías ACL de RESTORE (@keyspace, @write, @slow, @dangerous) y el modismo +@all -@dangerous, de la documentación oficial del comando y del manual de ACL de Redis. Lo nuestro aquí es la lectura —que 7,7 y 8,8 no son restables porque salen de estándares distintos, que la ficha SSVC es una foto fechada y no un indicador vivo, lo que significa «autenticado» cuando RESTORE vive en @write, y el salto de versión innecesario que induce el propio registro del CVE— y las cinco comprobaciones, que son de cosecha propia. La cita de la descripción del fallo reproduce la traducción al castellano que publica el propio NVD; las demás traducciones son nuestras.