Veeam has patched a critical remote code execution flaw in Backup & Replication (VBR) that hands any authenticated domain user โ€” not an admin, not a privileged service account, just a regular domain user โ€” the ability to run arbitrary code on a domain-joined backup server. Tracked as CVE-2026-44963 with a CVSS score of 9.4, it was reported by watchTowr researcher Sina Kheirkhah and disclosed in Veeam’s June 9 advisory (KB4869). There are no public reports of in-the-wild exploitation yet, but given VBR’s track record, that window will not stay open long.

What’s affected

The flaw impacts Veeam Backup & Replication 12.3.2.4465 and all earlier version 12 builds. It is fixed in 12.3.2.4854 (KB4696). Critically, version 13.x is not affected โ€” Veeam says architectural changes introduced in v13 removed the vulnerable path entirely.

Two conditions gate exploitation, and both matter for triage:

  • The backup server must be joined to a Windows domain. Workgroup-mode installs are not exposed by this specific bug.
  • The attacker needs valid domain credentials, but only at the lowest privilege tier. Any authenticated principal in the directory qualifies.

That second point is what makes this dangerous. The bar is not “compromise a domain admin.” It’s “have any foothold in Active Directory” โ€” exactly the position an attacker occupies after a single phished helpdesk account or a low-value workstation compromise. Veeam has not published the low-level mechanism, but the access profile mirrors the lineage of prior VBR RCEs (notably CVE-2024-40711), where a reachable deserialization sink in the backup service let attackers turn a network foothold into code execution on the most security-critical box in the environment.

Why backup servers are the prize

Ransomware crews target Veeam on purpose. Operators have told reporters outright that the backup server is the first thing they go for: it holds credentials to the rest of the estate, it offers lateral movement, and โ€” most importantly โ€” deleting the backups from inside removes the victim’s ability to recover without paying. CISA’s Known Exploited Vulnerabilities catalog already lists four separate VBR flaws abused in real attacks. CVE-2024-40711 alone was weaponized by the Akira, Fog, and Frag ransomware operations within weeks of disclosure, and FIN7 and the Cuba gang have both built tooling against Veeam servers exposed online.

The blast radius is enormous. Veeam reports more than 550,000 customers, including 82% of the Fortune 500 and 74% of the Global 2,000. A meaningful share of those deployments are domain-joined despite Veeam’s own long-standing hardening guidance recommending workgroup isolation precisely to contain bugs like this one.

What to do now

  1. Patch immediately. Upgrade VBR to 12.3.2.4854 or move to a 13.x build. Veeam explicitly warned that attackers will reverse-engineer the patch to exploit unpatched installs โ€” assume a working exploit is days, not months, away.
  2. Get the backup server out of the domain. If you run VBR domain-joined, this incident is your forcing function. Follow Veeam’s hardening guide and move it to a workgroup or a dedicated management domain so a single AD foothold can’t reach it.
  3. Audit recent access. Review authentication logs to the backup server and the VBR service accounts for anomalous domain-user sessions. Absence of a public PoC is not evidence of absence.
  4. Verify backup immutability. Confirm immutable/air-gapped copies exist and are tested, so that even a fully compromised VBR host cannot erase your last line of defense.

This is not a novel attack class โ€” it’s the same backup-server-as-crown-jewel story that has played out repeatedly. The only variable is whether you patch before someone finishes the reverse-engineering.

References: Veeam KB4869 advisory ยท Patch KB4696 ยท BleepingComputer ยท The Hacker News