Veeam CVE-2026-44963: un utente di dominio basta per i backup

Il 9 giugno 2026 Veeam ha rilasciato una patch d'emergenza per CVE-2026-44963, una vulnerabilità critica di remote code execution in Backup & Replication con punteggio CVSS 9.4. Il dato che conta non è il punteggio. È la precondizione: qualsiasi utente di dominio autenticato e a basso privilegio può eseguire codice su un server di backup unito al dominio. Non un domain admin. Non qualcuno che già controlla la macchina. Un singolo account ordinario — quello che ogni gruppo ransomware possiede entro poche ore dall'ingresso — trasforma la macchina più sensibile dell'edificio in una shell. Veeam è installato su oltre 550.000 clienti nel mondo, incluso l'82% delle Fortune 500: non è il bug di un'appliance di nicchia. È una precondizione soddisfatta in una frazione enorme delle reti aziendali in questo momento.

A CVE-2026-44963 basta un utente di dominio a basso privilegio

La falla è stata segnalata dal ricercatore watchTowr Sina Kheirkhah e divulgata insieme alla correzione, la versione 12.3.2.4854. Colpisce Backup & Replication dalla 12 alla 12.3.2.4465 e ogni build 12.x precedente; la linea 13.x non è interessata grazie a modifiche architetturali. L'avviso di Veeam la descrive in modo asciutto: "una vulnerabilità che consente l'esecuzione di codice remoto sul Backup Server da parte di un utente di dominio autenticato", e The Hacker News conferma la soglia bassa — l'account non deve essere privilegiato, solo unito al dominio e autenticato.

È proprio quella soglia il punto. L'RCE pre-autenticazione fa notizia perché si può spruzzare su tutta Internet. Ma un server di backup non sta su Internet — sta in profondità nella VLAN di management. La domanda operativa per un difensore non è mai "un attaccante anonimo può raggiungerlo da fuori?". È "una volta che qualcuno è dentro con una credenziale di helpdesk rubata, cosa può raggiungere?". CVE-2026-44963 risponde nel modo peggiore: può raggiungere l'esecuzione di codice sull'unica macchina che custodisce tutti i tuoi restore point.

Perché i gruppi ransomware colpiscono il server Veeam per primo

Su chi si interessi a questo non c'è ambiguità. Gli operatori ransomware hanno dichiarato direttamente a BleepingComputer che colpiscono sempre i server di backup Veeam — perché quella singola macchina permette di fare tre cose insieme:

• Rubare i dati. Il server di backup, per progettazione, contiene una copia leggibile di tutto ciò che vale la pena salvare. Compromettilo e salti il lavoro di scandagliare le condivisioni di rete — il bersaglio di esfiltrazione è già pre-aggregato.
• Muoversi lateralmente. Veeam ha bisogno di credenziali ampie e visibilità di rete per funzionare, quindi il service account è un punto di pivot verso hypervisor, file server e domain controller.
• Uccidere il ripristino. Cancella o corrompi i restore point e all'azienda restano solo due opzioni: pagare o ricostruire. La leva di una negoziazione a doppia estorsione viene interamente dall'assenza di un ripristino pulito.

È la kill chain canonica, e Veeam ne è bersaglio in modo ricorrente. L'istinto del difensore è trattare i backup come un controllo di recovery. L'attaccante li tratta come l'obiettivo primario — neutralizzare i backup, poi detonare.

CVE-2026-44963 è il pattern, non l'eccezione

Se l'impressione è di déjà-vu, è perché questa è solo l'ultima voce di una serie lunga e coerente. Il precedente del 2024 è quello da studiare. CVE-2024-40711, un RCE da deserializzazione di dati non attendibili con CVSS 9.8, è stato armato in poche settimane dai gruppi ransomware Akira e Fog. Sophos ha documentato un terzo operatore, "Frag", che usava lo stesso exploit e le stesse tecniche: ingresso da un gateway VPN senza MFA, colpo a Veeam sull'URI /trigger alla porta 8000, net.exe lanciato dal mount service e creazione di un account locale chiamato "dot" aggiunto ai gruppi Administrators locali e Remote Desktop Users. CISA ha inserito quel CVE nel suo catalogo Known Exploited Vulnerabilities; FIN7 e il gruppo ransomware Cuba sono stati collegati a falle Veeam precedenti.

CVE	Anno	CVSS	Sfruttato da	Tempo di weaponization
CVE-2024-40711	2024	9.8	Akira, Fog, Frag	Settimane; in CISA KEV
Falle VBR precedenti	2023–24	fino a 9.8	FIN7, Cuba	In-the-wild
CVE-2026-44963	2026	9.4	Non ancora osservato	Patch pubblicata; reverse engineering in corso

