Before the Patch Window Opens: Segmenting Your Backup Infrastructure

Any domain account can RCE your Veeam backup server right now. The Distributed Firewall is how you limit the blast radius while you wait for the patch.

The patch for your Veeam Backup & Replication server is probably not on this week’s change request. It’s on next week’s, assuming the maintenance window falls on a weekend and the app owner for the workloads your backup server protects is available to sign off on a testing window and the QA team isn’t already committed to a pre-production deployment. This is not bureaucracy failing you. This is change management working as designed for infrastructure that’s correctly categorized as high-risk-to-touch. The problem is that the window between “advisory published” and “patch applied” is exactly the window attackers are probing for the thing you haven’t fixed yet.

The Veeam advisory published this month describes a flaw in Backup & Replication version 12 that allows any authenticated domain user to execute arbitrary code on the backup server. No local admin rights required. No special Veeam permissions. Any Active Directory account — including the service account your helpdesk ticketing system uses, or the contractor account that never got deprovisioned — can run code on the machine that has network reach to every workload you protect. Veeam has patched it, but if you haven’t applied the fix yet, the exposure is live. The severity rating is 9.4.

What makes this particularly bad is what backup servers see. To take backups, they need to talk to protected workloads. That’s inherent to the architecture. A backup server that can reach every database, every application tier, and every domain controller is, from a lateral movement standpoint, the most connected host in your environment. Ransomware operators have known this for years. Compromising the backup server before encrypting production is standard playbook: destroy recovery options first, then detonate.

The exposure is wider than one CVE

A report published earlier this month analyzed internal traffic across 312 enterprise environments and found that 80% of enterprise servers are reachable from anywhere inside the network. Not “reachable after the attacker pivots through several hops.” Directly reachable. Seventy-eight percent of those servers accept inbound connections over SMB or WinRM — the same protocols ransomware uses to spread. Forty-three percent of internal authentication traffic still relies on NTLM, a protocol that hands credential hashes to any host that asks for them.

These numbers aren’t about the Veeam vulnerability specifically. They’re about the condition that makes the Veeam vulnerability so dangerous. If your backup server is reachable from any workstation on the network, then an attacker who compromises a contractor’s laptop can be running code on your backup server by the next morning. The only prerequisite is a domain credential, and NTLM relay or a single phished account handles that.

The report frames this as a blast radius problem. The vulnerability provides initial access. The unrestricted east-west reachability is what converts initial access into full-environment compromise. Patching Veeam is necessary. It’s not sufficient. The underlying exposure — any workload can reach any other workload — remains true after you patch, and will remain true until you do something about the network policy.

What the Distributed Firewall does here

vDefend’s Distributed Firewall (formerly NSX Distributed Firewall) is a stateful firewall enforced at the hypervisor vNIC of every VM, including your Veeam backup server. Policy travels with the workload regardless of network topology. You don’t reroute traffic through an appliance or provision a new VLAN. The rule is enforced where the packet originates.

For backup infrastructure, this means writing a DFW policy that permits inbound backup jobs from the Veeam server to protected workloads, while blocking inbound connections to the Veeam server from anything that isn’t the Veeam management console or authorized backup proxies. No direct SMB from arbitrary workstations. No RPC from endpoints with no legitimate reason to initiate connections to the backup server.

This doesn’t close the flaw — a legitimate Veeam process can still be exploited by a malicious domain user. But it defines what an attacker can do from the backup server after exploitation. If your DFW policy restricts the backup server so that it can only initiate outbound backup traffic to protected workloads, an attacker who lands on it has a foothold on an isolated host, not a launchpad into everything else. Detection without enforcement is a ticket queue. The DFW is enforcement.

The vDefend 9.1 Connectivity Strategy feature is worth deploying here specifically. Within Distributed Firewall policies, you can now invoke a Connectivity Strategy that applies application isolation directly from Security Intelligence flow recommendations or from your own stated design intent. The Isolated policy mode restricts a VPC or workload group so that only explicitly permitted flows are allowed; everything else is denied by default. That’s the correct posture for infrastructure this sensitive — whitelist the Veeam-specific protocols your environment actually uses, block the rest.

vDefend 9.1 also expanded the Distributed IDS/IPS signature library to cover 5,000+ Layer 7 application IDs. Enable DIDPS on your backup server segment with the latest signature content pack applied. There are signatures for unsafe deserialization patterns of the kind this vulnerability exploits. Signatures catch what’s known; the DFW policy is what catches attacker behavior that doesn’t match a signature.

What to do this sprint

Pull up the DFW policy for your backup server group right now. If you don’t have a dedicated NSX group for backup servers, create one in NSX Manager and assign the backup server VMs to it today. Then look at what flows are currently permitted to reach it.

If you’re running VCF 9.1, use the newly-published lateral security design blueprints for vDefend as your baseline. The blueprints — published this month and integrated directly into core VCF 9.1 design documentation — include verified configurations for securing management-domain infrastructure, which is where backup servers typically live. The point of blueprints is to skip the “where do I even start” phase and get to a defensible baseline faster. Use them.

For teams not yet on 9.1, the approach is the same, just manual: use Security Intelligence to observe what flows are currently hitting the backup server, flag anything that shouldn’t be there (workstation-to-backup-server RPC over port 135 or higher is a good place to start), and write DFW rules to block it. Set the backup server group to a default-deny posture and permit only what you can justify. Cross-reference the resulting permitted flows against your asset list. If flows from tier-1 production workloads to the backup server are permitted bidirectionally, tighten that to outbound-only from the backup server.

The patch still needs to happen. But the window between disclosure and remediation doesn’t have to be open season on your recovery infrastructure.

Further reading

• CVE-2026-44963: Veeam Backup & Replication RCE Vulnerability (Veeam Community)
• New Veeam vulnerability exposes backup servers to RCE attacks (BleepingComputer)
• 80% of Enterprise Servers Are Wide Open Once Attackers Get Inside — 2026 Lateral Movement Exposure Report (BusinessWire)
• Introducing VMware vDefend Lateral Security Design Blueprints for VCF 9.1 (VMware Security Blog)
• VMware vDefend for VCF 9.1: Zero Trust Lateral Security for the AI Era (VMware Security Blog)
• VMware vDefend 9.1 Release Notes (Broadcom TechDocs)
• MITRE ATT&CK: Remote Services — Lateral Movement (T1021)
• MITRE ATT&CK: OS Credential Dumping (T1003)