DEV Community

facilishz
facilishz

Posted on

CVE-2025-64393: Critical Remote Code Execution in Veeam Backup & Replication

#vulnerability #veeam #backup #cve202564393

CVE-2025-64393: Critical Remote Code Execution in Veeam Backup & Replication

Vulnerability overview

Singapore's Cyber Security Agency (CSA) published alert AL-2026-138 on 9 October 2026 describing a critical vulnerability in Veeam Backup & Replication, tracked as CVE-2025-64393. The alert assigns the flaw a CVSS v4.0 base score of 9.4 out of 10, placing it in the critical band. A vendor advisory is available as Veeam KB4934, and the public CVE record is maintained in NVD.
The affected range is broad for a modern backup platform: versions 12 through 12.3.2.4854. Any deployment running a build inside that window should be treated as in scope until it is upgraded.

Mechanism and exploitation conditions

According to the CSA alert, the flaw is reached through the Mount Service, which accepts data that is then deserialised without sufficient trust checks. Deserialising attacker-controlled data inside a privileged service is a well-known route to code execution, because the serialised payload can influence object construction inside the process rather than simply carry data.
The trigger requires an attacker who already holds the Backup Viewer role. That detail matters. CVE-2025-64393 is not an unauthenticated flaw reachable by any random internet client. The attacker needs a legitimate account with a specific, granted permission. The alert states that such an attacker can perform remote code execution on the Veeam Backup Server, and the code runs as SYSTEM on the host.
Two conditions therefore have to hold for exploitation. First, the target must run an affected build. Second, the attacker must possess, or obtain, the Backup Viewer role. The second condition is often treated as low risk during reviews, because the permission sounds read-only. This alert shows why that assumption deserves scrutiny.

Impact

Successful exploitation hands the attacker the highest privilege level on the backup server: SYSTEM. On a backup server, that level of control is exceptionally valuable. The host typically stores credentials for the environments it protects, holds recovery points for production systems, and manages storage repositories. An attacker with SYSTEM on that host can move the recovery objective itself, not just the production workload.
The alert does not report confirmed exploitation in the wild, and it does not describe a public proof-of-concept. The severity assignment reflects the combination of remote reachability through a service endpoint, the deserialisation weakness, and the resulting SYSTEM context rather than observed attacks.

Affected products and scope

The vulnerable range covers Veeam Backup & Replication 12 through 12.3.2.4854. Deployments on later builds that include the fix are outside the described range. Because the flaw is bound to a role and to the Mount Service, the exposure is a function of both version and identity configuration: systems where the Backup Viewer role is broadly assigned deserve priority attention even if they are few in number.
The alert states the vulnerability clearly but does not enumerate every product edition, so administrators should confirm the applicable edition and build against the vendor advisory rather than infer coverage from a marketing name.

Exposure context

A ZoomEye observation for the search dork title="Veeam Backup" returned 15,647 matching assets at the time of this analysis. That figure describes internet-visible assets whose titles match the query. It is observed exposure, not proof that those hosts run an affected build or that any of them is exploitable. The CVE-specific filter query returned no results, which is a normal outcome for a recently published identifier and is not evidence that the flaw is absent.

Remediation and mitigations

The alert's recommendation is direct: apply the security update immediately. Veeam KB4934 is the authoritative source for the fixed build and for any edition-specific instructions, and it should be read before scheduling the change.
While an upgrade is being arranged, reduce the two conditions the flaw depends on. Restrict who holds the Backup Viewer role and review every assignment, especially inherited ones. Keep the backup server and its management interfaces off untrusted networks. Confirm that the Mount Service is reachable only from systems that genuinely need it. After the upgrade, verify the running build rather than the installer's reported version.

References

Top comments (0)