Vulnerabilidad crítica en Progress LoadMaster permite ejecución de comandos como root sin autenticación (CVE-2026-8037)

Progress Kemp LoadMaster tiene una vulnerabilidad crítica que permite a un atacante no autenticado ejecutar comandos arbitrarios como root enviando una petición especialmente construida a su API; el fallo figura como CVE-2026-8037 y recibió una puntuación CVSS alta (9.8) según la Zero Day Initiative. Progress publicó un aviso de seguridad a inicios de junio y ya hay versiones parcheadas; sin embargo, la existencia de una prueba de concepto pública y el hecho de que el dispositivo actúe como borde de red convierten este problema en una prioridad para cualquier organización que utilice LoadMaster con la API activada.

El origen técnico del fallo es asombrosamente sencillo y esclarecedor desde el punto de vista de operaciones seguras: una función encargada de "escapar" comillas simples antes de pasar la entrada a un comando de shell no inicializaba correctamente su buffer y tampoco añadía un terminador nulo al final de la cadena resultante. Esa ausencia permite que la lectura de la cadena se desborde en memoria y alcance datos adyacentes controlables por el atacante; enviando decenas de claves JSON adicionales en la misma petición el adversario puede situar allí la carga que será interpretada y ejecutada por la shell. El vector concreto es el endpoint /accessv2, que valida credenciales de API, y no requiere credenciales válidas para lograr la ejecución, que se produce con permisos de root.

Las versiones afectadas son LoadMaster GA v7.2.63.1 y anteriores, y LTSF v7.2.54.17 y anteriores, siempre que la API esté habilitada; las versiones corregidas son GA v7.2.63.2 y LTSF v7.2.54.18. El parche es pequeño y directo: cambiar una llamada de asignación de memoria por otra que inicializa a cero el buffer y añadir el terminador nulo al final de la cadena escapada; dos líneas que cierran la puerta a la explotación. El descubrimiento fue reportado a través de Zero Day Initiative y posteriormente analizado públicamente por investigadores externos, que desmenuzaron la cadena de explotación y publicaron una prueba de concepto, lo que hace urgente aplicar la actualización.

Las implicaciones operativas son claras. Un balanceador y controlador de entrega de aplicaciones situado en el perímetro es un objetivo de alto valor: comprometerlo permite interceptar tráfico, desplegar puertas traseras, mover lateralmente por la red interna y potencialmente desplegar cargas destructivas o de ransomware con facilidad. Además, Progress no es ajeno a incidentes de alto impacto (la plataforma MOVEit fue explotada masivamente en 2023), por lo que las organizaciones deben considerar tanto la probabilidad como el impacto en sus estrategias de mitigación.

Si su entorno utiliza LoadMaster con la API habilitada, las acciones prioritarias que deberían ejecutarse de inmediato son parchear a las versiones corregidas y evaluar si la API necesita estar expuesta. Si no puede aplicar el parche en seguida, mitigue reduciendo la superficie de ataque: deshabilite la API si no es imprescindible, restrinja el acceso al endpoint desde redes de gestión confiables, implemente reglas de firewall y listas de control de acceso a nivel de red para limitar quién puede comunicarse con el dispositivo, y utilice segmentación para evitar que una máquina comprometida alcance sistemas críticos. Tras actualizar, verifique la versión instalada y compruebe firmas o checksums de los binarios si Progress los proporciona.

No basta con sólo parchear. Realice búsquedas activas de posibles indicios de compromiso: inspeccione registros de acceso y del sistema en momentos críticos, busque procesos o comandos inusuales ejecutados por root, revisiones en crontabs o cuentas de usuario nuevas, tráfico saliente sospechoso y cambios en la configuración de la appliance. Aísle cualquier instancia con anomalías y preserve evidencia para análisis forense. Considere también rotar credenciales y certificados que el balanceador administre o almacene, por si la explotación previa hubiese comprometido material sensible.

Finalmente, reflexione sobre la necesidad de que la API sea accesible desde redes no controladas: si la API no necesita estar expuesta públicamente, no debería estarlo. Audite los servicios en el perímetro, aplique el principio de menor privilegio y mantenga un programa de parches ágil. Para más información sobre coordinaciones de divulgación y catálogos de vulnerabilidades explotadas, consulte las páginas de la Zero Day Initiative y del catálogo de vulnerabilidades conocidas explotadas por actores reales de CISA: ZDI advisories y CISA Known Exploited Vulnerabilities catalog. Las recomendaciones del proveedor y los avisos oficiales de seguridad de Progress están disponibles en su portal de seguridad: Progress Security. Parchee ahora y, después, pregúntese seriamente si la API debe seguir siendo accesible desde redes que no controle.