Infoseccers criticize Veeam over critical RCE vulnerability and a failing blacklist

In patching the latest critical remote code execution (RCE) bug in Backup and Replication, software shop Veeam is attracting criticism from researchers for the way it handles uncontrolled deserialization vulnerabilities.

The vendor patched the near-maximum severity CVE-2025-23120 (9.9) on March 19, which can be exploited by any authenticated domain user provided the Veeam server is domain-joined. It affects Backup and Replication 12.3.0.310 and all earlier versions, Veeam said – all supported releases.

Usually, when vulnerabilities require authentication before the bad stuff can happen, The Register pops a big warning – a caveat – near the top of a report communicating that fact. They’re typically not as dangerous as their pre-auth cousins.

However, the severity score speaks for itself, and as watchTowr’s Piotr Bazydlo noted in his analysis of the bug, “the authentication requirement is fairly weak.”

He’s referring to the fact that any domain user can exploit the bugs, provided the organization in question doesn’t have a hardened Active Directory configuration. 

Veeam tries to pass some blame onto users by saying the B&R server should never be domain-joined as it goes against its best practices, but as many have already pointed out, barely anyone seems to be aware of this.

Also, as Bazydlo and Rapid7 highlighted, Veeam B&R is routinely targeted by ransomware groups, who are usually resourceful enough to gain access to at least one user account within an organization.

Further, Rapid7 added that more than 20 percent of incident response cases it was drafted to handle in 2024 involved Veeam being exploited in some way, although usually after an attacker gained an initial foothold in the victim’s network.

Domain issues aside, the bulk of Bazydlo’s criticism was directed at Veeam’s use of a blocklist-based system to mitigate deserialization vulnerabilities. He noted that whitelists are preferred and that Veeam does indeed implement one, but one of the allow list classes can lead to the inner deserialization mechanism, which itself is controlled by a blocklist.

He piggybacked off of fellow watchTowr researcher Sina Kheirkhah’s work from September on CVE-2024-40711 (9.8) – a similar RCE bug in the same product that could be exploited by gadgets missed by Veeam’s blocklist.

After it was disclosed, Veeam updated its blocklist to add the gadgets that could exploit CVE-2024-40711 but Bazydlo said this approach is always a step behind the attackers. A well-maintained allow list is the preferable approach.

He stated: “Once we figured out how to reach the deserialization sink based on the blacklist, this game becomes quite simple. Put simply – you only need to find a deserialization gadget which is not blacklisted and leads to some potentially malicious impact.”

And find a gadget he did. Two of them, in fact. With the right technical nouse, he said that the previous proof of concept exploit used for CVE-2024-40711 could be used with these gadgets too, with a little tweaking.

“Given the size of the Veeam codebase, we wouldn’t be surprised if other researchers now find numerous further feasible deserialization gadgets.”

Bazydlo blasted Veeam even further for only assigning one CVE identity to the bug despite the discovery of two separate gadgets that could be used to achieve RCE. 

“It is hard for us to be positive about this, given the criticality of the solution, combined with the well-known and trodden ground of this solution being targeted by ransomware gangs,” he added.

“We get chastised for not following someone else’s random definition of responsible disclosure, but where is the accountability for vendors who update a text file every time their solution gets popped?

“That would be all for the recent Veeam Backup & Replication RCE vulnerabilities. We hope that we have provided yet another proof that protection of deserialization sinks with a blacklist should be illegal.

“No matter how perfect, or … state-of-the-art your list is, somebody will eventually find a way to abuse it.”

The Register asked Veeam for a response. ®

READ MORE HERE