Should Your Veeam Backup Server Be on the Domain? CVE-2026-44963 Settles the Question

One question decides whether CVE-2026-44963 is an emergency for you or a footnote: is your Veeam backup server joined to a Windows domain? Veeam shipped the fix on June 9, and the flaw it closes carries a CVSS v4 score of 9.4. A domain user with no special privileges - any enabled account in your Active Directory - can run code on the Backup & Replication server. The reason that one question matters so much is that the bug only reaches installations that are domain-joined. A server in a workgroup, or in a separate management forest, never exposes the path.

The vulnerability was reported by Sina Kheirkhah of watchTowr and affects Veeam Backup & Replication 12.3.2.4465 and every earlier version 12 build. It is fixed in 12.3.2.4854. The 13.x line is unaffected, because the authentication architecture changed in that release. Veeam has not published the technical chain and there is no public exploit yet, but the company stated plainly what comes next: attackers reverse-engineer the patch and go looking for servers that did not install it.

Here is the honest version of who needs to act. If your backup server sits in a workgroup, or in its own management domain separate from the production forest, or you are already on 13.x, this specific CVE is not yours - patch on your normal maintenance window and read the rest of this for the architecture argument, not the fire drill. If the server is joined to the same Active Directory your staff log into every morning, and it runs a version 12 build, treat it as urgent. The arithmetic is unforgiving: the number of accounts that can now reach code execution on that box equals the number of enabled users in your domain, and the box in question holds the copy of your data you most need to survive an attack.

What the bug gives an attacker

The CVSS vector tells most of the story: AV:N/AC:L/AT:N/PR:L/UI:N with high impact across confidentiality, integrity, and availability, and high subsequent-system impact on top. Network-reachable, low attack complexity, low privileges required, no user interaction, and the damage does not stop at the Veeam process. In plain terms, an attacker who already holds one ordinary domain credential - phished, password-sprayed, or reused from an old breach - can send the right request to the backup server and end up executing code on it.

That is what separates this from a routine application bug. Veeam Backup & Replication runs its services under accounts with deep reach. The server stores the credentials it uses to connect to every host, hypervisor, and repository it protects, and it has the rights to read and delete the backups themselves. Code execution there reaches the recovery system for the entire environment along with a credential set that often unlocks large parts of it. That is a different category of problem from a foothold on an edge appliance you reimage by lunch.

Veeam withheld the exploitation details, which is the right call while organizations patch. It does not buy much time. The previous critical Veeam RCE, CVE-2024-40711, went from disclosure to working exploit code within about a week, and affiliates of the Akira and Fog ransomware operations used it specifically to reach backups before deploying their encryptors. The playbook is established. Plan as though a reliable exploit already exists, because in this product family one historically has, and quickly.

Run this on each Veeam server to confirm the installed build. Anything below 12.3.2.4854 on the version 12 line is exposed.

# Run on the Veeam Backup & Replication server (PowerShell, elevated).
$fixed = [version]"12.3.2.4854"
$key   = "HKLM:\SOFTWARE\Veeam\Veeam Backup and Replication"
$build = (Get-ItemProperty $key -ErrorAction Stop).CorePackageVersion
$v     = [version]$build

if ($v.Major -eq 12 -and $v -lt $fixed) {
    Write-Warning "VBR $build is VULNERABLE to CVE-2026-44963. Upgrade to 12.3.2.4854+."
} elseif ($v.Major -ge 13) {
    Write-Host "VBR $build (13.x line) is not affected." -ForegroundColor Green
} else {
    Write-Host "VBR $build is patched against CVE-2026-44963." -ForegroundColor Green
}

The real question: should a backup server be on the domain at all

Veeam has recommended against domain-joining the backup server for years. Its Security Best Practice Guide is explicit: for small and medium environments, put the Backup & Replication server in a workgroup; for large environments, place it and the rest of the backup infrastructure in a separate management domain in its own Active Directory forest. CVE-2026-44963 is the concrete, dated reason to finally act on advice that has always been easy to defer.

