Multiple RCE and Privilege-Escalation Vulnerabilities in Veeam Backup & Replication (January 2026)

CyberDefender 18 mins0

On 6–7 January 2026 Veeam published fixes for four vulnerabilities in Veeam Backup & Replication (13.x builds up to 13.0.1.180) that allow authenticated users with backup-related roles to run code or write files with elevated privileges. Veeam resolved them in 13.0.1.1071. The issues include two RCEs that result in code execution as the PostgreSQL service account, one RCE that can lead to root execution via crafted backup configuration, and one arbitrary file-write as root. Customers should patch immediately and apply compensating controls where patching cannot be immediate.

What was disclosed

  • CVE-2025-59470 — remote code execution (RCE) as the postgres user via crafted interval/order parameters. CVSS v3.1: 9.0 (Critical); Veeam adjusted the operational severity to High because the attack requires highly privileged Backup/Tape Operator roles.
  • CVE-2025-55125 — RCE as root by providing a malicious backup configuration file (attacker needs Backup/Tape Operator privileges).
  • CVE-2025-59468 — RCE as the postgres user via a specially crafted password parameter (rated Medium by Veeam).
  • CVE-2025-59469 — arbitrary file write as root by an authenticated Backup/Tape Operator.

(All four were reported as discovered during internal testing and fixed in build 13.0.1.1071.)

Why these are serious

  1. Trusted code paths + privileged roles. Veeam Backup & Replication runs services and internal databases (PostgreSQL) on the backup host. Backup and Tape Operator roles are intended to manage backups and therefore have elevated access to internal subsystems. Vulnerabilities that let those roles control parameters used by internal components (e.g., DB parameters, config parsing, or file paths) can be abused to pivot from a backup account to code execution under service accounts (postgres) — and in two cases to root. The presence of an on-box Postgres process and privileged file-writing paths increases blast radius.
  2. Parameters as attack vectors. The problems described map to three common root causes: unsafe deserialization or insufficient input sanitization of parameters passed to internal subsystems (interval/order/password), unsafe parsing of uploaded configuration files, and insufficient filesystem-write validation. These are classic vectors where an attacker injects values that get interpreted later in a higher-privilege context.
  3. CVSS vs. operational severity. CVSS assigns high numerical severity to the strongest technical impact (e.g., CVSS 9.0 for CVE-2025-59470). Veeam’s “adjusted severity” accounts for environmental and temporal factors (the fact that exploitation requires Backup/Tape Operator privileges and recommended hardening), so Veeam reported an adjusted “High” instead of publicly acting as if it were an open, unauthenticated remote-to-root flaw. That nuance matters for risk triage but not for mitigation: unpatched systems are still at risk.

Technical breakdown (what the vendor says + likely root causes)

Note: Veeam’s KB gives short, plain-language descriptions for each CVE; they don’t publish exploit code or PoCs. Below I synthesize what the KB states and the typical technical mechanisms that lead to these behaviors.

CVE-2025-59470 — RCE as postgres via interval/order parameter

  • Veeam summary: A Backup/Tape Operator can trigger remote code execution as the postgres user by sending a crafted interval or order parameter. CVSS 9.0.
  • Likely root cause (technical): unchecked or improperly normalized parameter input that gets passed to a function executed with DB/service privileges (e.g., string formatting used to construct SQL or a shell invocation, or passing unvalidated input to an eval-like or command-building routine). The presence of S:C (scope changed) in the CVSS vector suggests the exploit can cross privilege boundaries or affect multiple components.
  • Prereqs: valid account with Backup or Tape Operator role (authenticated).
  • Impact: code runs as the Postgres Linux user; attacker could read/write the local DB, escalate further (e.g., use local misconfigurations to escalate to root), or tamper with backups.

CVE-2025-55125 — RCE as root via malicious backup config

  • Veeam summary: A Backup/Tape Operator may obtain RCE as root by creating a malicious backup configuration file.
  • Likely root cause (technical): unsafe parsing of uploaded backup config files (e.g., trusting external input that later gets used as a path or parameter to a privileged operation, or deserialization of data that can instantiate objects). When config content is parsed by a privileged component without strict whitelisting or sandboxing, arbitrary commands or payloads can be introduced.
  • Prereqs: authenticated Backup/Tape Operator privileges and a mechanism to upload or register the config (which the role normally has).
  • Impact: root-level code execution — highest practical risk if chainable to the rest of the environment.

CVE-2025-59468 — RCE as postgres via password parameter

  • Veeam summary: A Backup Administrator can achieve RCE as the postgres user by sending a malicious password parameter. Rated Medium (6.7).
  • Likely root cause (technical): input passed directly into code paths used by DB authentication/management routines; an injection or interpretation bug in how the password parameter gets processed; could be logic where password strings are later evaluated or concatenated into database commands without sanitization.

CVE-2025-59469 — arbitrary file write as root

  • Veeam summary: A Backup/Tape Operator can write files as root. Rated High.
  • Likely root cause (technical): path validation issues, race conditions, or logic that allows operator-controlled values to resolve to privileged filesystem paths. If file contents or names are supplied by a privileged-but-not-root role and the service performs writes as root (e.g., via a privileged helper), the attacker can plant arbitrary files, overwrite binaries, or drop SSH keys.

