Read-only in the backup console was not read-only

In the advisory Veeam published on 6 October, the permission it takes to run code on the backup server is the one for looking. The role is called Backup Viewer, it touches nothing, deletes nothing, starts nothing, and it is the one granted without calling a meeting because it is there to check whether the jobs came out green.

The advisory is KB4934, published on 6 October 2026 alongside Veeam Backup & Replication 12.3.2 P4, build 12.3.2.4934. It carries three vulnerabilities. They affect build 12.3.2.4854 and every earlier version 12 build; version 13, the advisory says, is not affected. No interim mitigation: there is no workaround section.

Three flaws, and two are triggered by the same role

A practical note before going on: two of the three identifiers belong to the 2025 series and the third to the 2026 one. Search by year and they will not come up together, and if your vulnerability inventory sorts by identifier date, these three will not land on the same screen even though they arrive in the same advisory and are fixed by the same build.

PR:L is the part that changes the conversation

The vector of the serious one, exactly as Veeam publishes it:

CVE-2025-64393
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H

Read it left to right and it is a list of obstacles that are not there. AV:N, over the network. AC:L, no race conditions, no exotic configurations. AT:N, no prerequisites. UI:N, nobody has to click anything. And PR:L: low privileges, not none. That is the only toll, and in the shops we see it tends to be paid in advance.

The tail of the vector is the part usually skipped, and here it says something. The first three impacts, VC:H/VI:H/VA:H, belong to the vulnerable system: the whole backup server. The next three, SC:H/SI:H/SA:H, are the category CVSS 4.0 reserves for subsequent systems, that is, for impact landing outside the vulnerable system. Veeam marks those three high and stops there: it does not say which systems those are. Naming them is ours to do, because off a backup console hang the hypervisor credentials, the repository credentials and the storage array credentials.

Who holds Backup Viewer in your console?

That is the advisory's question, even though the advisory does not ask it. The read-only role exists to be granted without a meeting, and it goes to whoever asks "can I check myself whether last night's backup went through?". The reasonable answer to that question is yes.

The usual suspects, in order of how likely they are to be on your list with nobody remembering: the account the monitoring system uses to read job status; the service desk group, so they can answer "yes, there is a backup" without escalating; the consultant from the last audit; the supplier given visibility during a migration that has already finished; and the account of somebody who has left, still inside a directory group that carries the role. None of those grants was a mistake when it was made. The 6 October advisory is what reclassifies them.

The 6.1 touches the key to the safe

The second CVE is scored 6.1, medium, and it is the one we think its number explains worst. What it allows is modifying or deleting the Enterprise Manager master key. Veeam's documentation describes that keyset as a pair of matching keys: the public one encrypts storage keys on the backup servers connected to Enterprise Manager, and the private one decrypts those storage keys "in case a password for encrypted backup or tape is lost". That is, it is the documented mechanism for when somebody loses the password of an encrypted backup.

We are not going to say that deleting that key leaves you without backups, because we do not know and it depends on how many passwords you have written down and where. What we will say is more uncomfortable than it sounds: the documented escape route for the day password management fails was within reach of a read-only account, and that scores 6.1 because impact is measured against the product and not against your ability to recover. The action that comes out of this, on top of patching, is exporting the keyset to a file and keeping it off the backup server. And that is not our idea: Veeam's own documentation asks for it in so many words, "It is important to regularly back up your Enterprise Manager keys or save their copies in a safe place".

There is no workaround. There is a list

The KB offers no temporary mitigation, and that is honest: with a deserialisation flaw in an internal service there is no firewall rule that half-saves you. The fixed build is 12.3.2.4934 and that is that. But between reading this and getting the change window to touch the backup server —which in many shops is the least-touched box, because it works and because nobody wants to be the one who broke the backups— there is work that needs no window at all: finding out who holds the role.

In the console it lives under Users and Roles. If you would rather dump it to a file and compare the list six months from now, Veeam's PowerShell reference documents Get-VBRUserRoleAssignment, which returns RoleEntity, Role, Type, Name and Id. The output is a handful of lines of text, and those lines are the inventory missing from your recovery plan.

Why it hurts more here than on another server

An RCE on an application server is a bad day. An RCE on the backup server is a bad day where you also lose plan B, because the compromised box is the one holding the credentials that reach everything else and the one deciding what is retained and for how long. We have written this here in several shapes: when the backup server sits in the same domain as what it protects, the dependency is circular and invisible until it matters; and immutability falls short if a permission exists that deletes the object before the lock ever counts. This advisory adds a third route to the same place, and it is the cheapest of the three: a read-only account.

Nor is it the first time this console's privilege surface shows up in an advisory: back in September we covered a CVE where what leaked was an administrator ticket written into a log. Veeam has bugs like everyone else and publishes them in detail, with vector and fixed build, which is how it should be done. What repeats sits one floor below: the recovery plane accrues privilege in layers and nobody audits it as often as they audit the directory.

The order we would work in

What we are not claiming

With one console and four accounts, this is half a morning and you need nobody: check the build, print the roles, schedule the upgrade. It gets complicated when the recovery plane has been growing for years —an inherited Enterprise Manager, repositories in three places, a directory group nobody remembers creating— and the question "who can get into the backup console" has no written answer anywhere. That inventory, and the plan built on top of it, is exactly the work of a disaster recovery plan, and it is what we sell, so take it with the conflict of interest up front. If your people already have it mapped, good, and you owe us nothing. If point 2 made you wince, let us talk.

Sources