Veeam: two criticals in 21 days, and each one spares the branch the other sinks

On 7 October we wrote here about a Veeam advisory and repeated, because the vendor said so, that the 13 branch was not affected. That sentence lasted twenty days. On 27 October Veeam published KB4948 with a 9.1 critical hitting 13.0 and 13.1, and repeating the same note under each CVE: "Older versions (e.g., 12.x) are not affected." Two advisories, twenty-one days apart, and each one's reassuring clause points precisely at the branch the other sinks.

We're not telling this as a curiosity. We're telling it because the usual way to read an advisory is "does this hit me or not?", and in October the correct answer for a Veeam estate was "it hits you twice, three weeks apart, for different reasons." Anyone who stayed on the 12 branch to avoid the churn of 13 dodged the second one and took the first. Anyone who moved to 13 did the reverse. There was no branch to sit still on.

The two advisories, side by side

The "interim mitigation" row is the one that sets the pace. Neither advisory publishes a temporary workaround: the only answer the vendor offers is to move up a build. That turns a backup server into a component you must be able to stop and update at short notice, twice in three weeks, without anyone having to email three departments for permission. If your change window for that machine is quarterly, October's calendar doesn't fit in it.

The 9.1 moves faster than the 9.4, and the number doesn't say so

Sort them by score and the 6 October one comes first. Sort them by what it takes to pull the trigger and the order flips. The vectors, copied as they stand:

CVE-2025-64393  (9,4)  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
CVE-2026-108142 (9,1)  CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:H/SA:H

The two letters that matter are PR and AT. PR:L on the 9.4 means the attacker needs an account with some privilege; in that specific case, the Backup Viewer role, the one handed out so somebody can check whether the jobs came back green. PR:N on the 9.1 means they need none at all. In exchange, the 9.1 carries AT:P: there is a precondition the attacker does not control. The 9.4 carries AT:N, no conditions.

We wrote at length about the Backup Viewer role at the time, when we argued that read-only in the backup console wasn't read-only: the toll on that 9.4 was precisely the permission most freely handed out. What is new this month is that the 9.1 charges no toll at all.

Where the new flaw lives: the CDP service

The affected component is the Veeam CDP Coordinator Service, which runs on the backup server itself. Its job is to talk to vCenter, hand out continuous-protection tasks and manage the pieces involved in them. In Veeam's port table it shows up with two entries worth separating: 9509 is local, so the backup service can talk to the coordinator inside the same machine; 33034 is the one that listens for connections from CDP proxies, ESXi hosts and vCenter. The second is the one that matters here. The table documents those three sources and no others; that anything which isn't one of the three has no business on that port is our reading, not a vendor recommendation.

And here is a calendar detail that changes the size of the problem. For years, Veeam's continuous protection was a VMware vSphere-only feature, built on VMware's I/O filter (VAIO). In 13.1, released on 29 July 2026, Veeam shipped Universal CDP, which moves I/O capture out of the hypervisor API and extends continuous protection to other platforms; the product page sums it up as "near-zero RPO for Linux workloads with Universal CDP". Put another way: the component where the unauthenticated flaw turned up is, in exactly the branch where it turned up, the one that stopped being the concern of vSphere shops only.

What the advisory doesn't tell you, which is exactly what you need

The advisory lists affected builds and fixed builds. What it never says is whether the CDP Coordinator Service is up and listening on every installation in the 13 branch, or only where continuous-protection policies are configured. That difference is what separates "this affects me" from "this affects other people", and the document doesn't let you answer it. So don't answer it by reading: go and look at the machine. In this order, and don't skip the first one because you think you know it:

• The exact build, not the branch. "We're on 13" is no answer: the line sits at 13.1.1.18 and 13.0.2.29. It shows under Help > About in the console.
• Whether 33034 is listening on that server, and from where it can be reached. A service that isn't listening can't be attacked over the network; one that listens and accepts half the company can.
• Who holds the Backup Viewer and Restore Operator roles. They are the toll on the other flaws in the pair of advisories.
• The Linux agent version, which moves on its own schedule and has its own CVE in the same advisory.

# Windows (servidor de copias)
netstat -ano | findstr ":33034"

