Cuando CISA avisó del LoadMaster, el parche llevaba 64 días publicado

El 7 de agosto CISA añadió CVE-2026-8037 a su catálogo de vulnerabilidades explotadas y puso fecha límite: el 10 de agosto. Tres días. Suena a urgencia máxima, y lo es. Pero el parche de Progress llevaba publicado desde el 4 de junio. Sesenta y cuatro días. Si tu proceso de parcheo se dispara cuando una vulnerabilidad entra en el KEV, acabas de descubrir que llevas dos meses sin saber que ibas tarde.

El aparato afectado es un Progress Kemp LoadMaster, un balanceador. Es decir: la caja que está delante de tus aplicaciones, la que termina el TLS, la que ve todo el tráfico antes que nadie y la que casi nunca aparece en el inventario de parcheo porque «es de red». Este post no va tanto del LoadMaster como del criterio con el que decides qué parchear primero. Es el caso que mejor lo enseña este mes.

Los cuatro relojes

Toda vulnerabilidad de este tipo tiene cuatro fechas, y casi nadie las distingue:

El reloj que importa es el segundo. Entre el boletín y el PoC público tienes una ventana en la que eres el único que sabe dónde está el fallo; a partir del PoC, cualquiera con ganas puede reproducirlo. Veinticinco días es una ventana generosa, y aun así es fácil quemarla entera esperando la ventana de mantenimiento del mes que viene.

Qué falla exactamente

El NVD lo describe como inyección de comandos del sistema operativo en la API de los productos ADC de Progress, explotable sin autenticación, mediante entrada sin sanear en varios endpoints de comando. La clasificación es CWE-77. Traducido: alguien que llega a la API puede ejecutar órdenes en el aparato.

El detalle interesante lo puso watchTowr al abrir el binario: el fallo está en escape_quotes(), la función cuyo trabajo es precisamente evitar este tipo de inyección. Reserva un buffer con malloc() —memoria sin inicializar— y no escribe el terminador nulo al final de la cadena escapada. El resultado es una lectura fuera de límites que se cuela en trozos de memoria liberada contigua, donde el atacante ya ha colocado lo suyo. El endpoint de entrada es /accessv2, y el parche se limita a cambiar ese malloc() por calloc() y a terminar la cadena como es debido.

El 9,6 y el 9,8 no miden lo mismo

Aquí hay un detalle que merece más atención de la que recibe. En la ficha del NVD conviven dos puntuaciones CVSS 3.1 para el mismo fallo:

Dos décimas de diferencia, y sin embargo los vectores discrepan en dos ejes distintos. Progress dice AV:A: red adyacente, es decir, asume que a la API de gestión de tu balanceador no se llega desde Internet. El NVD dice AV:N: red, se llega y punto. Por otro lado Progress marca S:C (el fallo se escapa del componente comprometido) y el NVD marca S:U. Que los dos números acaben casi pegados es pura casualidad aritmética: se compensan dos desacuerdos de fondo.

La consecuencia práctica es la que nos interesa: la única persona que puede resolver ese desacuerdo eres tú, porque depende de si esa API asoma o no a Internet en tu instalación. Un CVSS mide el riesgo suponiendo una arquitectura, y la que supone rara vez es la tuya. Priorizar una lista de vulnerabilidades sin el inventario de qué hay expuesto es ordenar por un número que no habla de tu instalación. Saber qué tienes y por dónde se llega ocupa la mitad del trabajo de una auditoría técnica y de procesos.

792 intentos, 65 IPs, 18 países

La telemetría que ha circulado con la entrada en el KEV, atribuida a KEVIntel y recogida por The Hacker News, habla de 792 intentos de explotación en 41 días desde 65 direcciones IP únicas repartidas en 18 países, con la última actividad registrada el 4 de agosto. Cuarenta y un días hacia atrás desde el aviso caen en el 27 de junio: la ventana arranca en la misma semana en que se publicó la prueba de concepto, con un par de días de margen según dónde cierres el contador. Y eSentire, que vio los primeros intentos el 29, pone la misma fecha desde otro sitio.

