Contexto del incidente
El 2 de julio de 2026 la conversación sobre CVE-2026-8037 pasa de "vulnerabilidad crítica recién parcheada" a "explotación activa en Internet". La falla, descubierta por Syed Ibrahim Ahmed de TrendAI Research y coordinada por la Zero Day Initiative (ZDI-26-342), fue divulgada por Progress Software el 4 de junio con un parche disponible desde el mismo día. Tres semanas después, watchTowr Labs publicó un proof-of-concept funcional y, el 29 de junio, eSentire detectó los primeros intentos de explotación masivos contra appliances LoadMaster expuestos.
El NVD asignó a CVE-2026-8037 un puntaje CVSS v3.1 de 9.6 (Critical) con vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H: red atacable, baja complejidad, sin privilegios requeridos, sin interacción del usuario, impacto total en confidencialidad, integridad y disponibilidad. ZDI, por su parte, lo puntuó en 9.8 sobre la base de que la ejecución se realiza con privilegios de root sobre el sistema operativo subyacente. OpenCVE replica el 9.6 y, por ahora, no aparece en el catálogo KEV de CISA, aunque el patrón de exposición sugiere que eso puede cambiar en días.
El componente afectado no es un módulo menor: Progress Kemp LoadMaster es un balanceador de carga y Application Delivery Controller (ADC) muy extendido en entornos enterprise, donde cumple funciones de terminación TLS, WAF embebido, health-checking y distribución L4/L7. Cuando un dispositivo de borde con estas capacidades cae bajo control de un atacante, ese atacante no solo compromete al LoadMaster: gana una posición privilegiada para moverse hacia el interior de la red, interceptar tráfico de aplicaciones y capturar credenciales que circulan por la infraestructura perimetral.
La causa raíz es una combinación sutil de dos defectos en la función de sanitización escape_quotes(), que LoadMaster usa para limpiar valores antes de insertarlos en argumentos de shell entre comillas simples. La función llama a malloc() en lugar de calloc(), por lo que el buffer queda con datos residuales; y omite escribir el terminador NUL al final de la cadena escapada. Cuando el resultado se concatena con sprintf y se pasa a system() para construir el comando validuser, la lectura fuera de límites arrastra contenido del heap adyacente hacia la línea de comando final. Cuatro comillas simples en el campo apiuser generan exactamente 16 bytes de escape, suficiente para sobrescribir metadata del allocator y, con un poco de heap spraying, inyectar un fragmento de comando arbitrario. Lo más interesante: el atacante usa la propia rutina de sanitización del producto como vector, no inyecciones "clásicas" tipo ; rm -rf /.
El 4 de junio de 2026 Progress liberó parches en dos ramas: la rama GA quedó parcheada en v7.2.63.2 y la LTSF (Long-Term Support Fix) en v7.2.54.18. Estuvieron afectados todos los appliances con la API habilitada en versiones anteriores a v7.2.63.2 en la rama GA y anteriores a v7.2.54.18 en LTSF. Es importante notar que la API viene habilitada por defecto en muchos despliegues, sobre todo en appliances que se administran en forma remota.
Hay un segundo CVE que viaja en el mismo boletín de Progress: CVE-2026-33691, una evasión del WAF embebido mediante whitespace padding en nombres de archivo. Parchear CVE-2026-8037 sin tocar CVE-2026-33691 deja al WAF de LoadMaster inútil frente a cargas con padding, lo que en la práctica es equivalente a seguir expuesto a varios vectores de upload malicioso. Si administrás un cluster LoadMaster, validá que ambos parches estén aplicados en cada nodo antes de cerrar el ticket.
Un parche que arregla un agujero root pero deja vivo un bypass del WAF no es un parche, es un placebo.
¿Cómo proteger tu infraestructura?
1. Actualizá LoadMaster a v7.2.63.2 (GA) o v7.2.54.18 (LTSF) cuanto antes
El primer paso no es opcional. La combinación de pre-autenticación, ejecución como root y PoC público hace que esta vulnerabilidad sea explotable de forma masiva por atacantes con nivel técnico bajo. Desde la UI web de LoadMaster, navegá a System Configuration → System Maintenance → Upgrade y subí el firmware. Si estás en la rama LTSF, el binario v7.2.54.18 está disponible en el portal de soporte de Progress. Validá el hash SHA-256 publicado por Progress contra el archivo bajado para evitar downgrades maliciosos.
2. Deshabilitá la API de administración en interfaces públicas
Si por motivos operacionales no podés parchear de inmediato, deshabilitá la API REST de LoadMaster (/accessv2 es la ruta vulnerable) en cualquier interfaz reachable desde Internet. En la UI: System Configuration → Network Setup → API Settings y dejá la API solo en la VLAN de administración. Bloqueá el puerto 443 de la API en el firewall perimetral y filtrá por IP de origen a las IPs del jump host o de la VPN de management. Mientras el PoC esté público, exponer esta API a Internet es equivalente a entregar una consola root.
3. Implementá segmentación y monitoreo del tráfico East-West
El LoadMaster comprometido puede pivotar hacia los server farms que balancea. Si la red está plana, un shell en el LoadMaster se traduce en una shell en la base de datos o el ERP detrás. Asegurate de que la VLAN donde reside el LoadMaster no tenga rutas directas hacia segmentos de datos sensibles, y que el appliance no tenga credenciales privilegiadas (SSH keys, tokens de API) hacia los servidores de aplicación. Si las tiene, rotalas después de aplicar el parche: el atacante pudo haberlas capturado.
4. Detectá explotación con logs y comportamiento anómalo
Configurá alertas en tu SIEM para tres señales que dejó claras watchTowr: invocaciones sospechosas a validuser con payloads que contienen secuencias de comillas simples largas en apiuser, procesos hijos inesperados lanzados por el usuario del servicio LoadMaster (típicamente nobody o loadmaster), y conexiones outbound iniciadas por el appliance hacia destinos no documentados (un LoadMaster legítimo solo habla con sus backends y, eventualmente, con Progress para licenciamiento). El siguiente snippet de Suricata apunta a la firma HTTP más obvia:
alert http any any -> $LOADMASTER_MGMT 443 (msg:"Kemp LoadMaster CVE-2026-8037 escape_quotes heap-spray attempt";
flow:to_server,established;
http.uri; content:"/accessv2";
http.request_body; content:"apiuser"; nocase;
http.request_body; pcre:"/apiuser[^&]{0,256}'{4,}/";
classtype:attempted-admin; sid:2026803701; rev:1;)Indicadores de compromiso (IoC)
Los siguientes indicadores vienen de la telemetría que eSentire Threat Response Unit publicó el 30 de junio y del análisis de watchTowr Labs. Sirven para cazar intentos de explotación en logs de WAF, IDS o SIEM.
- IP atacante (eSentire TRU, 29-30 jun 2026):
192.42.116.58 - IP atacante (eSentire TRU):
192.42.116.105 - IP atacante (eSentire TRU):
146.70.139.154 - Endpoint vulnerable:
POST /accessv2(API REST de Kemp LoadMaster) - Campo malicioso en body JSON:
"apiuser"con 4+ comillas simples seguidas y payload adyacente de heap spray en otros parámetros - Versiones afectadas (sin parche): GA
< v7.2.63.2, LTSF< v7.2.54.18 - CVE companion (mismo advisory):
CVE-2026-33691(WAF bypass vía whitespace padding en filenames) - ID ZDI:
ZDI-26-342
Si ves tráfico desde cualquiera de las tres IPs hacia tu LoadMaster, asumí compromiso en curso: los intentos observados por eSentire terminaron en falla por timing, pero eso no significa que el próximo intento vaya a fallar. Aislá el appliance, capturá memoria si es posible, y revisá logs de procesos del sistema operativo del LoadMaster buscando shells inversos, curls anómalos o wget hacia destinos externos.
# Splunk SPL: shells lanzados por el servicio LoadMaster
index=linux host=loadmaster* user=nobody OR user=loadmaster
| eval cmd_lower=lower(cmd)
| where match(cmd_lower, "sh$|bash$|nc -|ncat|/dev/tcp/|wget |curl |python -c")
| stats count by host, _time, cmd_lower
| where count > 0🛡️ ¿Tu balanceador de carga es un punto de entrada o una línea de defensa?
Un LoadMaster sin parches hoy es un root shell esperando un curl. En IPSecureNetwork hacemos auditorías de appliances de borde (F5, Kemp, HAProxy, nginx) con foco en superficies de administración expuestas y CVEs recientes. Si tenés uno o varios LoadMaster en producción, te conviene un chequeo de firmware, segmentación y WAF embebido antes que el próximo CVE activo lo haga por vos.
SOLICITAR AUDITORÍA →