Progress LoadMaster CVE-2026-8037: RCE pre-auth nel load balancer

Un load balancer è l'unico apparato del perimetro che vede in chiaro tutto ciò che gli sta dietro. Termina il TLS, riscrive le richieste, custodisce i certificati e instrada il traffico verso le parti di rete che non si aspettavano di essere raggiungibili dall'esterno. CVE-2026-8037 è una command injection non autenticata in Progress Kemp LoadMaster — uno degli application delivery controller più diffusi in azienda — che consegna a un attaccante l'esecuzione di codice proprio su quell'apparato, senza bisogno di credenziali. Progress ha rilasciato la correzione a giugno. Il 7 agosto il bug era già nel catalogo Known Exploited Vulnerabilities della CISA, con 792 tentativi di exploit alle spalle. Quella finestra di due mesi è tutta la storia.

Cosa è davvero CVE-2026-8037

La descrizione in una riga somiglia a cento altri bollettini: "command injection nell'API che consente a un attaccante non autenticato di eseguire comandi arbitrari". NVD la classifica CVSS 9.8 (AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:H); Progress e CISA la riportano a 9.6. In entrambi i casi è una remote code execution pre-auth su un apparato esposto in Internet, la peggiore combinazione di proprietà che un bug possa avere.

Il meccanismo è più interessante del titolo. Secondo watchTowr Labs, che ha analizzato la patch a ritroso, il difetto vive in una funzione ausiliaria, escape_quotes(), raggiungibile tramite l'endpoint non autenticato /accessv2 che legge apiuser e apipass da un corpo JSON. Si sommano due errori:

• La funzione alloca il buffer di output con malloc() invece di calloc(), quindi parte pieno di contenuto heap non inizializzato — metadati dell'allocatore, resti di chunk liberati.
• Non scrive mai il terminatore nullo dopo l'output esitato.