Conviene ser honesto con lo que ese número no dice. 792 intentos en cuarenta días son escaneo oportunista, muy lejos de una campaña organizada. eSentire fue literal en su aviso: «en los casos observados por eSentire, la explotación no tuvo éxito y, por tanto, no se observó actividad posterior al compromiso». Y la propia ficha del KEV marca el uso conocido en campañas de ransomware como «Unknown». Nada de esto invita a relajarse. El escaneo oportunista de un fallo con exploit público es el patrón que precede a las cosas serias; los operadores de ransomware compran acceso a quien ya barrió Internet por ellos.

El KEV llega tarde por diseño, y está bien que así sea

Que quede claro: esto no es una crítica a CISA. El catálogo hace exactamente lo que promete —listar vulnerabilidades con evidencia confirmada de explotación— y confirmar cuesta tiempo. En la versión del catálogo del 10 de agosto hay 1.662 entradas; es una de las mejores herramientas gratuitas que existen para acotar el universo de CVEs a lo que de verdad se está usando.

El fallo está en usarlo como despertador. El KEV es un acuse de recibo, no una alarma: te confirma que algo ya lleva un rato pasando. Si es tu única señal de entrada, tu proceso hereda su latencia entera, y encima te llega con un día hábil para ejecutarlo. A cuenta del Patch Tuesday de julio y sus 622 parches ya dijimos que información sobra; lo que escasea es un orden propio para leerla.

Cómo ordenamos nosotros la cola

Ordenamos la cola con cuatro preguntas. Si las cuatro respuestas son «sí», eso se parchea fuera de ventana, hoy, y se avisa a quien haga falta:

CVE-2026-8037 respondía «sí» a las cuatro el 29 de junio. No hacía falta esperar al 7 de agosto para saberlo, y no hacía falta ninguna herramienta de pago: hacía falta un inventario que dijera «tenemos dos LoadMaster y su API de gestión está en tal sitio».

Si llevabas cuarenta días expuesto, parchear no es terminar

Hay un matiz en la propia instrucción de CISA que se lee por encima y que dice mucho. Junto a la orden de aplicar las mitigaciones del fabricante, la ficha remite a dos cosas en paralelo: la guía de la directiva BOD 26-04, «Prioritizing Security Updates Based on Risk», y los Forensics Triage Requirements de CISA. Traducido: actualiza, y después ve a mirar si ya habían entrado.

Ya desarrollamos ese argumento con FortiOS y los enlaces simbólicos que sobrevivían a la actualización, así que no lo repetimos aquí: parchear no es limpiar. Lo que sí toca añadir es el detalle incómodo de este caso concreto. Un aparato que ha pasado cuarenta días con un exploit público apuntándole no se da por bueno subiendo la versión y cerrando el ticket, y sin embargo un balanceador rara vez guarda los logs que harían falta para responder a la única pregunta que importa. Si no puedes reconstruir qué pasó en /accessv2 desde el 29 de junio, esa carencia es tu primer hallazgo.

En corto

El KEV es un catálogo excelente y una pésima señal de arranque. Cuando CISA te avisa, el fabricante lleva semanas o meses con el parche fuera y el exploit lleva un rato circulando. El reloj que ordena bien tu cola es el día en que aparece el PoC público, cruzado con el inventario que te dice si eso te toca a ti. Lo primero te lo dan gratis los que investigan. Lo segundo tienes que tenerlo hecho antes, porque el día del aviso ya no da tiempo a levantarlo.

Fuentes (verificadas): ficha del CVE, descripción y ambas puntuaciones CVSS 3.1 — NVD; fecha de alta (7-ago-2026), plazo (10-ago-2026), acción requerida y referencia a BOD 26-04 — catálogo KEV de CISA, versión 2026.08.10; análisis técnico, escape_quotes(), /accessv2, versiones y PoC (29-jun-2026) — watchTowr Labs; boletín del fabricante y versiones corregidas — Progress; aviso y cita literal sobre explotación sin éxito (30-jun-2026) — eSentire; telemetría de 792 intentos atribuida a KEVIntel — The Hacker News. Imagen de portada: «Racks Amravati Data Center», PiDatacenters, CC BY-SA 4.0, vía Wikimedia Commons.