CVE-2026-108142: Veeam CDP Authorization Bypass and Fixes

CVE-2026-108142 is an unauthenticated authorization bypass in the Veeam CDP Coordinator Service. Veeam rates it Critical, with a CVSS 4.0 score of 9.1, and lists both Windows-based Veeam Backup & Replication and Veeam Software Appliance deployments. The immediate task is to identify the backup server’s release branch and install its corresponding fixed build. The advisory does not describe a verified remote-code-execution chain. Those details come from Veeam security advisory KB4948, published October 27, 2026.

A backup system is part of the recovery plan for everything around it. Updating it therefore needs two outcomes: the vulnerable deployment is repaired, and the organization can still perform the protection and recovery operations it depends on. A successful installer is evidence of progress. Closure requires checking the running server and its legitimate workflows.

This assessment uses the public records available on October 28, 2026. The practical recommendations below are defensive engineering guidance; no production exploit or Veeam-specific bypass request is presented.

Affected versions and the correct fixed branch

Use the complete server build when assigning the update. A console version, installer filename, or broad “version 13” inventory field can leave the relevant branch unresolved. KB4948’s affected-product and solution sections give the following boundaries.

The two fixed builds are alternatives for different branches. Do not turn them into a single numeric threshold. A check that compares every installation against 13.1.2 would incorrectly classify a repaired 13.0 deployment. Record the product and branch beside the full build, its collection time, and the method used to obtain it.

Confirm the selected update against Veeam’s version 13 release information. That record also explains the update distribution process. An update becoming available and an update being installed on a particular server are separate events; record the latter directly.

The authorization boundary is the useful technical focus

について published CVE record associates the issue with CWE-636, failure to fail securely. Its CVSS vector includes no required privileges or user interaction, but it also includes attack requirements. The record does not explain the precise request, exception path, or deployment condition behind those requirements. “Unauthenticated” should not be expanded into an invented universal attack recipe.

Authentication establishes who is calling. Authorization decides whether that caller may perform a particular operation. A protected administrative login can coexist with a flaw in another service’s authorization checks. Consequently, documenting MFA on a management interface does not establish that the affected service boundary is repaired.

Veeam’s universal CDP infrastructure documentation places the coordinator on the backup server. This makes server identity more useful than a generic list of protected workloads. A workload’s healthy backup status is not a version check for the service coordinating its protection.

The defensive model separates four questions: can a source reach the service, which identity is established, what authorization decision is enforced, and which operation follows that decision? Network restrictions can reduce the first condition. A supported software repair addresses the product defect. Treat these as separate controls with separate evidence.

Inventory the actual service without attempting the bypass

Begin with the backup management inventory and confirm the server locally or through its approved management system. Record whether it is Windows-based or an appliance, who owns it, its full build, and the update mechanism in use. Include secondary, recovery, test, and temporarily disconnected backup servers when they belong to the same operational estate.

On a Windows backup server you administer, the following read-only PowerShell query can help locate the service. Veeam documents the service name in its service and component reference.

Get-Service -Name VeeamBackupCdpSvc |
    Select-Object Name, Status, StartType

A result shows service presence and current state. It does not establish that the binary is affected or repaired. An absent result should lead to checking the deployment type and inventory accuracy; it should not automatically produce a “not affected” finding. Use the product’s server build and applicable vendor guidance for the vulnerability decision.

Next, map permitted sources and paths to the relevant services. Consult the direction-specific entries in Veeam’s port matrix. A port used by one CDP component is not automatically the vulnerable listener, and a firewall rule for workload traffic is not necessarily a rule protecting the coordinator. The advisory does not identify a single port whose closure proves remediation.

For each claimed restriction, retain the enforcement point, source scope, destination, and validation method. Prefer configuration review and approved observations of ordinary traffic. Avoid malformed requests against production backup infrastructure merely to make a finding look more concrete.

A local model of failing closed

The following original Python example demonstrates an authorization property: unavailable or negative permission evidence must not authorize an operation. It is an offline model, not a reconstruction of Veeam’s code or a test for CVE-2026-108142. It opens no sockets and uses no credentials.

def decide(principal, action, permission_lookup):
    if principal is None:
        return False
    try:
        allowed = permission_lookup(principal, action)
    except LookupError:
        return False
    return allowed is True


def normal_lookup(principal, action):
    return principal == "lab-operator" and action == "view-status"


def unavailable_lookup(principal, action):
    raise LookupError("synthetic permission service unavailable")


