Veeam Backup Vulnerability Puts Servers at Risk

You imagined that the strong backup system you built over the course of months would be your last line of protection. And then one morning you wake up and find out that the same system was the portal through which a horrific breach occurred. That's what is happening right now with a Veeam backup flaw that allows hackers to run code on your backup server from far away. It's cruel but true because the irony is true.

Backups are there to protect you from disaster. But now, hackers are actively seeking for holes in backup systems. Why? Once hackers get inside your backup, they can change the data that is stored, erase recovery points, or inject dangerous code that stays there. A number of breach reports I've read say that attackers think the backup infrastructure is "the crown jewel."

In this post, we'll talk about how Veeam's remote code execution (RCE) works, how hackers use authentication and domain misconfigurations to get into your systems, and what you can do to keep your backup systems safe for good.

The Importance of Backup Servers

When people think about cybersecurity, they usually think of firewalls, web servers, and endpoints. It's a mistake not to include backups on the "top targets" list. Backup systems maintain the last good copy of your data. This implies that if a bad person gets their hands on them, they can delete, corrupt, or poison those backups.

From the attacker's point of view, getting into backup infrastructure offers them a more stable base. The enemy can do more than just take certain files; they can also stop recovery, mess up ransom negotiations, or stay in the system without being noticed. A lot of businesses don't segregate or safeguard their backup systems adequately, so they become a soft landing zone.

The effect is significantly bigger because so many organizations utilize Veeam. A flaw in a Veeam backup can have an impact on a lot of infrastructure.

The Structure of the Most Recent Veeam Backup Security Hole (CVE-2025-23120)

CVE-2025-23120 is the main issue. In early 2025, Veeam brought out a security alert that warned their Backup & Replication software had a major hole that may enable someone to run code on a distant computer.

The strange thing is that the attack needs a domain user who is logged in, so it's not totally anonymous. But the results are quite poor. The issue is that it's hazardous to use a broken blacklist function to deserialize .NET objects over a .NET Remoting channel (BinaryFormatter).

Deserialization difficulties often let attackers send phony objects (gadgets) to run code paths that the original developers didn't mean to run. In this situation, a user can run any code they want on the backup server itself with only a little bit of access.

Veeam warned that installations that are part of a domain are at danger since anyone on that domain can utilize the deserialization path.

The Follow-On Flaw: CVE-2025-23121 Risks and Patch Bypass

You might say, "Okay, we fixed CVE-2025-23120; problem solved." But threat researchers rapidly determined that Veeam's patch could be circumvented, which led to the discovery of a new vulnerability, CVE-2025-23121.

This second RCE has a CVSS severity of 9.9 and the same prerequisites for an attack: a domain user that is logged in to a Veeam server that is part of a domain.

There is a risk of a patch bypass, which means that one patch is not adequate. You should presume that hackers will try to figure out how to break into patches and find other gadget chains in the code, especially for backup systems that are really critical.

How hackers run code from a distance in Veeam

How does Veeam truly allow you to run code from far away? The usual order is:

1. The attacker (who is known) delivers a carefully designed serialized object to Veeam's .NET Remoting endpoint.

2. Veeam deserializes it using BinaryFormatter with a blacklist filter.

3. When you turn on the bad device, it runs code, like a shell or process spawn.

4. The attacker can now get into the backup server context, which normally has SYSTEM privileges.

All the attacker needs is a mechanism to get into the system, say by phishing or stolen credentials, and then they can go higher. The smart thing is that a lot of labs thought the patch fixed all the channels for gadgets, so they left some open. WatchTowr's analysis showed that Veeam's blacklist mechanism wasn't strong enough.

Exploitation is hard, so you might not see a lot of it immediately soon. But attacks get worse when PoCs are made public. That's exactly what happened with Veeam bugs in the past.

Problems with backup systems that aren't Veeam

This isn't only a concern with Veeam; all backup methods are dangerous. A lot of backup systems provide APIs, remote interfaces, or plugins that let you send them input, such as scripts, settings, or remote control. Hackers have used:

• Backup devices that have unsafe APIs

• Using backup job scripts to get extra access privileges

• Saved backup system credentials that let credentials leak

• Backup shares that don't have the right permissions

Once, a backup program let users run any scripts they wanted before or after backup jobs. This meant that a bad operator account might get into the code.

If your network isn't well segmented and your application servers and backup systems can all access the same data, you're asking for disaster.

Ransomware, Data Loss, and Backdoor

