Cinco semanas de ataques antes de que llegara el aviso

La firma de seguridad watchTowr publicó un análisis técnico y una prueba de concepto para CVE-2026-8037 el 29 de junio de 2026, menos de un mes después de que Progress Software revelara el fallo el 4 de junio. Al día siguiente, el equipo de respuesta a amenazas de eSentire ya registraba intentos de explotación contra dispositivos Progress Kemp LoadMaster, un fallo de inyección de comandos no autenticado con una puntuación CVSS de 9.6.

Cuando la Agencia de Ciberseguridad e Infraestructura de Estados Unidos (CISA) añadió el fallo a su catálogo de Vulnerabilidades Explotadas Conocidas el 7 de agosto de 2026, la telemetría recopilada por eSentire y KEVIntel ya mostraba 792 intentos de explotación en 41 días, procedentes de 65 direcciones IP distintas en 18 países, incluidos Australia, China, Indonesia, Japón, Polonia y Estados Unidos. CISA dio a las agencias civiles federales estadounidenses hasta el 10 de agosto de 2026, apenas tres días, para parchear conforme a la Directiva Operativa Vinculante 26-04. Pero el vacío más relevante no fue ese plazo de tres días, sino las cerca de cinco semanas y media entre el primer ataque real y el momento en que la inclusión en el KEV obligó al tema a entrar en la agenda de la mayoría de los equipos de seguridad.

Por qué un balanceador de carga es un objetivo poco vigilado

Un balanceador de carga no es un sistema periférico. Normalmente termina o reenvía el tráfico de todas las aplicaciones expuestas al público que opera una organización, lo que le otorga una visibilidad de red y un control de enrutamiento que pocos otros dispositivos poseen. Comprometerlo da al atacante un punto de apoyo con visión sobre todo lo que hay detrás, mucho más allá de la caída de un único sitio web.

A pesar de esa exposición, los balanceadores de carga y dispositivos de red similares suelen parchearse con menos urgencia que las aplicaciones web a las que dan servicio. Los equipos de red e infraestructura a menudo los tratan como cableado que, una vez configurado, no debe tocarse fuera de una ventana de mantenimiento programada. Esa costumbre es precisamente lo que hace tan peligroso un fallo de ejecución remota de código no autenticado como CVE-2026-8037: el dispositivo más expuesto a internet suele ser el que menos probabilidades tiene de recibir un parche de emergencia.

El fallo en detalle: una función de saneamiento que no sanea

CVE-2026-8037 reside en una función llamada escape_quotes, cuya tarea es eliminar caracteres peligrosos de las entradas del usuario antes de que lleguen a un comando de shell. La función no lo hace por completo, y el fallo es accesible a través del endpoint de API /accessv2 siempre que la API de LoadMaster esté activada. El atacante no necesita ninguna credencial; una solicitud especialmente diseñada basta para que el dispositivo ejecute comandos arbitrarios.

Están afectadas la versión GA de LoadMaster 7.2.63.1 y anteriores, y la versión LTSF 7.2.54.17 y anteriores. Progress Software también confirmó el mismo defecto en las compilaciones de MOVEit WAF anteriores a GA 7.2.63.2. Ya existen versiones corregidas: LoadMaster GA 7.2.63.2 y LoadMaster LTSF 7.2.54.18. No hay sustituto para aplicar estos parches; desactivar la API donde no sea necesaria reduce la exposición, pero no cierra el fallo en los despliegues que dependen de ella.

Por qué se trata de un disparador NIS2, no solo de un ticket de parcheo

Para las organizaciones clasificadas como entidades esenciales o importantes bajo la directiva NIS2 de la UE, una vulnerabilidad de ejecución remota de código no autenticada en un dispositivo de infraestructura expuesto a internet es casi un ejemplo de manual de lo que las normas de notificación de incidentes de la directiva fueron escritas para cubrir. Un balanceador de carga situado en el borde de la red, accesible sin credenciales y con explotación activa confirmada, cumple prácticamente todos los criterios que reguladores como el INCIBE español utilizan para definir un incidente significativo: impacto en la confidencialidad, la integridad o la disponibilidad con potencial de causar un daño operativo o financiero considerable.

Eso tiene una consecuencia práctica más allá de parchear. Si un dispositivo LoadMaster dentro del alcance de NIS2 estaba expuesto a internet y ejecutaba una versión vulnerable durante la ventana de explotación, el plazo de notificación puede estar corriendo ya, con independencia de si se ha confirmado o no un compromiso. Esperar a tener certeza forense antes de evaluar las obligaciones de notificación es un error habitual y costoso.

Qué deben hacer los propietarios esta semana

Quien opere un dispositivo Kemp LoadMaster con GA 7.2.63.1 o anterior, o LTSF 7.2.54.17 o anterior, debe parchear de inmediato y priorizar las instancias expuestas a internet. No conviene esperar a una ventana de mantenimiento programada; la telemetría de explotación muestra que los atacantes ya están escaneando de forma amplia e indiscriminada, por lo que los dispositivos sin parchear se encuentran mediante barridos automatizados.

Más allá de esta corrección puntual, conviene aprovechar el vacío de cinco semanas entre la primera explotación y la inclusión en el KEV para revisar cómo sigue la organización los avisos de los fabricantes especificamente para dispositivos de red e infraestructura, una categoría que los programas de parcheo centrados en software de aplicación suelen pasar por alto. Un programa de gestión de parches que solo escala cuando algo aparece en una lista gubernamental de vulnerabilidades explotadas está, por definición, siempre por detrás de los atacantes que encontraron el fallo primero.

Leer a continuación: 45.601 fallos y solo 171 se están usando  |  Un edificio inutilizado cuesta más que un rescate