Veeam Management Pack 13.1 Fixes Three RCE Flaws

Veeam Management Pack RCE fixes ship in version 13.1, build 13.1.0.334. Veeam’s 29 October advisory covers three remote code execution vulnerabilities, including a critical flaw that needs no login. Teams running Management Pack 9.x need an upgrade, because Veeam will not issue a fix for that branch.

Last updated: 29 October 2026. Veeam published and last modified KB4961 on 29 October 2026.

One Product, Three Different Access Conditions

The table sets out the service at risk and the access an attacker needs. Veeam rates the unauthenticated Virtualization Extensions vulnerability Critical at 9.3 under CVSS v4.0. The two Collector vulnerabilities are High, but they need different access and can cause different harm.

FIRST’s CVSS v4.0 user guide says Base scores measure severity and should not be used alone to assess risk. For this patch decision, combine Veeam’s scores with each service’s access conditions; the score alone does not confirm exploitation.

For the critical vulnerability, Veeam describes code execution on servers running the Veeam Virtualization Extensions service. Its vector lists no required privileges and no user interaction. These are the attack conditions. They do not show that every host can be reached from the internet.

The 8.8 Collector vulnerability requires membership in the Veeam Virtualization Extensions Users group. Veeam’s vector also includes passive user interaction, so group membership is not the only condition shown. The advisory does not explain that interaction, and the table should not be read as a complete exploit recipe.

The 8.7 Collector vulnerability allows an authenticated domain user to run code as LocalSystem on a server running the service. That is a different access condition from the named group requirement above. Our remote code execution definition explains the consequence of running code on another system.

The Compatibility Patch Leaves 9.x in Scope

For all three findings, Veeam’s KB4961 advisory lists Management Pack 9.1 and every earlier version 9 build as affected. It also includes the Veeam Backup & Replication 13 compatibility patch. Installing that compatibility patch therefore does not remove a Management Pack server from the affected scope.

Veeam says unsupported product versions were not tested but are likely affected and should be treated as vulnerable. It names 13.1.0.334 as the first fixed build for each finding. The vendor’s stated action for 9.x customers is to upgrade, rather than wait for a 9.x fix.

This is separate from our 27 October Backup & Replication and Veeam ONE patch coverage. Those products have their own advisories and fixed builds. A closed Backup & Replication change ticket is not evidence that Management Pack has reached 13.1.0.334.

Match the Upgrade Route to the Installed Components

Start by recording the Management Pack version on each server that hosts the affected services. List the Virtualization Extensions host and the Collector hosts on their own, even when one team owns them. This is a proposed admin workflow drawn from the advisory, not an upgrade we tested.

Check the starting release before scheduling the change. Veeam’s VMware Management Pack upgrade guide supports upgrading to version 13 from version 9a only. The security advisory uses the label 9.1; the guide uses 9a, so confirm the supported route for the installed build.

Do not assume every affected 9.x release can jump straight to 13.1. Veeam’s VMware guide covers management packs and the core services first, then additional Collectors. Its detailed setup instructions also require a license file, so check that need before the change window.

Veeam’s additional Collector upgrade instructions warn against moving monitoring jobs between Collectors on different versions during the change. Include remote Collector hosts in the plan, rather than closing the task after the Management Server upgrade alone.

After the upgrade, record the installed Management Pack build on each host in scope and compare it with the advisory’s fixed build. Check that normal monitoring still works before closing the task. Our patch management process explains why installing an update and verifying its result are separate steps.

Keep the Vendor Identifiers and Evidence Limits Visible

KB4961 prints CVE-2023-22793 for the critical finding and CVE-2026-107239 and CVE-2026-107238 for the Collector findings. We use those IDs as Veeam lists them. Their exact public CVE records could not be confirmed through the CVE Program API during our 29 October check.

The CVE Program’s archived FAQ on CVE ID years says the year can reflect ID assignment or an earlier public disclosure. A 2023 prefix alone therefore does not prove public disclosure in 2023. Until the identifiers can be confirmed, use the product, service and fixed build to scope the change. We have not guessed a new ID for any vendor entry.

Keep severity and evidence of an attack separate in the vulnerability management workflow. Assign an owner to each Management Pack host still due for an upgrade and keep the installed-build evidence with its change record. If the supported upgrade route is unclear, resolve it with Veeam Support before treating the ticket as complete.