Veeam patches critical RCE in Backup & Replication (CVE-2026-44963)
An authenticated domain user can run code on a domain-joined VBR backup server. CVSS 9.4. Fixed in 12.3.2.4854; v13 is not affected.
Veeam shipped a fix on June 9 for CVE-2026-44963, a critical remote code execution flaw in Backup & Replication v12 that any authenticated domain user can exploit to run code on the backup server itself. Veeam scored it 9.4 (CVSS v4). The fix is in 12.3.2.4854. Only domain-joined VBR installations are exposed.
The primary advisory is Veeam's community resource hub entry; release notes are in KB4696.
Affected versions
- Veeam Backup & Replication 12.3.2.4465 and all earlier 12.x builds.
- Not affected: any 13.x build. Veeam attributes the gap to architectural changes in v13's authentication path.
Fixed in 12.3.2.4854, released June 9 as part of the regular 12.3.2 maintenance build.
What the bug does
The flaw is reachable by any account that belongs to the Active Directory domain the backup server is joined to. No backup-operator role, no admin role — a low-privilege domain user is enough. From there, exploitation lands code execution in the security context of the VBR service, which on a typical deployment holds credentials for every host, hypervisor, repository, and tape device in the backup chain.
watchTowr researcher Sina Kheirkhah discovered and reported the flaw.
Exploitation status
No public PoC and no in-the-wild reports at disclosure. Veeam's advisory warns that VBR CVEs are typically weaponized within days — CVE-2024-40711 went from patch to mass exploitation by Akira and Fog ransomware crews in under a week last year. Treat the clock as already running.
What to do today
- Upgrade to 12.3.2.4854. Veeam shipped no out-of-band hotfix and no workaround patch — the point release is the only patched build available.
- Inventory which VBR servers are domain-joined. Workgroup / standalone installations are not vulnerable to this specific CVE. If a given VBR host doesn't need AD membership for its backup workflows, this is the moment to confirm that and consider removing it.
- Audit who has any account in the same forest as the backup server. Dormant service accounts, unused interns, decommissioned contractors — every one of them is a path to RCE on the most blast-radius-heavy host in the estate. Disable, don't just unprivilege.
- Pull authentication logs on the VBR host. Look at Windows event IDs 4624 / 4625 / 4672 for the last 30 days. Interactive or network logons from unexpected low-privilege accounts are the canary you want.
- Treat the v13 migration as a security project. Veeam confirms this RCE class doesn't exist in 13.x. New deployments stood up this quarter should start there; existing 12.x estates need a documented upgrade path even if not this week.
Context
This is Veeam's second batch of high-severity VBR CVEs in three months. The March release bundled seven critical issues, all touching the same domain-join attack surface. Backup servers remain the highest-value pivot in enterprise networks: they hold the credentials to restore everything, which means they also hold the credentials to destroy everything. Ransomware operators have spent two years systematically targeting them before encryption — Akira, Fog, Black Basta and Storm-1175 have all built playbooks around VBR pre-positioning.
CVE-2026-44963 fits the pattern. Patch on the same change window you reserve for a domain controller; this host sits inside the same blast radius.