Skip to content
RESEARCH INDEX BREACHROAD / INTELLIGENCE NOTE

Veeam CVE-2025-64393: Backup Viewer access and the October P4 fix

Review Veeam Backup & Replication 12 versions and access. Apply the fix, verify backup operations and prepare the team to respond to suspicious activity.

PUBLIC RESEARCH
AUTHOR
/ CEO of Breachroad · OSCP · PNPT
PUBLISHED
10 October 2026
READING TIME
5 min read
TOPIC
Vulnerabilities and CVEs
Veeam CVE-2025-64393: Backup Viewer access and the October P4 fix

On October 6, Veeam published KB4934 for Backup & Replication 12.3.2 P4. CVE-2025-64393 affects build 12.3.2.4854 and earlier version 12 releases. The vendor states that version 13 is unaffected by this issue.

Breachroad recommends confirming the running backup server’s build, scheduling the update and reviewing assignment of the Backup Viewer role today. Also assign someone to verify correct operation after the change. Protection of the recovery system needs a specific owner and an outcome that can be checked.

Viewer access is a condition of the reported path

The CVE-2025-64393 record describes code execution as SYSTEM by a user with the Backup Viewer role. This account-access requirement belongs in the assessment of the particular environment.

In our assessment, a role’s name is insufficient to establish that an account is unimportant. Administrators should identify the people and groups holding access, why they need it and how it can be withdrawn. Include accounts left behind after a project, external support engagement or staff absence. Review permissions alongside the urgent update.

Record who can investigate an unexpected login and where console operators should report one. If an account is shared, assess whether activity can be attributed to a particular person. These are Breachroad’s access-management recommendations, rather than evidence that the vulnerability has been used in your organisation. The review should produce clear ownership of each unresolved access question.

Finish the update by verifying the outcome

The release information identifies fixed build 12.3.2.4934 and explains how to check the console’s build number under Help > About. Before changing the system, confirm the appropriate update path for the installed version and components.

Our proposal for the service owner is to agree on a maintenance window, the change lead’s contact details and completion criteria. Record the build before and after the update. Also agree on what to do if a problem occurs so on-call staff know when to request more support and who decides the next steps.

Afterwards, check the outcome of agreed jobs and availability of the recovery process. Select checks appropriate to the environment and the importance of protected services. A successful installer and verified service operation are separate outcomes to record in the task. The business owner should know when verification is complete and who confirmed the result.

Distinguish patching from investigating suspicious activity

Breachroad recommends reporting unusual logins, configuration changes or system events to the response team. Provide the observation time, affected host, account and available change information. Preserving the history allows activity to be compared with actual administrative work and known maintenance windows.

Avoid running an arbitrary vulnerability demonstration on the backup server to establish whether the problem exists. Exposure assessment can begin with version, permissions and configuration. Where evidence suggests compromise, the coordinator should determine the scope of further investigation and a plan for safely maintaining service-recovery capability.

Finding an affected build alone does not establish whether backups have been altered. That requires findings about the particular event and environment. In management updates, separate confirmed facts, open questions and decisions needing an owner. This helps the organisation distinguish a patching task from a completed investigation and avoid unsupported assurances about recovery.

Practise the handover between teams

Imagine a fictional company where an administrator notices a former supplier’s account logging in. The on-call colleague does not know the project, while a manager asks whether service recovery remains available. In Breachroad’s exercise, the team identifies a coordinator, checks access history and prepares a message grounded in the available information.

The discussion should establish who knows the current build, who approves the change and who verifies recovery readiness. Our backup strategy guide develops the wider context. Through cybersecurity training for organisations, IT teams and managers can practise handling this report and making decisions when information is incomplete.

SHARE / COPY