It's not just a theory that Veeam flaws can lead to ransomware and data loss; it's happened. Groups like Akira and Fog used CVE-2024-40711 to get into networks, move sideways to backup servers, and then use remote code execution to delete or encrypt backups before starting ransomware.

It is almost impossible to get back to normal once the backup system has been hacked. Some gangs even bragged about deleting backups from hijacked Veeam servers to scare victims during ransom talks.

Why Veeam Backup Servers in a Domain Are More Likely to Be Hacked

A lot of the time, I see admins make the error of connecting the Veeam Backup & Replication server to their main Active Directory domain. Veeam's own instructions and warnings indicate not to do it.

If a domain user joins a domain, they might be able to utilize CVE-2025-23120 or 23121 to get remote code execution (RCE). If you utilize a stand-alone instance or an isolated forest instead, the attack surface gets smaller.

"I joined to get AD authentication; I didn't know it would make me vulnerable," I've heard admins claim on forums.

In short, adding backup servers to a domain makes it more dangerous. As much as possible, keep your backup infrastructure independent. Use a separate forest or a trust that is carefully managed if you need to connect to AD.

History of Vulnerability Patches: How Veeam Has Reacted

This is a general history of how the Veeam backup vulnerability landscape has changed:

• CVE-2025-23120 (March 2025): core RCE in VBR that is connected to a domain. It was fixed in version 12.3.1.1139.

• After the fix, researchers identified a method around it, which resulted in CVE-2025-23121 being made public in June 2025. Version 12.3.2.3617 repaired it.

• Also made public were CVE-2025-24286 (code execution that raises the backup operator role) and CVE-2025-24287 (local privilege escalation).

• Veeam had already found and patched bugs in 2024, such as CVE-2024-42457, CVE-2024-40717, and issues with getting credentials and running scripts.

• There is also a problem with the Veeam Azure backup tool (CVE-2025-23082) that has to do with SSRF.

There is a pattern in this patch history: using backup servers is a recurrent topic. The provider responds swiftly, but hackers are continually looking for ways to get around security.

The best way to manage Veeam patches is to follow this workflow.

Patch management is the first line of defense against any vulnerability, including Veeam Backup RCE. Based on my experience in the field, this is a methodology I suggest:

1. Make a list of all the Veeam agents and servers for the inventory and audit. Find out which ones are open or part of a domain.

2. Risk Triage: Sort by how much it will hurt the business (critical systems, test, dev).

3. Testing in Staging: Always deploy patches first in a staging clone and check that backup and restore function.

4. Rollout to Production: Focus on key infrastructure first, and then push out patches based on the environment window, with a plan for rolling back.

5. Check and keep a watch on things: After the patch, check the version, test the restoration, and keep an eye on logs and alerts for anything weird.

6. Harden and stop reversion: Don't let local admins roll back patch modifications, and keep the patch policy in place.

A lot of the time, I see that admins consider Veeam patching to be "low priority" because "backup doesn't touch users." This is a terrible mistake. Because the Veeam backup vulnerability is so serious, this patch should be one of your top priorities.

How to Use the Veeam Backup Security Update

In large settings, it is not easy to install the Veeam backup security update. You can do these things:

• Set aside time for maintenance when there isn't a lot of installation or backup work going on.

• Tell stakeholders when the backup is offline for a little while

• Use Veeam's recommended update pathways, like going from 12.3.0.x to 12.3.1 to 12.3.2.

• Just in case, make sure you have full backups before you apply the fix.

• Check that the backup repositories, job schedules, and mount services are still working after the upgrade.

You can also utilize any hotfixes that Veeam sends you to decrease the risk in the meantime if you can't obtain the full update immediately.

Be careful: you may also need to patch specific aspects, including agents and remote mount services, to fix the Veeam backup vulnerability's sidechains.

What an Attack Chain Might Look Like When You Use Veeam Backup Server

I want to show you a potential (but realistic) chain of attacks:

1. A hacker employs phishing to steal a user's domain name and password.

2. They either go up to a higher-level server on the network or migrate to a lower-level one.

3. Then they look for the Veeam Backup & Replication server, which normally has more storage space.

4. They acquire RCE using the .NET remoting interface by using CVE-2025-23120 (or 23121).

5. Because they have full power over it, they can stop backup jobs, remove backups, or introduce ransomware to the backup server.

6. They can also mess up or erase new backups or add backdoors to make it tougher to get rid of them.

This pattern is like prior times when backups have been used in breach analyses. It indicates that a lot of people think of backup infrastructure as "noncritical" or "behind the scenes," when it's really everything.

How to Make Your Backup Infrastructure Safer against RCE Attacks

