Infoseccers criticize Veeam over critical RCE vulnerability and a failing blacklist
(2025/03/20)
- Reference: 1742495594
- News link: https://www.theregister.co.uk/2025/03/20/infoseccers_criticize_veeam_over_critical/
- Source link:
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.
[1]
However, the severity score speaks for itself, and as watchTowr's Piotr Bazydlo noted in his [2]analysis of the bug, "the authentication requirement is fairly weak."
[3]
[4]
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 [5]many have already [6]pointed out , barely anyone seems to be aware of this.
[7]
Also, as Bazydlo and [8]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 [9]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.
[10]
He piggybacked off of fellow watchTowr researcher Sina Kheirkhah's work from September on [11]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 [12]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.
[13]Backup software vendor Veeam deleted forum data after restoration SNAFU
[14]Chinese spies suspected of 'moonlighting' as tawdry ransomware crooks
[15]Here's a NIS2 compliance checklist since no one cares about deadlines anymore
[16]Veeam tests support for another VMware alternative: XCP-NG
"We get chastised for not following someone else's random definition of [17]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. ®
Get our [18]Tech Resources
[1] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/patches&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2Z9yeFIp0bT2mC0zlRIfXrAAAAEg&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[2] https://labs.watchtowr.com/by-executive-order-we-are-banning-blacklists-domain-level-rce-in-veeam-backup-replication-cve-2025-23120/
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/patches&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Z9yeFIp0bT2mC0zlRIfXrAAAAEg&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/patches&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Z9yeFIp0bT2mC0zlRIfXrAAAAEg&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[5] https://infosec.exchange/@catc0n/114191617178926285
[6] https://cyberplace.social/@GossiTheDog/114191643845172404
[7] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/patches&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Z9yeFIp0bT2mC0zlRIfXrAAAAEg&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[8] https://www.rapid7.com/blog/post/2025/03/19/etr-critical-veeam-backup-and-replication-cve-2025-23120/
[9] https://www.theregister.com/2020/05/02/uks_ncsc_whitelist_blacklist/
[10] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/patches&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Z9yeFIp0bT2mC0zlRIfXrAAAAEg&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[11] https://labs.watchtowr.com/veeam-backup-response-rce-with-auth-but-mostly-without-auth-cve-2024-40711-2/
[12] https://www.theregister.com/2025/02/17/veeam_forums_data_loss/
[13] https://www.theregister.com/2025/02/17/veeam_forums_data_loss/
[14] https://www.theregister.com/2025/02/14/chinese_spies_ransomware_moonlighting/
[15] https://www.theregister.com/2024/10/24/nis2_compliance_checklist/
[16] https://www.theregister.com/2024/10/28/vmware_alternatives_veeam_gartner_xcpng/
[17] https://www.theregister.com/2025/03/17/microsoft_bug_report_troll/
[18] https://whitepapers.theregister.com/
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.
[1]
However, the severity score speaks for itself, and as watchTowr's Piotr Bazydlo noted in his [2]analysis of the bug, "the authentication requirement is fairly weak."
[3]
[4]
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 [5]many have already [6]pointed out , barely anyone seems to be aware of this.
[7]
Also, as Bazydlo and [8]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 [9]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.
[10]
He piggybacked off of fellow watchTowr researcher Sina Kheirkhah's work from September on [11]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 [12]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.
[13]Backup software vendor Veeam deleted forum data after restoration SNAFU
[14]Chinese spies suspected of 'moonlighting' as tawdry ransomware crooks
[15]Here's a NIS2 compliance checklist since no one cares about deadlines anymore
[16]Veeam tests support for another VMware alternative: XCP-NG
"We get chastised for not following someone else's random definition of [17]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. ®
Get our [18]Tech Resources
[1] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/patches&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2Z9yeFIp0bT2mC0zlRIfXrAAAAEg&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[2] https://labs.watchtowr.com/by-executive-order-we-are-banning-blacklists-domain-level-rce-in-veeam-backup-replication-cve-2025-23120/
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/patches&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Z9yeFIp0bT2mC0zlRIfXrAAAAEg&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/patches&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Z9yeFIp0bT2mC0zlRIfXrAAAAEg&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[5] https://infosec.exchange/@catc0n/114191617178926285
[6] https://cyberplace.social/@GossiTheDog/114191643845172404
[7] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/patches&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Z9yeFIp0bT2mC0zlRIfXrAAAAEg&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[8] https://www.rapid7.com/blog/post/2025/03/19/etr-critical-veeam-backup-and-replication-cve-2025-23120/
[9] https://www.theregister.com/2020/05/02/uks_ncsc_whitelist_blacklist/
[10] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/patches&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Z9yeFIp0bT2mC0zlRIfXrAAAAEg&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[11] https://labs.watchtowr.com/veeam-backup-response-rce-with-auth-but-mostly-without-auth-cve-2024-40711-2/
[12] https://www.theregister.com/2025/02/17/veeam_forums_data_loss/
[13] https://www.theregister.com/2025/02/17/veeam_forums_data_loss/
[14] https://www.theregister.com/2025/02/14/chinese_spies_ransomware_moonlighting/
[15] https://www.theregister.com/2024/10/24/nis2_compliance_checklist/
[16] https://www.theregister.com/2024/10/28/vmware_alternatives_veeam_gartner_xcpng/
[17] https://www.theregister.com/2025/03/17/microsoft_bug_report_troll/
[18] https://whitepapers.theregister.com/
Re: Unknown best practice?
Anonymous Coward
Didn't manage to edit my post on time. As for the actual vuln? Ouch!
Re: Unknown best practice?
Anonymous Coward
Indeed, i've setup several Veeam solutions in enterprise environments and not once have they been domain-joined. It wouldn't even occur to me to do so, so the fact this unknown knowledge (at least according to this article) is a worry.
"Blocklist" ???
Alan Mackenzie
What's this nonsense with "blocklist"? A blocklist is a list of blocks, such as might be allocated in a file system or any number of similar things.
It took me several minutes to work out what you were talking about. What you were talking about was a BLACKLIST, a word instantly recognised and understood. Particularly when you contrasted it with "whitelist".
We're (mostly) robust adults reading and commenting on the Register. There is nothing whatsoever offensive about "blacklist". Please use it in the future when it's the correct word.
Thanks!
Re: "Blocklist" ???
Anonymous Coward
Because it is immediately obvious that black is bad and white is good?
Whitelist
Anonymous Coward
"but one of the allow list classes can lead to the inner deserialization mechanism, which itself is controlled by a blocklist."
Funny.
Unknown best practice?
We have been using Veeam for maybe 7 years now, and it was clear from day 1 that it makes sense for the backup server to not be domain joined. So when we then saw it in the best practices documentation (you know, that important stuff when implementing something) it was of no surprise whatsoever. I would class myself as pretty amateur working for a small company with a two person IT team - the proverbial Jack of all trades, master of none.
So I am a tad confused as to how people don't seem to be aware of something so basic.