CVE-2026-44963 non è stato ancora visto in-the-wild. Quell'avverbio pesa molto. Veeam stessa riconosce il passo successivo ovvio — gli attaccanti fanno reverse engineering della patch per costruire un exploit contro il parco non aggiornato. Per i bug Veeam ad alto valore, l'intervallo tra "patch rilasciata" ed "exploit nel playbook di un ransomware" si è storicamente misurato in settimane, non in trimestri. Trattare "nessuno sfruttamento osservato" come margine di respiro è esattamente l'errore che la cronologia del 2024 punisce.

Cosa la patch non risolve

La patch 12.3.2.4854 chiude lo specifico percorso di codice. Non cambia tre fatti strutturali che sopravviveranno a questo CVE:

"Abbiamo patchato Veeam il giorno stesso. Siamo coperti."

Coperti contro questo CVE. Non contro il prossimo — e non contro l'attaccante che aveva già un account di dominio ed era già dentro quando avete patchato.

Primo: il server di backup resta il bersaglio interno di maggior valore della rete, patchato o no. Secondo: la superficie d'attacco "qualsiasi utente di dominio" è una proprietà di progettazione di un server di backup unito al dominio, non un bug isolato — ogni futura falla di deserializzazione o di logica di autenticazione di questa classe eredita la stessa precondizione banalmente soddisfatta. Terzo: patchare non dice nulla su se quel percorso fosse già stato percorso. Un server di backup raggiungibile da un foothold a basso privilegio la settimana scorsa era raggiungibile a prescindere dall'esistenza di un CVE pubblicato.

Il punto cieco: il tier di backup non è mai stato nello scope del pentest

Ecco la parte scomoda. Prendete il report del penetration test dell'anno scorso e leggete la dichiarazione di scope. Quasi certamente copre il perimetro esterno, l'applicazione web pubblica, forse la VPN. Quasi certamente non include un esercizio assumed-breach che parte da un account di dominio a basso privilegio e si chiede: da qui, posso raggiungere l'RCE sul server di backup? Il tier di backup è trattato come infrastruttura, non come superficie d'attacco — esattamente l'inversione che i gruppi ransomware sfruttano.

Un pentest annuale è anche un'istantanea. Dice che il percorso verso il backup era sicuro il giorno del test, contro gli exploit noti in quella data. CVE-2026-44963 è uscito il 9 giugno. Se il vostro test è stato a marzo, il report tace su questo — e tacerà fino al marzo successivo. La cadenza della divulgazione è settimanale; quella della validazione, per la maggior parte delle organizzazioni, è annuale. Quel disallineamento è il dwell time in cui vivono gli attaccanti.

Dove si inserisce Zero Hunt

Lo scenario descritto da CVE-2026-44963 — un foothold interno a basso privilegio che raggiunge l'esecuzione di codice sul server di backup — è esattamente il percorso che un motore di validazione continua in modalità assumed-breach è costruito per trovare prima di un attaccante. Lo swarm di 10 agenti AI di Zero Hunt opera dall'interno della rete, non solo dal perimetro: gli agenti Credential, Pivot e Post-Exploit concatenano un account di dominio in mano verso bersagli interni ad alto valore come farebbe un operatore, e generano l'exploit per ambiente con un LLM locale invece di pescare un modulo statico — così una classe di RCE su server di backup appena divulgata viene esercitata contro la vostra topologia reale, non un lab generico. Ogni tecnica candidata è backtestata nell'AI Gym contro corpora come Vulhub e la suite black-box basata su CVE prima ancora di toccare la produzione, e lo swarm gira su un'appliance 100% on-prem senza callback verso il cloud — il che conta quando gli asset sotto test sono i vostri sistemi di backup e management più sensibili. Le campagne change-triggered fanno sì che un server Veeam appena patchato (o appena non patchato) avvii una validazione entro l'ora, non alla prossima finestra annuale.

E per la metà della kill chain che la patch non può mai sanare — l'attaccante che era già dentro — il modello di AI Traffic Analysis è la seconda linea. Le sue quattro inference head osservano il filo proprio per le firme che seguono la compromissione di un server di backup: un host di management che storicamente solo riceve dati e all'improvviso legge ogni repository, cancellazioni massive di restore point, fan-out laterale anomalo dal service account Veeam verso hypervisor e domain controller. Quell'attività è rilevabile comportamentalmente, nei secondi in cui sta accadendo, invece che nel digest SIEM del mattino dopo — il che, quando il bersaglio è la vostra capacità stessa di recuperare, è la differenza tra un incidente e una catastrofe.

Patchate CVE-2026-44963 oggi. Poi ponetevi la domanda che la patch lascia aperta: se qualcuno ha già un account di dominio ordinario, può raggiungere i miei backup — e me ne accorgerei? Se non potete rispondere a entrambe le metà a partire da evidenza continua, la patch vi ha comprato meno tempo di quanto pensiate. Parliamone.