Cinco semanas de ataques antes do alerta

A empresa de segurança watchTowr publicou uma análise técnica e uma prova de conceito para a CVE-2026-8037 a 29 de junho de 2026, menos de um mês depois de a Progress Software ter revelado a falha a 4 de junho. Já no dia seguinte, a equipa de resposta a ameaças da eSentire registava tentativas de exploração contra equipamentos Progress Kemp LoadMaster, uma falha de injeção de comandos não autenticada com uma pontuação CVSS de 9.6.

Quando a agência norte-americana CISA adicionou a falha ao seu catálogo de Vulnerabilidades Exploradas Conhecidas a 7 de agosto de 2026, a telemetria compilada pela eSentire e pela KEVIntel já mostrava 792 tentativas de exploração em 41 dias, provenientes de 65 endereços IP distintos em 18 países, incluindo Austrália, China, Indonésia, Japão, Polónia e Estados Unidos. A CISA deu as agências civis federais norte-americanas até 10 de agosto de 2026, apenas três dias, para aplicarem a correção ao abrigo da Binding Operational Directive 26-04. Mas o intervalo mais relevante não foi esse prazo de três dias, e sim as cerca de cinco semanas e meia entre o primeiro ataque real e o momento em que a inclusão no KEV obrigou o tema a entrar na agenda da maioria das equipas de segurança.

Porque é que um balanceador de carga é um alvo pouco vigiado

Um balanceador de carga não é um sistema periférico. Normalmente termina ou reencaminha o tráfego de praticamente todas as aplicações expostas ao público que uma organização opera, o que lhe confere uma visibilidade de rede e um controlo de encaminhamento que poucos outros equipamentos possuem. Comprometê-lo dá ao atacante um ponto de apoio com visão sobre tudo o que está por trás, muito além de derrubar um único site.

Apesar desta exposição, os balanceadores de carga e equipamentos de rede semelhantes costumam ser corrigidos a um ritmo mais lento do que as aplicações web que protegem. As equipas de rede e infraestrutura tratam-nos muitas vezes como canalização que, uma vez configurada, não deve ser tocada fora de uma janela de manutenção planeada. É precisamente esse hábito que torna uma falha de execução remota de código não autenticada como a CVE-2026-8037 tão perigosa: o equipamento mais exposto à internet é frequentemente aquele com menor probabilidade de receber uma correção de emergência.

A falha em detalhe: uma função de saneamento que não saneia

A CVE-2026-8037 reside numa função chamada escape_quotes, cuja tarefa é remover caracteres perigosos das entradas do utilizador antes de estas chegarem a um comando de shell. A função não o faz por completo, e a falha é acessível através do ponto de API /accessv2 sempre que a API do LoadMaster está ativada. Um atacante não precisa de quaisquer credenciais; um pedido especialmente construído basta para que o equipamento execute comandos arbitrários.

São afetadas a versão GA do LoadMaster 7.2.63.1 e anteriores, e a versão LTSF 7.2.54.17 e anteriores. A Progress Software confirmou também o mesmo defeito subjacente nas compilações do MOVEit WAF anteriores a GA 7.2.63.2. Já existem versões corrigidas: LoadMaster GA 7.2.63.2 e LoadMaster LTSF 7.2.54.18. Não há substituto à aplicação destas correções; desativar a API onde não é necessária reduz a exposição, mas não fecha a falha nas implementações que dela dependem.

Porque é que isto é um gatilho NIS2, não apenas um ticket de correção

Para organizações classificadas como entidades essenciais ou importantes ao abrigo da diretiva NIS2 da UE, uma vulnerabilidade de execução remota de código não autenticada num equipamento de infraestrutura exposto à internet é praticamente um exemplo de manual daquilo para que as regras de notificação de incidentes da diretiva foram escritas. Um balanceador de carga situado na periferia da rede, acessível sem credenciais e com exploração ativa confirmada, cumpre praticamente todos os critérios que reguladores como o CNCS português utilizam para definir um incidente significativo: impacto na confidencialidade, integridade ou disponibilidade com potencial para causar dano operacional ou financeiro considerável.

Isto tem uma consequência prática para além da correção. Se um equipamento LoadMaster no âmbito do NIS2 estava exposto à internet e a executar uma versão vulnerável durante a janela de exploração, o prazo de notificação pode já estar a decorrer, independentemente de um comprometimento ter sido confirmado ou não. Esperar por certeza forense antes de avaliar as obrigações de notificação é um erro comum e dispendioso.

O que os proprietários devem fazer esta semana

Quem opera um equipamento Kemp LoadMaster com GA 7.2.63.1 ou anterior, ou LTSF 7.2.54.17 ou anterior, deve corrigi-lo de imediato e dar prioridade às instâncias expostas à internet. Não convém esperar por uma janela de manutenção planeada; a telemetria de exploração mostra que os atacantes já estão a fazer varrimentos amplos e indiscriminados, pelo que os equipamentos sem correção são encontrados através de varrimentos automatizados.

Para além desta correção pontual, vale a pena aproveitar o intervalo de cinco semanas entre a primeira exploração e a inclusão no KEV como motivo para rever como a organização acompanha os avisos dos fabricantes especificamente para equipamentos de rede e infraestrutura, uma categoria que os programas de correção centrados em software de aplicação muitas vezes negligenciam. Um programa de gestão de correções que só escala quando algo surge numa lista governamental de vulnerabilidades exploradas está, por definição, sempre atrás dos atacantes que encontraram a falha primeiro.

Leia a seguir: 45.601 falhas e só 171 estão a ser usadas  |  Um edifício inutilizado custa mais do que um resgate