Backup and recovery company Veeam on March 19 released a patch for a critical 9.9 deserialization vulnerability in its backup and replication product that could let attackers run a remote code execution (RCE).
The danger here: A flaw in Veeam storage that’s gets exploited can potentially compromise the security of backups, leading to ransomware attacks, data breaches, and business disruptions because backup and replication servers often contain critical data and are vital for recovery.
Veeam, which reportedly supports 550,000 customers worldwide, said in its advisory that the flaw — CVE-2025-23120 — affects Versions 12.3.0.310 and all earlier Version 12 builds. Researcher Piotr Bazydlo of watchTower first reported the flaw to Veeam.
In its March 19 blog post, watchTowr said if security teams had not patched their Veeam server and it’s joined to the organizations Active Director domain: “you are probably in real danger.”
This was Veeam’s second try at patching the deserialization flaw. The danger with this type of flaw is that when an application deserializes data that it receives from an untrusted source such as a user, network, or database without checking its integrity, attackers can inject malicious code or data that when deserialized, can compromise the application.
“It seems that Veeam has tried to address previous deserialization exploit vectors by adding to their deserialization block (black) list,” explained Casey Ellis, founder at Bugcrowd. “This fix would mitigate known code paths leading to exploitation of deserialization. However, it doesn’t address unknown code paths that exploit the same root problem. While Veeam could add to the block list to mitigate the new issues, it’s basically the equivalent of playing whack-a-mole across a large codebase. The better approach would be to default deny, and instead control access to deserialization through an allow list.”
Mayuresh Dani, manager of security research at the Qualys Threat Research Unit, added that this vulnerability is a classic example of blacklisting vulnerable gadgets when deemed vulnerable. Instead of relying on a blacklist, which can be bypassed if new deserialization gadgets are discovered, Dani agreed with Ellis that a strict whitelisting approach should be implemented.
“This involves only allowing the deserialization of explicitly approved classes, reducing the attack surface significantly,” said Dani. “I also suggest regular third-party code audits and regular penetration testing and security assessments to simulate attacks and identify vulnerabilities before they are exploited — if not being done already. Bug bounty participants can also encourage responsible disclosure before threat actors are made aware of such vulnerabilities.”