# Veeam Software Appliance / Linux
ss -lntp | grep ':33034'

# desde otra maquina: ¿a quien le responde?
nc -zv <servidor-de-copias> 33034

The third command is the one that actually tells you something, because it asks who can reach it rather than what is installed. If it answers from the admin laptop, from the user network, or from anywhere that isn't a CDP proxy, an ESXi host or vCenter, you have two jobs ahead of you: raise the build and then fix the reason that port was open to the wrong people. The patch closes this flaw; the network reach leaves you exposed to the next one.

The other three CVEs in the same advisory

KB4948 doesn't only carry the critical. It carries two mediums, CVE-2026-108140 and CVE-2026-108141, both 5.9 and with the same description: an authenticated user with the Restore Operator role who also controls the contents of a backed-up NAS share can write attacker-controlled files to an arbitrary path on the backup server, via relative path traversal. That second condition is not a footnote, and Veeam scores them PR:H, not PR:L: in its own reading, that role counts as a high privilege. And it carries CVE-2026-105477, a 7.3 local privilege escalation in the Veeam Agent for Linux, affecting 13.1.1.4 and earlier 13.1 builds and fixed in 13.1.2.11.

The role behind the two mediums deserves a note. Restore Operator is, by design, the permission you give someone so they can recover things without being an administrator of the backup server; that is, the permission every properly separated recovery plan depends on. Two of the four flaws in this advisory are triggered from roles that exist precisely so you don't have to hand out the administrator one. Separating duties is still right; what you can't do is describe the small role as harmless.

The part no patch fixes

October made one thing clear, and it is more uncomfortable than any of the four CVEs: the backup server is a target, not a spectator. It has its own advisory cadence, its own listening services and its own distributed roles, and none of that depends on how well you take backups. It is one more server, with the peculiarity that it is the one that has to stay standing when the others aren't.

The practical consequence is about isolation, and we already worked through it when we explained why a backup server inside the domain is a circular dependency: if the machine that saves you shares authentication and network with whatever went down, it doesn't save you. October adds a calendar layer on top: anyone who needs sign-off from three departments to touch that machine will be late for the next advisory, and there will be a next advisory.

At everyWAN this falls under compliance and continuity, because the RTO and RPO you sign up to in a plan depend on one specific machine someone has to keep standing and current, and under IT maintenance, where the boring part lives: the build inventory and the patching cadence. We'll say it plainly, because it is what we see: almost nobody has written down anywhere which build of their backup software is running today, and that is the first thing either of these advisories asks for.

And one more thing, for the sake of honesty: none of this says Veeam is worse than anyone else. A vendor that publishes four CVEs with vectors, exact builds and dates is doing its job; silence would be far worse news. What October demonstrates isn't about brands: the "I'll stay on the previous version until the new one matures" strategy is not a defensive position. It is simply a different bet.

Sources. CVE-2026-108142, CVE-2026-108140, CVE-2026-108141 and CVE-2026-105477, with their scores, affected builds, fixed builds and the sentence "Older versions (e.g., 12.x) are not affected" — Veeam advisory KB4948, 27 Oct 2026. CVE-2025-64393 and the note that v13 was not affected — Veeam advisory KB4934, 6 Oct 2026. Ports 9509 and 33034 for the CDP Coordinator Service and the documented sources for each — the ports table in Veeam's documentation. "Near-zero RPO for Linux workloads with Universal CDP" — Veeam Data Platform 13.1 product page; the general-availability date, 29 July 2026, comes from Veeam's press release, not from the product page. That continuous protection was exclusive to VMware vSphere until 13.1 and relied on the VAIO filter is documented by Chris Childerhose on the Veeam community; that is a community source (Veeam Legend), not official documentation, and we flag it as such. The side-by-side reading of the two vectors and the hypothesis about AT:P are ours and are marked as such in the text. Declared dedupe: we published KB4934 and the Backup Viewer role on 7 Oct 2026; what is new here is KB4948, the symmetry between the two branches and how it fits with Universal CDP. Sentences from the advisories are reproduced in their original English; the one from the product page is translated. Identifiers, scores, vectors and builds are reproduced verbatim.