Your backup server sits inside the domain it has to restore

On 8 June, Veeam released build 12.3.2.4854 of Backup & Replication. It fixed CVE-2026-44963, a 9.4 out of 10, described in a single line: remote code execution on the backup server by "an authenticated domain user". That is worth reading twice. It does not say administrator. It does not say backup operator. It says user. And there is a consequence that is not in the vendor advisory but in the analysis an outside security firm published a month later: on a workgroup server, the flaw never comes into existence. Same code, same version, same machine. What changes is who your backup server asks whether you can be trusted.

The flaw is not where you think it is

The mechanics, according to the technical analysis SecureLayer7 published in July, are a .NET classic. The Veeam.Backup.Service.exe service exposes a .NET Remoting endpoint over HTTP on TCP/8000. Three chained WCF operations end up handing data to a BinaryFormatter deserialiser protected by a deny list: it rejects the known dangerous classes and trusts everything else. All you need is a serialisable class that is not on the list. The documented chain goes through DataSet subclasses, leans on ReadXmlSchema so that the schema is written by the attacker, and ends at Process.Start.

That is the how. The who is what matters. Before deserialising anything, the service checks that the caller belongs to the WindowsBuiltInRole.User role. On a domain-joined machine, any domain account satisfies that role: the intern, the sales rep, the printer's service account. On a workgroup machine only local accounts satisfy it — the ones you created, and you can count them on one hand.

And that who is not a quirk of this particular flaw: it is the pattern. In the same Veeam release note, the phrase "remote code execution on the Backup Server by an authenticated domain user" appears in March 2025 (CVE-2025-23120, a 9.9), again in October 2025, and twice more in March 2026 (CVE-2026-21666 and CVE-2026-21667, both 9.9). June's is the sixth in the series in little over a year, and also the lowest scoring one. A detail worth reading twice: the build now listed as vulnerable, 12.3.2.4465, was precisely March's patch for those two. Six repetitions of the same sentence is not bad luck in the code. It is what happens when a system's authorisation boundary is domain membership.

Two caveats before going on, because the rest of this article rests on them. First, and this needs stating precisely: that internal detail — the port, the class chain, the role being checked — comes from third-party analysis, not from Veeam's advisory, which is deliberately terse. Veeam does explicitly flag some of the earlier flaws as affecting domain-joined servers only, and it does not do so for this one. The claim that it never comes into existence on a workgroup server rests on the outside analysis, not on the vendor. Second caveat: we have no evidence that this CVE is being exploited in the wild, and we are not going to imply otherwise to create urgency. The argument in this post does not need it to be.

It already happened, in the same component, two years ago

