Back to Articles
critical

CRITICAL: Veeam Service Provider Console CVE-2026-58073 Allows Unauthenticated Credential Theft

Veeam patched four flaws in Service Provider Console, the multi-tenant console that MSPs and hosting providers use to manage customer backups. The most severe, CVE-2026-58073 at CVSS 9.5, lets an unauthenticated attacker impersonate a managed agent and steal that agent's credentials. Every version 9 build through 9.2.1.33875 is affected, and build 9.3.0.35057 is the fix.

By Danny Mercer, CISSP — Lead Security Analyst Aug 6, 2026
Is your business exposed? Our McKinney-based security team can assess your risk for free.
Share:

Backup infrastructure is the quiet part of the attack surface. It rarely shows up in the quarterly business review, nobody demos it to the client, and yet it holds credentials for every system it protects. Veeam just shipped fixes for four vulnerabilities in Service Provider Console, and the worst of them lets an attacker with no credentials whatsoever impersonate a managed agent and walk off with that agent's identity.

For managed service providers, this one belongs in the drop everything and patch it now bucket. Service Provider Console is not a piece of software that sits on one customer's network. It is the multi-tenant management plane that hosting companies and MSPs use to run, monitor, and report on backups across their entire client base. One console, many downstream customers. That architecture is exactly what makes it efficient, and exactly what makes it worth attacking.

What Veeam actually fixed

The headline flaw is CVE-2026-58073, rated 9.5 under CVSS version 4.0 with a vector of CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H. Veeam describes it plainly in KB4893 as a bug that allows an unauthenticated attacker to impersonate a managed agent and obtain that agent's credentials. It carries a CWE-288 classification, which is the authentication bypass family, and it arrived through Veeam's HackerOne program rather than internal testing.

Read that vector carefully before you panic, and also before you relax, because both reactions are available. PR:N and UI:N mean no privileges and no user interaction are required. AV:N means it is reachable over the network. Those are the ingredients of a genuinely nasty pre-auth bug. The moderating factor is AC:H, high attack complexity, which in CVSS 4.0 terms means the attacker has to beat conditions outside their direct control. Unauthenticated does not automatically mean trivial. It also does not mean safe, and the scope metrics at the end of that vector, all six of them rated high, tell you what happens if somebody does beat those conditions. Confidentiality, integrity, and availability fall over both in the vulnerable component and in whatever sits downstream of it.

Right behind it is CVE-2026-58072 at CVSS 9.0, vector CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H. This one allows an arbitrary file write on the management server, which Veeam acknowledges can lead to remote code execution. It needs a low privileged account rather than nothing at all, and the attack complexity drops to low. In practice that combination is often the more realistic path. Attackers who have already phished a junior technician's portal login, or who simply bought one from a broker, now have a route from a limited account to code execution on the console that manages every tenant.

The other two are high severity rather than critical, and they still deserve your attention. CVE-2026-58067, at 8.7, lets an unauthenticated attacker exhaust host memory and knock the console over, which is a denial of service against your entire backup visibility layer at precisely the moment you would most want it working. CVE-2026-58071, at 8.2, exposes the proxied appliance API at Portal Administrator level during a short window right after an administrator session begins. Race conditions like that read as exotic on paper and turn out to be depressingly practical once somebody writes a loop.

Who is exposed

Every version 9 build up to and including 9.2.1.33875 is affected. The fix is build 9.3.0.35057, and there is no partial patch or configuration flag that makes the older builds safe. Veeam published the advisory as KB4893 on August 4, and this is a full version upgrade rather than a hotfix, which means it needs real change control rather than a Tuesday afternoon click.

The good news, and it is genuinely good news for once, is that as of this writing none of these four CVEs appears in CISA's Known Exploited Vulnerabilities catalog, and no public proof of concept has surfaced. That is a window, not an all clear. Veeam products have a well documented history of going from advisory to mass exploitation faster than most organizations complete a change request. Ransomware crews have spent years specifically hunting backup infrastructure, because an operator who can reach your backup console does not have to break your encryption. They can delete or corrupt the restore points first and then detonate, which turns a bad week into an existential conversation with your insurer.

Attack complexity being rated high on the worst bug buys defenders time. It does not buy them a pass. The people who reverse engineer these patches for a living are looking at the diff between 9.2.1.33875 and 9.3.0.35057 right now, and what counts as high complexity for a random opportunist is routine work for a dedicated crew.

What exploitation would look like

Since there is no public exploit yet, what follows is informed extrapolation rather than observed tradecraft, and it deserves that label. For CVE-2026-58073, the plausible shape is an attacker who can reach the console's agent communication endpoint over the network, presents themselves as a legitimate managed agent, and receives credentials belonging to that agent. Those credentials are the interesting part. Agent credentials in a Service Provider Console deployment are the connective tissue between the console and customer environments, so the prize is not the console itself, it is the lateral path into tenants.

That gives defenders something concrete to hunt for. Look for agent registrations or re-registrations that do not correspond to a technician actually doing work, especially from source addresses outside your normal management ranges. Look for a single source address enumerating agent identifiers, or repeated failed agent handshakes followed by a sudden success. For CVE-2026-58072, the detection story is more familiar, since arbitrary file write leading to code execution almost always leaves artifacts. Watch for unexpected files appearing in web accessible directories on the management server, new or modified executables and scripts outside the normal patch window, and the console service process spawning command interpreters. If your endpoint tooling can alert on the console service account launching anything resembling a shell, turn that on today.

What to do about it

Upgrade to 9.3.0.35057. That is the entire remediation, and everything else in this section is a stopgap for the hours or days until you get there.

Until you do get there, the single most valuable control is network exposure. Veeam Service Provider Console has no business being reachable from the open internet on its management and agent ports, and if yours is, that is a finding independent of these four CVEs. Restrict inbound access to known customer ranges and your own management network, put the portal behind a VPN or a reverse proxy that enforces authentication ahead of the application, and confirm the restriction actually holds by scanning yourself from outside rather than by trusting the firewall rule you believe you wrote in 2023.

Beyond the patch itself, this is a reasonable moment to review who holds Portal Administrator and low privileged portal accounts, because CVE-2026-58072 turns any stale technician login into a stepping stone. Enforce multifactor authentication on every portal account without exception. Rotate agent credentials after you patch, since fixing a credential disclosure bug does not retroactively un-disclose anything an attacker may already have taken. Pull your console logs for the last several months and check them against the hunting ideas above before retention overwrites them, because if something did happen, the evidence is on a clock.

Finally, verify that your backups are immutable and that at least one copy is genuinely offline or sitting in an object lock tier the console cannot alter. The entire threat model here is an attacker reaching the system that controls backups. Immutability is what keeps that from being the end of the story rather than the middle of it.

The MSP business angle

This is a rare vulnerability where the affected product is the MSP's own toolchain, which makes it an honest conversation starter rather than a fear pitch. Clients whose backups you manage through Service Provider Console deserve a short proactive note saying you were aware within days, you patched, and here is what you verified afterward. That one email does more for renewal season than a quarter of marketing spend.

The upsell writes itself from there. Backup infrastructure hardening reviews, immutable and air gapped storage tiers, and management plane segmentation are all services clients understand the value of the moment you explain that ransomware operators go after restore points before they go after data. Add darkweb monitoring for portal credentials to that bundle, because CVE-2026-58072 specifically requires a low privileged login, and a credential surfacing in a dump is now a documented step on a path to remote code execution against a system that touches every tenant you manage.

References

Concerned about this threat?

Our security team can assess your exposure and recommend immediate actions.

Get a Free Assessment →