A newly disclosed deserialization vulnerability, tracked as CVE-2026-44963, lets authenticated domain users achieve remote code execution (RCE) against Veeam Backup & Replication (VBR) backup servers by abusing unsafe BinaryFormatter deserialization.
Published analysis from SecureLayer7 Labs shows the flaw stems from a blacklist-based mitigation around .NET BinaryFormatter that can be bypassed by an unlisted serializable class, continuing a worrying trend of issues in Veeam’s .NET Remoting attack surface.
VBR’s Backup Server is the central orchestration point for backup, replication, and disaster recovery across virtual, physical, and cloud workloads.
Because it stores credentials and coordinates job execution, the Backup Server is a high-value target for ransomware actors who aim to delete or corrupt backups before deploying payloads.
Veeam CVE-2026-44963
CVE-2026-44963 directly threatens that trust boundary by exposing a deserialization sink in the Veeam Backup Service (Veeam.Backup.Service.exe), which exposes a .NET Remoting HTTP endpoint on TCP port 8000 at the /trigger path.
The service accepts incoming requests that are processed using BinaryFormatter deserialization wrapped in a custom CProxyBinaryFormatter with a RestrictedSerializationBinder operating in FilterByBlacklist mode.
Rather than enforce strict type whitelisting, this binder blocks a list of known dangerous classes while implicitly trusting all other serializable types.
SecureLayer7’s research demonstrates how an attacker can craft a payload using a previously unlisted [Serializable] class to bypass the blacklist and trigger code execution during deserialization.
The exploitation chain requires only authentication as a low-privilege domain user because the service’s authorization check validates membership in WindowsBuiltInRole.User, which includes all domain users by default.
The attack proceeds through a three-call WCF sequence: RestoreJobSessionsDbScopeCreateSession establishes a context, OpenVbRestoreSession initializes the deserialization environment, and ExecuteStartAgentSessionTrafficProxy delivers the malicious BinaryFormatter payload to CProxyBinaryFormatter.Deserialize(). The payload leverages a gadget chain rooted in System.
Data.DataSet deserialization, abusing ReadXmlSchema and ReadXml to process attacker-controlled XML containing doctored xsi:type entries.
Those entries enable instantiation of arbitrary .NET classes—most notably System.Windows.Data.ObjectDataProvider allowing attackers to set ObjectInstance, MethodName, and MethodParameters to invoke Process.Start and run commands under the Veeam Backup Service account, typically SYSTEM.
At its core, CVE-2026-44963 highlights the danger of continued reliance on BinaryFormatter. Microsoft marked BinaryFormatter as obsolete and unsafe beginning with .NET 5 because it enables complex gadget chains and unsafe post-deserialization behavior.
Veeam’s blacklist approach cannot comprehensively enumerate every gadget class; each new CVE in this family (including prior issues such as CVE-2024-40711 and CVE-2025-23120) has relied on discovering a previously unblocked class.
Patch analysis of Veeam 12.3.2.4854 (KB4696) shows the vendor addressed CVE-2026-44963 by adding the newly exploited class to BinaryFormatter.blacklist.txt.
No architectural changes were made to remove BinaryFormatter or replace the deserialization pipeline, leaving other unlisted gadgets as potential future attack vectors. By contrast, Veeam 13.x removes the BinaryFormatter-based pipeline and is not vulnerable to this class of flaw.
Security teams running Veeam 12.x should apply vendor patches immediately, restrict network access to TCP port 8000, and consider deploying Backup Servers in workgroup mode to reduce domain-scope exposure.
Longer-term mitigation requires eliminating BinaryFormatter, adopting strict deserialization whitelists or safer serialization formats, and applying the principle of least privilege to services that perform sensitive orchestration tasks.
CVE-2026-44963 is a stark reminder that blacklist-based defenses are brittle and that legacy deserialization mechanisms must be retired to prevent attack chaining against critical backup infrastructure.
No Comment! Be the first one.