In September 2024, Veeam fixed CVE-2024-40711: a 9.8 on the scale of the day (CVSS v3.1, whereas today's 9.4 is v4.0, so the two are not directly comparable), also untrusted data deserialisation and in the same service, that one unauthenticated. It shipped the update on 4 September; watchTowr published its analysis on the 9th and held the proof-of-concept code until the 15th. By October, the Sophos X-Ops team was already tracking at least four ransomware attacks using it. Akira and Fog first, Frag later. The pattern they described is the part that matters: they came in through VPN gateways with stolen credentials and no second factor, exploited the Veeam service from there, created a local administrator account and encrypted.

Nobody came in through the backup server. They came in somewhere else and went looking for it, which is different and deliberate: whoever controls the backups decides whether you negotiate. The same thing we saw in the wiping of Romania's land registry, where the attacker held valid credentials and destroyed everything their session could reach, backups included. And the same thing the statistics say: in this year's ransomware report, 79% of attacks started in identity, not in a vulnerability. Which is to say: by the time someone gets this far, they usually already hold some ordinary domain account.

The circular dependency nobody draws

So far this is a security problem. Now comes the part that turns it into a recovery problem — the part that almost never makes it onto the diagrams.

Sunday afternoon. Something has encrypted half the company and the domain controllers are compromised, powered off, or both. You go to the backup console, which is exactly what it exists for, and it asks you for a username. The answer to "who are you?" is given by the Active Directory you have just lost. The system that has to give you back the directory needs the directory to let you in.

Let us be precise, because it is easy to overstate this: it is not that the machine will not boot. Cached credentials will usually let you log on to the server. What breaks is everything else: name resolution, Kerberos tickets to the rest of the components, the service accounts the backup server uses to talk to repositories, hosts and agents. You do not find this out at the start of the restore. You find it out halfway through.

And it is not our discovery: it is in the vendor's own security best practice guide, in a sentence that sums it up — a data protection system should not rely in any way on the environment it is meant to protect. The same guide warns about both sides of the problem: if the production environment goes down along with its domain controllers, that hits your ability to perform restores, because the backup server depends on them for console authentication and for name resolution; and anyone who gains high privileges on that server also gets, as a bonus, detailed information about the infrastructure it protects.

It is a fire escape bolted to the façade of the building it is supposed to get you out of. It works perfectly as long as the problem is one floor. Not when what gives way is the structure.

What it really costs to take it out of the domain

This is where most articles write "move it to a workgroup" and go to lunch. The vendor's recommendation actually has two tiers, and neither is free:

• Small environments: workgroup. It is the fastest thing to set up and it genuinely isolates. In exchange, every system is configured separately — users, permissions, local security policy — there is no Kerberos, and everything has to be documented, because what group policy gave you in the domain, here you give yourself. With several backup servers and several operators, this gets heavy fast.
• Large environments: a management domain in a separate Active Directory forest. You keep centralised management, group policy and compliance, and you gain something operational a workgroup does not give you: disabling an account in one click in the middle of an incident. In exchange it is new infrastructure — controllers, backups, lifecycle — to build and maintain.

And there is a consequence that appears in neither description and causes the most work on day one: once you leave the domain, every connection towards production is made with explicit credentials stored on the backup server itself — hypervisor hosts, repositories, shares, agents, databases. That has to be inventoried before you touch anything, because what breaks if you miss one is not the console: it is the three-in-the-morning job.

The checklist we review a backup server with

• The exact build, not "12". 12.3.2.4465 and every earlier version 12 build are affected; 12.3.2.4854 fixes it; no 13.x build is affected, due to architectural changes.
• Is it domain-joined? The first question we ask, and it decides the rest.
• Who can reach TCP/8000. That port does not need to be reachable from the whole user network, and certainly not from the internet. It is the difference between "any domain user" and "any domain user who is also on the right segment".
• Accounts and second factor. How many accounts can log into the console, who knows them, and whether MFA is in place. In the 2024 attacks the way in was a VPN with no second factor; the backup server was merely the next stop.
• Repository immutability. It is the only thing left standing when everything above has failed.
• An access path that does not depend on the directory. How you get into the console on the day the domain does not answer: written down, with the credentials somewhere that also does not depend on the domain, and tested by someone other than you.
• A restore drill with the domain out of play. Not the one where you recover a deleted file: the one where you bring up a domain controller when no domain controller is left.

Before you touch the topology

Three situations where we would not start by taking the server out of the domain:

• If the repository is still mutable. Taking the server out of the domain while leaving the backups where a compromised administrator can delete them moves the problem, it does not solve it.
• If nobody is going to document anything. A badly run workgroup ends in a password in a drawer and an unpatched server because "that one is not covered by the policies". That is worse than where you started.
• If your backup server is neither Windows nor talks to Active Directory. Proxmox Backup Server, for instance, authenticates against its own realm by default, so it does not inherit this dependency; integrating it with LDAP or AD is optional, and that is precisely where it would inherit it. We run both, Veeam and PBS, and we resell neither: this is not "switch products", it is "look at what yours depends on".

The patch does not change who can call

Patching is mandatory and we are not arguing about it: if you run a version 12 build older than 12.3.2.4854, that is this week's job. But it is worth reading what the vendor actually says. Version 13 is not affected by this flaw because that part of the architecture changed, not because the underlying question has gone away: who does your backup server trust to tell it who you are? .NET deserialisation flaws have been showing up for a decade, and a deny list is always one step behind somebody else's creativity.

The patch closes one hole. The trust topology decides how many people can peer into the next one. They are two different jobs and we usually only do the first, in the same way that patching is not cleaning: closing the door does not change who had a key.

The question that tells you where you stand

You do not need an audit to know which side you are on. One question is enough, and it is worth asking it out loud at the next meeting: Monday morning, with the directory down, how do you get into the backup console?

If the answer is "with my usual account", you already know what your recovery plan depends on. If the answer is "we have never tested it", that is the same answer with better manners.

If you want us to look at how yours is built — what the console depends on, whether the repository holds up against a compromised administrator, and what exactly happens on the day the directory is missing — that is part of what we do in disaster recovery and managed backup.

Sources (verified): the CVE-2026-44963 facts (score 9.4 on CVSS v4.0; code execution on the backup server by an authenticated domain user; affects build 12.3.2.4465 and earlier version 12 builds; fixed in 12.3.2.4854, released on 8 June 2026; no 13.x build affected due to architectural changes) come from Veeam KB4696 and The Hacker News coverage of 9 June 2026, which credits the finding to Sina Kheirkhah (watchTowr). The run of earlier flaws carrying the same description ("remote code execution on the Backup Server by an authenticated domain user") is in that same KB4696: CVE-2025-23120 (9.9, March 2025), another in October 2025, and CVE-2026-21666 and CVE-2026-21667 (both 9.9, fixed in build 12.3.2.4465 of 12 March 2026 — the build now listed as vulnerable). In that KB, Veeam explicitly flags some of those flaws as affecting domain-joined servers only, but does NOT do so for the June one: the workgroup immunity rests on the outside analysis, not on the vendor. The internal detail — .NET Remoting endpoint on TCP/8000, three WCF operations, BinaryFormatter deserialiser with a deny list, chain via DataSet subclasses and ReadXmlSchema, and the WindowsBuiltInRole.User check — comes from SecureLayer7's technical analysis published on 6 July 2026: it is third-party work, not the vendor advisory, and we have said so. The workgroup or separate-forest management domain recommendation, its trade-offs and the line about not depending on the environment being protected are in Veeam's security best practice guide. The 2024 facts (CVE-2024-40711, 9.8; update on 4 September; watchTowr analysis on the 9th and proof-of-concept code on the 15th; Akira and Fog attacks tracked by Sophos X-Ops in October via MFA-less VPNs; Frag later) come from BleepingComputer and the Sophos blog. The 79% of attacks originating in identity is from Sophos's The State of Ransomware 2026 report, which we analysed at the time. We have no record of public exploitation of CVE-2026-44963 as of this article's publication date. Social image photograph: fire escape stairs in Rotterdam, by Marek Ślusarczyk (Tupungato), Wikimedia Commons, CC BY 3.0.