Veeam Backup & Replication 13: six CVEs and two 9.9 RCE paths

On 12 March 2026 Veeam published KB4831 for six vulnerabilities in Veeam Backup & Replication 13. Two — CVE-2026-21669 and CVE-2026-21708 — carry CVSS 9.9 and can provide remote code execution from an authenticated identity. The others cover stored SSH credential extraction, HA appliance RCE, local escalation and bypass of Windows driver-signature enforcement.

The fixed release is 13.0.1.2067; 13.0.1.1071 and earlier affected v13 builds are vulnerable. Veeam explicitly warned that patch reverse engineering was likely after publication. A backup server is a critical asset, so this update does not belong in an ordinary maintenance window several months away.

Six trust boundaries

CVE-2026-21669 allows an authenticated domain user to execute code on a Windows backup server. The 9.9 score reflects the low starting privilege: an ordinary domain identity should have no code path into a platform storing enterprise-wide recovery data. It is particularly relevant after phishing or workforce-account compromise.

CVE-2026-21708 affects the Backup Viewer role and allows code execution as postgres on Windows and appliance deployments. A read-oriented role sounds safe, but a feature-rich system can let “view” operations reach dangerous data or interpreter layers.

CVE-2026-21670 lets a low-privilege user extract stored SSH credentials. CVE-2026-21671 gives a Backup Admin an RCE route in HA appliance deployments. CVE-2026-21672 is Windows local privilege escalation, while CVE-2026-21709 lets a local administrator bypass driver-signature enforcement. Each has a different starting position; do not compress them into the inaccurate claim that anyone can remotely take over every Veeam server.

Why backup is a tier-zero target

VBR knows hypervisors, repositories, servers, agents and service accounts. It can read data, run jobs on hosts, restore systems and remove restore points. A compromise can expose credentials, sabotage recovery or turn trusted channels into lateral movement.

Backup is supposed to be ransomware’s final barrier. If it shares production Active Directory, administrator workstations and network paths, one domain foothold may become a short route to the platform intended to recover the business.

Establish effective exposure

Collect the running console, server, appliance, HA-node and proxy/repository versions. The executing process is evidence; an installer on a share is not. Record account roles, domain groups, management systems and network routes, including dormant DR nodes that only start during tests.

Determine:

• whether ordinary Domain Users can reach VBR service ports;
• which identities hold Backup Viewer and Backup Admin;
• what stored SSH credentials reach;
• whether HA appliance and Windows components need different packages;
• whether immutable repositories have separate administration;
• whether Veeam telemetry is stored outside its own trust domain.

CVSS 9.9 does not mean unauthenticated. It means low required privileges relative to complete impact — exactly where identity context matters more than an “internal only” label.

Upgrade sequence

Preserve configuration, logs and job evidence first. Verify backup integrity and access to an independent offline or immutable restore point. Upgrade the server and required components to 13.0.1.2067 or a newer fixed release exactly as KB4831 directs.

HA planning must cover node order, compatibility and failover. Verify every running process after upgrade, not just the console banner. Run a controlled backup and restore of a synthetic asset, then validate monitoring, repositories, agents and integrations.

Do not use a public RCE PoC in production. Version, reachability and role evidence are enough to prioritise. Active exploitation can damage services, databases or recovery data and turn a test into an incident.

Hunt and recover

Review domain logins to VBR, RBAC changes, unusual job creation, credential export, repository and retention changes, immutability disablement and deletion. Correlate child processes of Veeam services, connections to managed hosts, unusual PostgreSQL activity and Windows driver changes.

Where RCE evidence exists, assume exposure of service, SSH, hypervisor, cloud and storage secrets reachable from the server. Rotate them at destination systems, rebuild VBR from a trusted image and reconnect repositories only afterwards. Do not allow a compromised control plane to manage healthy recovery data again.

Architecture for the next CVE

• separate backup identity from the production domain where possible;
• use dedicated non-interactive, least-privilege accounts;
• restrict VBR ports to explicit components;
• deploy hardened repositories and immutability under independent administration;
• require PAM/JIT for Backup Admin;
• keep remote logs and alert on retention, repository and identity changes;
• test restore without dependency on production AD.

Combine this with a 3-2-1 backup strategy, privileged access management and ransomware defence. To ensure recovery remains a real last line of defence, BreachRoad can test its segmentation and identity paths.

---

Primary source: Veeam KB4831.