The case for joining the backup server to the production domain is convenience: one set of logins, the group policy you already manage, no separate credential store to document. The case against it is everything this CVE demonstrates. A domain-joined backup server inherits the entire domain as its trust boundary. Every credential-theft path, every over-permissioned group, every phished user becomes a potential route to the one system whose whole job is to outlive the compromise of the others. When ransomware rides in on a domain user's roaming profile and that user has any reach into the backup server, the malware reaches it too.

How to decide

• Under roughly 100 endpoints, one or two IT staff: workgroup. Give the backup server a unique local administrator password, manage it directly, and accept the modest overhead. Doing so removes the domain-user attack path entirely, this CVE included.
• Larger, or an MSP backing up multiple clients: a dedicated management forest with no trust, or a one-way trust, to production. More work to stand up, far smaller attack surface, and a tenant's domain compromise stays away from the backup fabric.
• Domain-joined to production and unable to change it this week: patch immediately, then put the migration on the roadmap. The patch closes this bug and does nothing about the next one in the same class.

Check where each server actually stands. If this returns True on a box joined to your production domain, that membership is the exposure the CVE turns into code execution.

# Is this backup server domain-joined? CVE-2026-44963 only applies when True.
(Get-CimInstance Win32_ComputerSystem).PartOfDomain

# If True, list the domain it trusts and confirm it is not your production forest:
(Get-CimInstance Win32_ComputerSystem).Domain

Patch, then close the path for good

Patching is the first move and it is not optional. Upgrade version 12 deployments to 12.3.2.4854 or later; if you are already planning the jump to 13.x, this is one more reason to schedule it. The servers that get breached through bugs like this, though, are usually the ones nobody remembered they were running. Veeam gets installed for a one-off migration, a branch office, or a project, then runs forgotten on a build no one tracks. Inventory every instance before you assume they are all patched.

The control that turns a backup-server compromise from a business-ending event into a bad afternoon is a copy of your backups the backup server itself cannot delete: immutable object storage with object lock, a hardened Linux repository with immutability enabled, or genuinely offline media. This is the second "1" in the 3-2-1-1-0 rule, and it is the difference between paying a ransom and restoring from a copy the attacker could not touch.

The hardening pass

• Upgrade every version 12 instance to 12.3.2.4854 or later, and confirm the build rather than assuming it.
• Discover every Veeam install on the network, including the ones spun up for a project and forgotten.
• Settle the domain question above and start the migration if the answer is "off the domain."
• Keep at least one immutable or offline backup copy the server cannot reach to delete - the 3-2-1-1-0 rule.
• Restrict and log who can authenticate to the server, and alert on domain logons you did not expect.
• Test a restore. A backup you have never restored is a guess about your recovery, not a fact.

While you plan the architecture change, watch the box. This hunt surfaces every domain-account logon to the backup server in the last week, filtering out the machine and SYSTEM noise, so an unexpected user account reaching it stands out.

# Run on the backup server: domain-account logons in the last 7 days.
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624; StartTime=(Get-Date).AddDays(-7)} |
  Where-Object { $_.Properties[5].Value -notmatch '^(SYSTEM|ANONYMOUS LOGON|.*\$)$' } |
  Select-Object TimeCreated,
    @{n='Account';   e={$_.Properties[5].Value}},
    @{n='Domain';    e={$_.Properties[6].Value}},
    @{n='LogonType'; e={$_.Properties[8].Value}},
    @{n='Source';    e={$_.Properties[18].Value}} |
  Sort-Object TimeCreated -Descending | Format-Table -AutoSize

Get the backup server off the domain

Patch to 12.3.2.4854 today if you run a version 12 build - that is the part with a deadline attached, and a low-privilege foothold anywhere in your domain is enough to start the clock. Then treat the patch as the start of the work, not the end of it. The reason this CVE is an emergency for some organizations and a non-event for others comes down to one architectural choice Veeam has recommended against for years, and that choice is yours to change. Move the backup server into a workgroup or a separate management forest, keep an immutable copy your environment cannot delete, verify a restore actually works, and the next Veeam authentication bug never reaches the one system you cannot afford to lose.