assert decide(None, "view-status", normal_lookup) is False
assert decide("lab-operator", "view-status", normal_lookup) is True
assert decide("lab-operator", "change-policy", normal_lookup) is False
assert decide("lab-operator", "view-status", unavailable_lookup) is False
print("Synthetic authorization checks passed")

The positive control matters. A function that rejects every operation also rejects unauthorized access, but it fails the service’s legitimate purpose. Meaningful repair validation asks for both properties: prohibited operations remain prohibited, and approved work continues under its intended identity.

The example deliberately does not infer the vendor’s implementation. Public records are sufficient to choose an update without being sufficient to reproduce the defect. Treat a claim of exploitability from a third-party script as a separate research claim requiring its own provenance and evidence.

Prepare the update around the recovery requirement

Before scheduling the change, establish what the server protects and what interruption the protection owner can accept. Identify running jobs, CDP dependencies, recovery objectives, and the person who can decide whether an unexpected result requires escalation. This preparation turns a generic instruction to patch into a change that the operations team can execute.

用途 Veeam’s upgrade checklist for the supported route and prerequisites. Do not infer that an arbitrary installation package can be applied to every previous build. The correct route depends on the actual starting configuration.

Protect the configuration before changing the service. Veeam documents a supported process for running configuration backups manually. A configuration backup serves a different purpose from a protected workload’s restore point. Confirm that the people responsible for recovery can locate the required material and satisfy its access requirements if the management server is unavailable.

Keep evidence free of secrets. A change ticket needs confirmation that recovery material exists and is accessible to the designated custodians; it does not need exported credentials, encryption passwords, or a database attachment. Preserve sensitive material through the organization’s established recovery process.

Define the fallback before the maintenance window. Returning to an affected build would reopen the vulnerability decision. If rollback becomes necessary, restore the asset’s unresolved status and retain any effective temporary restrictions while the owner chooses the next supported repair.

Verify the running server and the protection workflow

After applying the branch-appropriate repair, collect the server build again. Tie that observation to the same asset identified before the change. A screenshot from an administrator’s console or a completed deployment batch can be misleading if it refers to another server or only to downloaded media.

Check the services and component states expected for the deployment, then exercise ordinary protection activity. Review job results against the pre-change baseline. Where CDP is used, have its owner verify the required operation rather than accepting a successful unrelated backup job as a substitute.

Include a representative recovery test in the acceptance plan. Define the object, restore destination, success condition, and data-handling requirements before execution. The purpose is to show that the maintenance preserved the recovery capability the organization actually needs; it is not a request to perform a disruptive production failover.

For a failed or deferred update, retain the specific error and next owner. Avoid a fleet-wide green status derived from a mostly successful rollout. The remaining backup server may protect an unusually consequential recovery path.

Keep historical investigation separate from repair

The reviewed advisory and CVE record do not establish active exploitation in the wild. That is a statement about the reviewed evidence, not a guarantee that exploitation is impossible or that every public report has been assessed.

If there are independent reasons to suspect misuse, preserve relevant logs and configuration history through the incident process. Investigate unexplained administrative changes, abnormal job behavior, service events, and unexpected access within the period when the server was exposed. These are investigation leads, not published indicators specific to this CVE.

Do not manufacture a detection rule around an undocumented endpoint or packet. Without a verified request signature, a precise-looking rule may create false confidence. A sound handoff describes which observations exist, which identities and operations were reviewed, and what remains unknown.

Frequently asked questions

Is CVE-2026-108142 a confirmed remote-code-execution vulnerability?

• The public description identifies an authorization bypass. Do not promote it to an established code-execution chain without additional primary evidence.

Should every Veeam version be classified as affected?

• No. Use the branch matrix above. A finding for another Veeam issue or a general product match does not expand this CVE’s stated scope.

Does enabling MFA resolve the issue?

• MFA on a management login is useful, but it does not demonstrate repair of the separate service authorization boundary. Complete the applicable update.

Can a scanner close the finding from a version banner?

• Treat the banner as an inventory lead. Confirm the actual server, branch, full build, and active deployment before accepting a remediation result.

Should CDP services simply be stopped?

• Assess the protection and recovery consequences with the service owner. An emergency restriction needs a defined scope and recovery plan; it is not a universal replacement for patching.

What is a useful completion record?

• Retain asset identity, starting and observed final builds, the supported update route, relevant service checks, protection and recovery results, time, owner, and any unresolved exceptions.

The repair is ready to close when the backup owner can identify the updated server, explain the supported branch choice, and show that protection and recovery still work. Any missing connection should become a named follow-up action rather than an assumption carried into the next incident.