Cinque settimane di attacchi prima dell'allarme

La società di sicurezza watchTowr ha pubblicato un'analisi tecnica e un proof-of-concept per CVE-2026-8037 il 29 giugno 2026, meno di un mese dopo che Progress Software aveva reso pubblica la falla il 4 giugno. Già il giorno successivo, il team di threat response di eSentire registrava i primi tentativi di sfruttamento contro le appliance Progress Kemp LoadMaster, una falla di command injection non autenticata con un punteggio CVSS di 9.6.

Quando l'agenzia statunitense CISA ha aggiunto la falla al proprio catalogo delle vulnerabilità sfruttate note il 7 agosto 2026, la telemetria raccolta da eSentire e KEVIntel mostrava già 792 tentativi di sfruttamento in 41 giorni, provenienti da 65 indirizzi IP distinti in 18 paesi, tra cui Australia, Cina, Indonesia, Giappone, Polonia e Stati Uniti. CISA ha concesso alle agenzie civili federali statunitensi tempo fino al 10 agosto 2026, appena tre giorni, per applicare la patch secondo la Binding Operational Directive 26-04. Il divario più rilevante, tuttavia, non è stato quel termine di tre giorni, ma le circa cinque settimane e mezzo trascorse tra il primo attacco reale e il momento in cui l'inserimento nel KEV ha imposto il tema all'agenda della maggior parte dei team di sicurezza.

Perché un load balancer è un bersaglio poco sorvegliato

Un load balancer non è un sistema periferico. Di norma termina o inoltra il traffico di ogni applicazione esposta al pubblico che un'organizzazione gestisce, il che gli conferisce una visibilità di rete e un controllo dell'instradamento che pochi altri dispositivi possiedono. Comprometterlo da all'aggressore un punto d'appoggio con visuale su tutto ciò che sta dietro, ben oltre la messa fuori uso di un singolo sito web.

Nonostante questa esposizione, i load balancer e i dispositivi di rete simili vengono abitualmente aggiornati con un ritmo più lento rispetto alle applicazioni web che proteggono. I team di rete e infrastruttura spesso li trattano come impianti che, una volta configurati, non vanno toccati al di fuori di una finestra di manutenzione pianificata. Proprio questa abitudine rende così pericolosa una falla di esecuzione di codice remoto non autenticata come CVE-2026-8037: il dispositivo più esposto a internet è spesso quello con minori probabilità di ricevere una patch d'emergenza.

La falla nel dettaglio: una funzione di sanificazione che non sanifica

CVE-2026-8037 risiede in una funzione chiamata escape_quotes, il cui compito è rimuovere i caratteri pericolosi dagli input dell'utente prima che raggiungano un comando di shell. La funzione non lo fa completamente, e la falla è raggiungibile tramite l'endpoint API /accessv2 ogni volta che l'API di LoadMaster è abilitata. Un aggressore non ha bisogno di alcuna credenziale; una richiesta appositamente costruita basta a far eseguire all'appliance comandi arbitrari.

Sono interessate la versione GA di LoadMaster 7.2.63.1 e precedenti, e la versione LTSF 7.2.54.17 e precedenti. Progress Software ha inoltre confermato lo stesso difetto di fondo nelle build di MOVEit WAF precedenti alla GA 7.2.63.2. Sono disponibili versioni corrette: LoadMaster GA 7.2.63.2 e LoadMaster LTSF 7.2.54.18. Non esiste un sostituto all'applicazione di queste patch; disattivare l'API dove non è necessaria riduce l'esposizione ma non chiude la falla per le implementazioni che ne dipendono.

Perché è un innesco NIS2, non solo un ticket da patchare

Per le organizzazioni classificate come entità essenziali o importanti ai sensi della direttiva NIS2 dell'UE, una vulnerabilità di esecuzione di codice remoto non autenticata su un'appliance infrastrutturale esposta a internet è quasi un esempio da manuale di ciò per cui sono state scritte le regole di segnalazione degli incidenti della direttiva. Un load balancer posto al confine della rete, raggiungibile senza credenziali e con sfruttamento attivo confermato, soddisfa praticamente ogni criterio che regolatori come l'ACN italiana usano per definire un incidente significativo: un impatto su riservatezza, integrità o disponibilità con il potenziale di causare un danno operativo o finanziario considerevole.

Questo ha una conseguenza pratica che va oltre il patching. Se un'appliance LoadMaster nell'ambito di applicazione di NIS2 era esposta a internet e utilizzava una versione vulnerabile durante la finestra di sfruttamento, i termini per la segnalazione potrebbero già essere in corso, indipendentemente dal fatto che una compromissione sia stata confermata o meno. Attendere la certezza forense prima di valutare gli obblighi di segnalazione è un errore comune e costoso.

Cosa devono fare i proprietari questa settimana

Chi gestisce un'appliance Kemp LoadMaster con GA 7.2.63.1 o precedente, oppure LTSF 7.2.54.17 o precedente, deve applicare la patch immediatamente e dare priorità alle istanze esposte a internet. Non conviene attendere una finestra di manutenzione pianificata; la telemetria di sfruttamento mostra che gli aggressori stanno già scansionando in modo ampio e indiscriminato, quindi le appliance non aggiornate vengono trovate tramite scansioni automatizzate.

Oltre a questa correzione puntuale, vale la pena usare il divario di cinque settimane tra il primo sfruttamento e l'inserimento nel KEV come spunto per rivedere come l'organizzazione monitora gli avvisi dei fornitori specificamente per i dispositivi di rete e infrastruttura, una categoria che i programmi di patching costruiti attorno al software applicativo spesso trascurano. Un programma di gestione delle patch che scala solo quando qualcosa compare in un elenco governativo di vulnerabilità sfruttate è, per definizione, sempre in ritardo rispetto agli aggressori che hanno trovato la falla per primi.

Da leggere ora: 45.601 falle, solo 171 vengono davvero usate  |  Un edificio inutilizzabile costa più di un riscatto