Ogni apice singolo nell'input si espande in quattro byte (' diventa \'\'). Passando apiuser: "''''" si producono sedici byte di output esitato senza alcun terminatore nullo. Quando l'apparato costruisce poi la stringa di comando con __sprintf_chk(), legge oltre il buffer — attraverso l'heap circostante — finché non trova un byte nullo che ormai non c'è più. L'attaccante che ha già "spruzzato" un payload di comando nei valori JSON adiacenti se lo ritrova letto dentro la stringa di comando ed eseguito come root.

Chi valuta: "È un problema di quoting. Il nostro WAF filtra i metacaratteri di shell, quindi siamo coperti."

Realtà: Il punto di injection non è un metacarattere da mettere in blocklist. È un terminatore nullo mancante che lascia il parser camminare in memoria che controlli tu. I byte malevoli arrivano come normalissimi valori di campo API; non c'è nessun ; o | che un WAF possa intercettare. L'exploit è un layout dell'heap, non una firma di payload.

Ecco perché il bug è pericoloso ben oltre il suo punteggio CVSS. Sconfigge i due controlli su cui la maggior parte dei team si appoggia per gli apparati di frontiera — "serve l'autenticazione" (non serve) e "il nostro WAF filtra le injection" (questa non è l'injection che il tuo WAF modella).

Perché un load balancer è il posto peggiore in cui perdere

Gli application delivery controller stanno in un collo di bottiglia strutturale. Comprometterne uno significa ereditarne la posizione, non solo la shell:

• Terminazione TLS. L'apparato custodisce le chiavi private dei siti che serve. Root sulla macchina è root sui certificati.
• Raggiungibilità del backend. I load balancer, per progetto, sono autorizzati a parlare con i servizi interni che nessun altro può raggiungere. Una shell lì è un pivot già autorizzato verso il livello applicativo.
• Esposizione delle credenziali. Account per gli health check, token API e credenziali dei servizi di backend sono configurati sull'apparato in chiaro o quasi.
• Un punto cieco nel monitoraggio. Nessuno mette un EDR su un LoadMaster. L'unico host in posizione di vedere tutto il traffico è di solito l'unico host senza telemetria endpoint propria.

Questa genealogia non è nuova. La knowledge base di Zero Hunt segnala la stessa classe di bug da anni — la command injection nel Barracuda Load Balancer (CVE-2017-6320), le injection sui parametri di certificato dello Zen Load Balancer (CVE-2019-7301) — tutte root-via-metacaratteri-di-shell sull'apparato che sta davanti a tutto. CVE-2026-8037 è la voce 2026 di una lunga lista, distinta solo dall'essere pre-autenticazione.

Dalla patch di giugno alla KEV di agosto: la cronologia

La parte scomoda di questa storia è la cronologia. La correzione è esistita per settimane mentre lo sfruttamento cresceva.

Data	Evento
Giugno 2026	Progress rilascia le build corrette (GA 7.2.63.2, LTSF 7.2.54.18) e il bollettino di sicurezza
~29 giugno 2026	Primi tentativi di sfruttamento osservati
Luglio 2026	eSentire segnala sfruttamento attivo ma "in gran parte senza successo"
4 agosto 2026	Ultima attività registrata nella finestra di telemetria di eSentire
7 agosto 2026	CISA aggiunge CVE-2026-8037 al catalogo KEV
10 agosto 2026	Scadenza di remediation federale ai sensi della Binding Operational Directive 26-04

In quella finestra eSentire ha registrato 792 tentativi di sfruttamento da 65 indirizzi IP distinti in 18 paesi — tra cui Australia, Cina, Indonesia, Giappone, Polonia e Stati Uniti. La nota "in gran parte senza successo" conta: significa che gli attaccanti stavano spruzzando l'exploit su bersagli non aggiornati mancandoli quasi sempre, che è esattamente l'aspetto di una campagna di scansione di massa contro un CVE vecchio di due mesi, prima che qualcuno metta a punto l'heap spray. "In gran parte senza successo" è uno stato, non una garanzia.

La scadenza federale di tre giorni (dal 7 al 10 agosto) va letta con attenzione. Con la BOD 26-04, la CISA ha sostituito la vecchia regola KEV piatta a 14 giorni con fasce basate sul rischio; una RCE pre-auth su un apparato di frontiera ricade nella fascia con l'orologio più corto. Se la tua organizzazione segue gli obblighi NIS2 o DORA, quella suddivisione in fasce è lo standard di riferimento europeo che sta emergendo per definire "quanto è abbastanza veloce", e per questa classe di esposizione la risposta ora è tre giorni.

Remediation

Progress evidenzia una condizione non ovvia: lo sfruttamento colpisce l'API, quindi ciò che un attaccante cerca è un apparato con l'API REST di LoadMaster abilitata e raggiungibile. Questo definisce sia la verifica dell'esposizione sia i controlli compensativi.

1. Sono interessato?

Verifica la versione del firmware in esecuzione dall'interfaccia LoadMaster (System Configuration → Update Software) o via SSH:

# Sull'apparato
cat /etc/version    # oppure controlla "Firmware Version" nel banner della WUI

Sei vulnerabile se esegui:

• LoadMaster GA 7.2.63.1 o precedente
• LoadMaster LTSF 7.2.54.17 o precedente

Lo stesso percorso di codice interessa anche le build ECS Connection Manager, Connection Manager for ObjectScale e MOVEit WAF derivate da LoadMaster. Poi conferma l'esposizione: l'interfaccia di management/API è raggiungibile da reti non fidate?

# Da un punto di osservazione esterno: /accessv2 è raggiungibile?
curl -sk -o /dev/null -w "%{http_code}\n" https://<ip-mgmt-lb>/accessv2

Qualsiasi risposta diversa da un rifiuto di connessione significa che l'endpoint pre-auth è raggiungibile e l'apparato va trattato come esposto.

2. Patch — versioni corrette esatte

Aggiorna alle build rilasciate da Progress a giugno:

• LoadMaster GA → 7.2.63.2 o successiva
• LoadMaster LTSF → 7.2.54.18 o successiva

Applica le build corrette corrispondenti per ECS Connection Manager, Connection Manager for ObjectScale e MOVEit WAF dal bollettino di sicurezza Progress. La patch è l'unica correzione completa; i controlli sotto guadagnano tempo, non sicurezza.

3. Non puoi applicare la patch subito? Controlli compensativi

• Togli l'API e l'interfaccia di management da Internet. Vincola l'amministrazione di LoadMaster a una VLAN di management dedicata o limita /accessv2 a una allowlist di IP amministrativi. Un exploit pre-auth contro un endpoint che nessun attaccante può raggiungere è un non-evento.
• Metti il piano di management dietro una VPN o un bastion. Non esporre direttamente l'amministrazione dell'apparato; richiedi prima un salto di rete autenticato.
• Applica rate-limit e alert su /accessv2. Raffiche di POST verso quel percorso da molti IP sorgente sono la firma della campagna — 65 IP sono uno spray, non una sonda mirata.

4. Caccia alla compromissione

Il mapping su MITRE ATT&CK è pulito. Tratta l'apparato come potenzialmente violato se è stato esposto in Internet e non aggiornato in qualsiasi momento da fine giugno.

• T1190 (Exploit Public-Facing Application): rivedi i log del load balancer e degli upstream cercando POST verso /accessv2 con valori apiuser/apipass anomalmente lunghi o pieni di apici. eSentire ha indicato 192.42.116.58, 192.42.116.105 e 146.70.139.154 come IP sorgente — cercali, ma non considerare la lista esaustiva.
• T1059 (Command and Scripting Interpreter): cerca processi shell generati dal servizio web/API dell'apparato — qualsiasi cosa che il normale funzionamento del load balancer non avvierebbe mai.
• T1505.003 (Web Shell): ispeziona le directory web scrivibili dall'apparato per file nuovi o modificati. Le librerie di regole di detection (per esempio la regola pubblica Sigma "Webshell Detection With Command Line Keywords") si basano su processi interprete che invocano comandi di ricognizione come whoami, id e ipconfig da un contesto web.
• T1071 / anomalie in uscita: un load balancer storicamente riceve soltanto connessioni. Nuove sessioni in uscita dall'apparato verso ASN sconosciuti — una reverse shell che chiama casa — sono uno dei segnali a più alta affidabilità disponibili, proprio perché questo host non ha alcun motivo legittimo per iniziarle.

5. Eradica e verifica

• Rimuovi web shell, voci di cron o binari modificati trovati; su un apparato embedded, dopo una compromissione confermata, la via più pulita è wipe e ricostruzione da un'immagine nota-buona, quindi patch prima di rimetterlo in servizio.
• Ruota ogni segreto che l'apparato ha toccato: le chiavi private TLS dei siti serviti (root sulla macchina implica chiavi da considerare divulgate), le credenziali di backend e degli health check, e qualunque token API configurato su di esso.
• Riesegui la verifica dell'esposizione del passo 1 per confermare che l'API non sia più raggiungibile da reti non fidate, e conferma che la versione in esecuzione sia una build corretta — un impianto sopravvissuto può anche falsificare un banner "patchato", quindi verifica anche dall'esterno, non solo sull'apparato.

Dove il testing continuo cambia i conti

Ogni numero concreto di questo articolo indica lo stesso divario: la correzione è arrivata a giugno, lo sfruttamento è corso per luglio, e la voce KEV è atterrata ad agosto. Nulla era nascosto. Gli apparati vulnerabili erano raggiungibili e la patch era disponibile per tutto il tempo. Mancava qualcosa che chiedesse di continuo "il nostro LoadMaster è ancora raggiungibile e ancora sfruttabile, oggi?" tra la valutazione trimestrale e l'incidente.

Quella domanda è ciò a cui il motore generativo a 10 agenti di Zero Hunt esiste per rispondere. Invece di prelevare un exploit statico da un database, l'agente Exploit scrive una prova per il bersaglio specifico — l'apparato e il firmware che ha davanti — lo stesso ragionamento che watchTowr ha applicato a mano, eseguito sul tuo perimetro secondo pianificazione e rilanciato in automatico nell'ora in cui un nuovo apparato compare. Ogni skill di exploit è validata nell'AI Gym prima di toccare la produzione, e ogni finding è firmato ECDSA per la catena di prove — così "il LoadMaster è stato aggiornato in questa data" è evidenza, non un ricordo. Contro l'orologio di tre giorni della BOD 26-04, un'evidenza che puoi produrre a richiesta è la differenza tra un finding chiuso e uno aperto.

E poiché un load balancer compromesso è più una posizione furtiva che rumorosa, il modello di AI Traffic Analysis copre l'altra metà. Le sue quattro teste di inferenza girano sulla GPU dell'appliance a velocità di rete, in attesa esattamente del segnale descritto al passo 4: un dispositivo che ha sempre e solo accettato connessioni che improvvisamente apre una sessione in uscita verso un ASN mai visto. È la reverse shell che lascia il load balancer — colta mentre accade, non nella revisione dei log del mattino dopo. Per il quadro più ampio degli apparati di frontiera che restano sfruttabili dopo che il vendor ha rilasciato la correzione, vedi la nostra analisi di CitrixBleed 3 e della RCE HTTP/3 di NGINX.