Exploitability & attacker model (what an attacker needs)

  • Authentication: All four issues require an authenticated account with backup-related privileges (Backup Administrator, Backup Operator, or Tape Operator). These are privileged accounts in typical deployments.
  • Network access: Most Veeam control plane APIs and management ports are reachable from the management network. If those networks are exposed or accessible to an attacker (e.g., via VPN or compromised admin workstation), an attacker could abuse these vectors.
  • Preconditions: exploitation depends on being able to supply crafted parameters or files that the product will process. There is no authoritative public reporting of in-the-wild exploitation at the time of the vendor disclosure, but the presence of RCE and file-write primitives make rapid weaponization plausible.

Detection — what to look for (safe, non-exploitative)

Do not attempt exploit code. Instead look for anomalous activity that often accompanies attempts to abuse these classes of vulnerabilities:

  • Authentication anomalies: logins by backup-role accounts at unusual times or from unusual IPs, sudden new service accounts, or unexpected changes to backup users.
  • Unusual parameter values: application logs containing unexpected or non-typical interval, order, or password values; extremely long or binary-looking fields in API logs. (Log and collect these values for analysis, do not execute them.)
  • Unexpected process spawns by postgres or Veeam processes: e.g., child processes of the postgres user that invoke shell commands, interpreters, or network utilities. Monitor process creation events originating from Veeam or Postgres service accounts.
  • New/modified files written by root in backup directories or system places: file creation or modification timestamps that don’t match maintenance windows; newly added SSH keys under /root/.ssh; unexpected binaries in /usr/local/bin or similar.
  • Integrity failures: checksum or binary integrity changes for installed Veeam binaries.
  • Network connections: outbound connections from the backup host to unexpected remote IPs (exfiltration attempts).

Suggested sources of logs and telemetry: Veeam application logs, OS auditd/syslog, process accounting, EDR alerts, and network flow logs. If you have SIEM, create correlation rules for backup-role authentication + unexpected process creation or file-write events.

Short-term mitigations (urgent, before patch)

  1. Patch immediately — install Veeam Backup & Replication 13.0.1.1071 (fixes all four issues). This is the single best action.
  2. Least privilege — restrict Backup/Tape Operator and Backup Administrator accounts to the minimum set of users and hosts; remove unnecessary accounts and rotate credentials.
  3. Network segmentation — isolate management interfaces and backup repositories to a management-only network and block direct access from general user networks and the internet.
  4. Harden access to backup console — require MFA for accounts that can manage backups and require access only from approved admin workstations.
  5. Enable and monitor OS/EDR telemetry — make sure process creation, file writes, and shell execution from the postgres or Veeam processes are captured and alerted on.
  6. Temporary compensating control — if you cannot patch immediately, consider disabling remote management APIs or restricting access via firewall rules to known admin IPs (weigh service impacts carefully).

Recommended patch/upgrade plan

  1. Inventory all Veeam Appliances and Backup & Replication servers; identify those running 13.0.1.180 or earlier 13.x builds. (Veeam KB lists affected builds: all 13 builds up to 13.0.1.180.)
  2. Schedule maintenance windows and apply 13.0.1.1071 per vendor instructions (test in staging first if possible).
  3. After patching, verify service health (backup jobs, DB connectivity) and monitor for any signs of compromise (see Detection).
  4. If patching is not immediately possible, apply the mitigations above and create enhanced monitoring around backup-server activity.

Incident response if you suspect compromise

  • Isolate the affected backup host from the network (or apply strict egress filtering) to prevent lateral movement/exfiltration.
  • Snapshot evidence: collect memory, filesystem images, and Veeam logs (application logs and system logs). Preserve chain-of-custody.
  • Forensic triage: look for created files by root, recent processes spawned by postgres or Veeam processes, unexpected user accounts or SSH keys, and outbound network connections.
  • Rotate credentials for backup-related service accounts, admin accounts, and any credentials stored in backups if there’s evidence of exfiltration or tampering.
  • Restore and validate from backups known to predate the compromise, only after ensuring the backup environment is clean. Because these vulnerabilities target backup systems, be especially careful: an attacker who controls backups may have persisted hidden modifications.
  • Engage vendor support and follow Veeam’s incident response guidance; consider involving external IR specialists if root compromise is suspected.

How operators can safely validate their remediation

  • Version check: verify the installed version is 13.0.1.1071 or later on all 13.x systems. The vendor KB lists the patched build.
  • Functional tests: run backup/restore operations in a test environment and verify normal behavior; check that hardened access controls still allow legitimate admin workflows.
  • Passive detection checks: search logs for the specific anomalous strings or patterns you saw pre-patch; confirm that altered or malicious config files are not present.
  • Threat-hunt: run the detection checklist above to ensure no signs of exploitation remain.

Practical hardening & longer-term recommendations

  • Enforce strong separation of duties: treat backup operators as high-privilege and apply privileged-access controls (PAM) to their accounts.
  • Run backup appliances in segmented management networks with strict firewall and zero-trust access.
  • Apply defense-in-depth for backup infrastructure: host-based hardening, EDR, immutable backup targets where possible, and strong logging/monitoring.
  • Keep an inventory and automated patching pipeline for critical infrastructure components (backup servers are high-value targets).
  • Periodically audit what backup-role accounts can do and remove any capabilities they do not need.

Final notes

  • The single highest-impact action is to upgrade to Veeam Backup & Replication 13.0.1.1071 across all affected systems and validate backups post-upgrade.
  • Even though exploitation requires authenticated backup roles (which reduces the public risk surface), organizations commonly grant backup-role access to service accounts and admins — and backup servers are a high-value target for attackers seeking persistence and data theft. Treat these fixes as urgent.

CyberDefender