It's important to patch, but that's not all you need to do. Hardening is the best way to keep your backups safe from RCE attacks. Don't connect the Veeam server directly to your main domain. Instead, keep it on its own network or VLAN. Only give admin rights to people who really need them, and turn off features you don't use, like .

NET services or remote remoting. Set up alerts and logging so you can see when something strange happens. In real-life situations, it also helps to limit which AD groups can access the Veeam management ports. You should protect the backup server more than a regular server because it is your main safety net.

Network Security Controls to Stop Veeam RCE Attacks

Network controls give you more safety, even if you do a good job of patching and hardening:

• Set up firewalls or ACLs so that only certain hosts can connect to the Veeam management ports.

• Use network segmentation to stop data from moving sideways to backup servers.

• Create rules for intrusion detection and prevention that look for patterns in serialized payload traffic or strange remote calls.

• Use zero-trust segmentation: only let protocols that are needed through and only between endpoints that have been given permission.

I've seen networks in real life where every internal subnet can get to Veeam, which is not safe. Keep track of everything and only let certain people in.

Endpoint Protection: Defense in Depth for Backup Servers

A backup server needs the same protection as any endpoint. Use a strong EDR or anti-malware tool that works deep in the system, whitelist trusted apps, and keep a host-based firewall active. Disable unused services and keep the OS, .NET, and drivers fully updated.

Since many Veeam backup exploits run hidden processes, solid endpoint protection can block or remove those threats even if remote code execution occurs

Getting around authentication, getting higher access, and other risks

RCE is just one of the threats. Some more vulnerabilities that are tied to this one include:

• Bypassing authentication: Attackers can get in if the authentication to Veeam or its administrative interfaces is weak.

• Privilege escalation: Attackers can start as a low-privilege user and work their way up to a backup operator or even the system.

• Abuse of backup operators: weaknesses like CVE-2025-24286 let operators alter backup jobs to run any code they wish.

• Credential leakage: because of earlier Veeam bugs, attackers might read saved credentials in plain text.

These are all part of the larger vulnerabilities in the backup infrastructure that an attacker might use to get more access.

When attackers access a backup server, they can view all backed-up data, delete or alter backups, and plant malicious code in restored files. This makes recovery difficult and gives hackers a hidden foothold, showing that a Veeam backup flaw is a serious organizational risk.

A list of things to do to secure Veeam Backup and Replication

This simple checklist can help you, or you can embed it:

• Write down all of your Veeam servers, agents, and mount services.

• Find out which ones are part of the domain

• Right away, patch to version 12.3.2 (or the most recent version).

• Use hotfixes if you can't upgrade directly.

• Backup servers should be separate from the rest of the network and secured by a firewall.

• Remove roles or accounts that aren't needed.

• Let logging, auditing, and alerting happen

• Turn down interfaces that aren't being used and make the operating system more secure.

• Set up endpoint detection and response (EDR)

• Check the status of patches and scan for weaknesses on a regular basis.

• Make sure that the fix works for backups and restorations.

Try this out as part of your company's security policy.

What We Learned and What We Can Do About It

A few things can be gleaned from this wave of Veeam backup vulnerability disclosures:

• Backup systems aren't an afterthought; they're the main targets.

• Patching alone isn't adequate; design, segmentation, and protection in depth are also crucial.

• Attackers will try to get around patches, so you should know that this is feasible.

• Putting sensitive systems on a domain makes the danger higher.

• When there are multiple flaws in real life, they will all connect to each other.

Backup systems took months to fix after production servers since the backup admin was at the bottom of the list of priorities at certain firms. That is a mistake that could cost you your life. You should take care of your backup infrastructure just like you do your customer-facing servers, or even more.

Don't Let Your Backup Get in the Way

In short, the Veeam backup vulnerability is a genuine concern, not simply a theoretical one. If someone can run code on your backup server from far away, your last line of defense could become your first line of weakness.

The good news is that Veeam has issued fixes for CVE-2025-23120 and 23121, as well as other problems that are connected to them. You also have tools that can aid.

But patching is just the first step. Hardening, cautious architecture, network controls, endpoint defense, and vigilant watchfulness all help keep your backup system safe. Don't let your defense mechanism turn into a weakness.

Right away, patch, isolate, and keep an eye on your backup server. Don't think of it as "just another server"; think of it as critical infrastructure.

With its Endpoint Security services, Hoplon Infosec can help keep your backup systems safe. They keep your data safe and recoverable by protecting important servers, spotting suspicious activity early, and stopping attackers from messing with backups.