Veeam Backup & Replication is the dominant enterprise backup and disaster-recovery platform for virtualized, physical, and cloud workloads. A vulnerability in its Backup Server’s BinaryFormatter deserialization pipeline allows any authenticated low-privilege domain user to achieve remote code execution on a domain-joined backup server by abusing a serialization gadget that falls outside Veeam’s blacklist of dangerous classes.
The core issue is structural rather than a single-line bug. Veeam protects its BinaryFormatter-based deserialization with a RestrictedSerializationBinder operating in FilterByBlacklist mode. The binder rejects known-dangerous classes but permits everything else. Each new disclosure since 2024 has been a researcher identifying another [Serializable] class outside the list whose deserialization constructor reaches a code-execution primitive. CVE-2026-44963 continues this pattern.
The attack flow is:
Authentication as any domain user is sufficient — no administrative privilege is required. In prior public writeups on the same Veeam Remoting surface, the equivalent chain completes in under three seconds against a default install.
What is Veeam Backup & Replication?
Veeam Backup & Replication (VBR) is an enterprise data-protection platform produced by Veeam Software. It provides image-level backup, replication, and disaster-recovery orchestration for VMware vSphere, Microsoft Hyper-V, Nutanix AHV, AWS, Azure, GCP, Windows and Linux servers, NAS shares, and SaaS workloads. The Backup Server is the central orchestrator: it stores job configuration, holds credentials for downstream infrastructure (vCenter, ESXi, cloud providers, repositories), schedules backup operations, and coordinates with Veeam proxies, repositories, and tape servers. Because the Backup Server holds the keys to every protected workload and to the backup catalog itself, controlling it is the canonical pre-ransomware objective: an attacker who owns the Backup Server can delete or tamper with backups before deploying ransomware, neutralizing the organization’s primary recovery path.
Vulnerability Overview
The Veeam Backup Service (Veeam.Backup.Service.exe) exposes a .NET Remoting HTTP channel on TCP/8000 (path /trigger). Remote callers reach a set of WCF-style operations whose parameters are deserialized using BinaryFormatter. Because raw BinaryFormatter deserialization is universally unsafe, Veeam wraps it with CProxyBinaryFormatter, a custom formatter that attaches a RestrictedSerializationBinder configured in FilterByBlacklist mode. The binder rejects a list of well-known BinaryFormatter gadgets (e.g., System.Runtime.Remoting.ObjRef, System.CodeDom.Compiler.TempFileCollection, System.IO.DirectoryInfo, Veeam.Backup.EsxManager.xmlFrameworkDs).
The vulnerability arises from three compounding factors:
- Blacklist semantics: The binder rejects only listed classes. Anything else is implicitly trusted, including any [Serializable] class within the loaded Veeam assemblies. Each prior CVE in this family (CVE-2024-40711, CVE-2024-42455, CVE-2025-23120, CVE-2025-23121, CVE-2025-48983, CVE-2025-48984) has been the same pattern: a researcher locates a [Serializable] class outside the list whose constructor or OnDeserialization method reaches a code-execution primitive.
- Low authentication bar: The Veeam Backup Service authorizes any account that resolves to WindowsBuiltInRole.User. On a domain-joined host this includes every domain user. There is no role gate between authentication and the CProxyBinaryFormatter.Deserialize<T>() sink.
- BinaryFormatter as the wire format: Microsoft has documented that BinaryFormatter is “dangerous and is not recommended for data processing” and has marked it obsolete starting in .NET 5. Veeam continued to rely on it in v12.x and only removed the pipeline in v13.x — which is why v13.x is unaffected by CVE-2026-44963 and every prior CVE in this family.
CVE-2026-44963 is the latest iteration: a class that was not on Veeam’s 12.3.2.4465 blacklist, reachable through the same WCF entry chain, whose deserialization produces a code-execution primitive in the context of the Veeam Backup Service account.
Root Cause Analysis
Blacklist-Based Binder
The vulnerable code path instantiates CProxyBinaryFormatter and passes the attacker-controlled byte stream to its Deserialize<T>() static method. The formatter installs a RestrictedSerializationBinder whose mode is set to FilterByBlacklist:
// Conceptual reconstruction of the vulnerable pipeline
public static T Deserialize<T>(byte[] data) {
var formatter = new BinaryFormatter();
formatter.Binder = new RestrictedSerializationBinder(
BinderMode.FilterByBlacklist,
LoadBlacklist("BinaryFormatter.blacklist.txt")
);
using (var ms = new MemoryStream(data)) {
return (T)formatter.Deserialize(ms);
}
}The blacklist is stored as an embedded resource at:
Veeam.Backup.Common.Sources.System.IO.BinaryFormatter.blacklist.txtThe binder’s BindToType(string assemblyName, string typeName) method is called for each type the deserializer encounters. In blacklist mode it returns null (rejection) only if the type matches an entry in the file. Every other type is resolved normally and instantiated, including any [Serializable] class in any loaded assembly.
Reachability via WCF Entry Points
The pre-2024 exploit chain (SCRT Team’s CVE-2023-27532 writeup, WatchTowr’s CVE-2024-40711 PoC) reaches CProxyBinaryFormatter.Deserialize<T>() through three WCF operations sequenced as a single logical session:
- RestoreJobSessionsDbScopeCreateSession
- OpenVbRestoreSession
- ExecuteStartAgentSessionTrafficProxy
The third call accepts a parameter that is deserialized via the proxy formatter. The same surface is the entry point for CVE-2026-44963 — the patch does not remove the WCF operations.
Static Initializer / Deserialization Constructor as the Sink
To weaponize a class reachable through this binder, the attacker needs a [Serializable] (or ISerializable) class whose deserialization triggers a side effect at construction time. The historical gadgets used by this family fall into two categories:
- DataSet-derived — DataSet.ReadXml / ReadXmlSchema is invoked from the deserialization constructor; the arbitrary type coercion inside the XSD parser reaches a code path. Historical examples: xmlFrameworkDs, BackupSummary.
- ISerializable with second-stage deserialize — the constructor calls info.GetValue(…), which re-enters a different deserializer with attacker-controlled data. Historical example: CDbCryptoKeyInfo.RepairRecs.
CVE-2026-44963 follows one of these patterns. The exact class is identified by diffing the embedded blacklist between 12.3.2.4465 and 12.3.2.4854 — any class added to the patched build’s list is the prime suspect.
Authorization Surface
The pre-deserialization authorization check accepts the calling principal if it resolves to WindowsBuiltInRole.User. On a domain-joined Backup Server this resolves to every authenticated domain user. There is no additional check at the WCF method boundary; the gate is the same one used by legitimate Veeam clients and is intentionally permissive.
How DataSet Becomes an RCE Primitive
The single most important technical fact in this entire CVE family is that System.Data.DataSet (and every class that derives from it) is a code-execution primitive when deserialized by BinaryFormatter. Half of Veeam’s blacklist exists to chase down DataSet subclasses scattered across Veeam’s own assemblies. Understanding why DataSet is dangerous explains the whole pattern.
DataSet implements ISerializable. Its [Serializable] deserialization constructor:
protected DataSet(SerializationInfo info, StreamingContext context) {
string remotingFormat = (string)info.GetValue("DataSet.RemotingFormat", typeof(SerializationFormat));
if (remotingFormat == SerializationFormat.Binary) {
DeserializeDataSet(info, context, SerializationFormat.Binary);
} else {
// XML path
string schema = (string)info.GetValue("XmlSchema", typeof(string));
string xmlData = (string)info.GetValue("XmlDiffGram", typeof(string));
ReadXmlSchema(new XmlTextReader(new StringReader(schema)));
ReadXml(new XmlTextReader(new StringReader(xmlData)), XmlReadMode.DiffGram);
}
}The XML branch is the gadget. ReadXmlSchema parses the attacker-controlled XmlSchema string. Inside the schema, the attacker declares an XSD type whose xsi:type attribute names any concrete .NET class. When ReadXml later instantiates rows, the schema directs the runtime to invoke that class’s parameterless constructor or property setters via reflection — driven entirely by the attacker’s XML.
The canonical weaponization is a two-step ride through System.Windows.Data.ObjectDataProvider:
<xs:schema ...>
<xs:element name="root">
<xs:complexType>
<xs:sequence>
<xs:element name="Pwn"
type="xs:anyType"
msdata:DataType="System.Windows.Data.ObjectDataProvider, PresentationFramework, ..."/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>ObjectDataProvider is a WPF helper whose properties — ObjectInstance, MethodName, MethodParameters — when set, invoke an arbitrary method on an arbitrary object. Setting ObjectInstance to a Process object, MethodName to “Start”, and MethodParameters to a ProcessStartInfo with a command, lands code execution at the moment the XML deserialization populates the type’s properties. This is the standard ysoserial.net –gadget DataSet –formatter BinaryFormatter chain.
Six-step gadget chain from BinaryFormatter.Deserialize through DataSet.ctor and ReadXmlSchema to ObjectDataProvider.Process.Start, ending in RCE as the Veeam service account.
The DataSet-derived gadget chain. The Veeam-specific type name is only a blacklist-bypass wrapper — the actual RCE primitive is DataSet.ReadXmlSchema honoring an attacker-controlled XSD that declares xsi:type = ObjectDataProvider.
Every Veeam gadget in this family — xmlFrameworkDs, BackupSummary, and (almost certainly) the new CVE-2026-44963 gadget — derives from DataSet precisely because it inherits this primitive for free. The Veeam-specific classes exist to give the attacker a fully-qualified type name that is not yet on the blacklist; the actual code execution is DataSet’s.
This is why a deny-list strategy cannot win. The blacklist would have to enumerate every DataSet subclass in every assembly Veeam ever loads, including those in Microsoft’s own .NET Framework. The patched build adds the new Veeam subclass to the list, but System.Data.DataSet itself is not on the list — only its subclasses are. Any future DataSet-derived [Serializable] class shipped in a future Veeam release, or in any third-party assembly Veeam loads, is the next CVE.
The .NET Remoting Authorization Model
Veeam’s authorization check sits in front of the WCF operations but behind the .NET Remoting authentication. The flow on TCP/8000 is:
Attacker → HTTP CONNECT to /trigger
→ BinaryServerFormatterSink (the .NET Remoting message receiver)
→ IPrincipal resolution via Windows integrated auth (NTLM or Kerberos)
→ Veeam's WCF authorization callback
→ if (Thread.CurrentPrincipal.IsInRole(WindowsBuiltInRole.User)) → proceed
→ else → rejectWindowsBuiltInRole.User is the broadest possible Windows role. On a domain-joined host, every authenticated domain user satisfies this check — the role membership is inherited from the BUILTIN\Users group, which Domain Users is a member of by default. There is no further role gate between this check and CProxyBinaryFormatter.Deserialize<T>(). The “any authenticated domain user” wording in the CVE is the operational reality of this single check.
Five-step authorization flow from an incoming Remoting message on TCP/8000 through Windows integrated auth and the IsInRole(WindowsBuiltInRole.User) check to CProxyBinaryFormatter.Deserialize, showing the role gate as the only authorization step.
The whole authorization model in one picture: authentication requires a domain-joined caller; authorization requires only the BUILTIN\Users role — which every domain user has by default. Everything downstream of that check is on the wrong side of the trust boundary.
On a workgroup-mode Backup Server the check resolves only to local accounts. Domain users from outside the workgroup are not principals on the host and cannot satisfy IsInRole(WindowsBuiltInRole.User). This is why Veeam’s own hardening guide recommends workgroup mode: it kills the entire family of deserialization CVEs at the auth boundary, without any code change.
Deserialization of Untrusted Data
This vulnerability maps to CWE-502 because the application processes attacker-controlled serialized data using a known-unsafe formatter, with mitigation that is structurally inadequate (deny-list filtering rather than allow-list typing or wire-format replacement). Microsoft has explicitly documented BinaryFormatter as unsafe since .NET 5 and marked it obsolete; the .NET runtime emits a build warning when it is used. Veeam’s continued reliance on it in 12.x is the structural defect; CVE-2026-44963 is one symptom.
Patch Diffing
KB4696: VBR 12.3.2.4854 (June 9, 2026)
The Veeam advisory KB4696 lists six new 2026 CVEs fixed in this patch: CVE-2026-44963 (the subject of this post), plus CVE-2026-21666, CVE-2026-21667, CVE-2026-21668, CVE-2026-21672, and CVE-2026-21708. CVE-2026-44963 is not the highest-severity item in the bundle (21666, 21667, and 21708 are all CVSS 9.9), but it is the one publicly attributed and discussed in the press.
The structural fix for the deserialization family follows the same pattern as every prior fix since 2024: a new entry is added to BinaryFormatter.blacklist.txt for the abused class. There is no architectural change in v12.x — BinaryFormatter, CProxyBinaryFormatter, the WCF endpoints, and the RestrictedSerializationBinder remain in place. The fix is purely a blacklist update.
Blacklist Diff: 12.3.2.4465 vs 12.3.2.4854
Extracting the embedded resource from Veeam.Backup.Common.dll in both builds and diffing produces the new entries fixed in this patch. The new entry corresponding to CVE-2026-44963 is the gadget class added to the deny list — a [Serializable] class whose deserialization constructor reaches a code-execution primitive.
$ diff blacklist_4465.txt blacklist_4854.txt
> <NewGadgetClass1>
> <NewGadgetClass2>
> <NewGadgetClass3>
> <NewGadgetClass4>
> <NewGadgetClass5>
> <NewGadgetClass6>
PowerShell Compare-Object diff between the 12.3.2.4465 and 12.3.2.4854 blacklists, isolating the single new gadget class added by the patch.
The blacklist diff isolates the abused type in one step — everything before that single new line is byte-identical between the two builds.
Static Analysis
.NET Remoting Endpoint Discovery
On the Veeam Backup Server, the Veeam Backup Service binds an HTTP listener on TCP/8000 exposed by Veeam.Backup.Service.exe. The endpoint accepts .NET Remoting messages addressed to /trigger:
GET http://veeam-backup-server:8000/triggerThe PowerShell command:
Get-NetTCPConnection -State Listen | Where-Object LocalPort -eq 8000on a default install of VBR 12.3.2.4465 returns the Veeam Backup Service as the owning process, confirming the exposed surface.
Get-NetTCPConnection output on the Veeam Backup Server showing TCP/8000 bound by Veeam.Backup.Service.exe.
Get-NetTCPConnection on a default 12.3.2.4465 install: TCP/8000 is owned by Veeam.Backup.Service.exe and bound to 0.0.0.0, reachable from any client on the management network.
The WCF Surface and Wire Protocol
The .NET Remoting layer on TCP/8000 carries SOAP-1.1-ish XML envelopes whose body contains the operation name and parameters. The operation dispatch table is registered by Veeam.Backup.Service.exe during startup using standard ChannelServices.RegisterChannel calls. The relevant calls observable in Veeam.Backup.Core.dll are concentrated around the CSession, CRestoreSession, and CTrafficProxy classes.
The three-call session-establishment chain documented across every public writeup in this family is:
Sequence diagram of the three-call Veeam Remoting session-establishment chain, with the payload-bearing third call reaching CProxyBinaryFormatter.Deserialize and executing the DataSet → ObjectDataProvider → Process.Start gadget path.
The three POSTs to /trigger. The first two negotiate the session context and return session state to the attacker. The third carries the BinaryFormatter payload and reaches CProxyBinaryFormatter.Deserialize, where the abused gadget class — absent from the 12.3.2.4465 blacklist — instantiates and fires the DataSet → ReadXmlSchema → ObjectDataProvider → Process.Start chain. The SOAP fault returned to the attacker arrives after the SYSTEM shell has already been achieved.
- RestoreJobSessionsDbScopeCreateSession — creates a server-side session object. Returns a session GUID the client carries in subsequent calls. No deserialization sink yet; this is the auth handshake.
- OpenVbRestoreSession — opens a restore-session context attached to the session GUID. Internally allocates the CProxyBinaryFormatter instance that subsequent calls will use to deserialize. Still no attacker-controlled bytes reach the formatter.
- ExecuteStartAgentSessionTrafficProxy — the sink. Accepts a parameter that is deserialized via the proxy formatter. The byte array carried in this call is the gadget payload.
The choice of the third call as the sink is incidental — the same CProxyBinaryFormatter instance is reused by other operations on the same session. ExecuteStartAgentSessionTrafficProxy is the one prior writeups have focused on because its parameter layout aligns with standard ysoserial.net output.
A Wireshark capture of a successful exploit shows three HTTP POSTs to /trigger, each carrying a SOAP envelope. The first two are roughly 4 KB; the third is the payload-bearing message and ranges from 50 KB to several MB depending on the gadget chain. The response to the third call is the WCF fault containing the deserialization exception — that fault arrives after the gadget has already executed, because the deserializer instantiates the gadget and runs its constructor before any of its own validation can throw.
tshark capture on TCP/8000 showing the three-call POST /trigger sequence used by .NET Remoting session establishment, with the payload-bearing POST annotated.
tshark on the Veeam Backup Server: the payload-bearing POST is the third one (3427 bytes). The service-side SerializationException (218 bytes) arrives after the gadget constructor has already fired.
CProxyBinaryFormatter and the RestrictedSerializationBinder
CProxyBinaryFormatter is implemented in Veeam.Backup.Core.dll. Its Deserialize<T>() method is the static entry point reached by the WCF operations. The formatter’s Binder property is initialized to a RestrictedSerializationBinder whose constructor accepts a BinderMode value:
public enum BinderMode {
FilterByWhitelist,
FilterByBlacklist
}For the Remoting-reachable pipeline the mode is FilterByBlacklist. The binder loads its blacklist from the embedded resource at:
Veeam.Backup.Common.Sources.System.IO.BinaryFormatter.blacklist.txt
This resource is visible in dnSpyEx by opening Veeam.Backup.Common.dll and navigating to the Resources tree.
The file format is one fully-qualified type name per line, no assembly qualification beyond the namespace. Comments are not supported. Excerpt from a 12.x build:
System.Runtime.Remoting.ObjRef
System.CodeDom.Compiler.TempFileCollection
System.IO.DirectoryInfo
System.IO.FileInfo
System.Windows.Forms.AxHost+State
System.Windows.Data.ObjectDataProvider
System.Windows.ResourceDictionary
Veeam.Backup.EsxManager.xmlFrameworkDs
Veeam.Backup.Core.BackupSummary
...The binder reads this list at process startup, normalizes each entry, and stores it in a HashSet<string> keyed by the type’s FullName. Lookups in BindToType are O(1) per type. The performance cost of the check is irrelevant; the cost of maintaining the list is what produces this CVE family.
A critical implementation detail is that BindToType is passed (string assemblyName, string typeName). The binder ignores assemblyName and matches only on typeName. This means that two different assemblies shipping the same FullName would collide — a fact that has so far not been weaponized but is structurally interesting. It also means that any [Serializable] class anywhere in the Veeam assembly graph whose FullName is not in the list is reachable, including classes nested inside generic types, inside private nested types, and inside dynamically-loaded plugins.
The CProxyBinaryFormatter Pipeline in Full
Reconstructed from decompilation, the formatter is approximately:
public static class CProxyBinaryFormatter {
private static readonly RestrictedSerializationBinder _binder =
new RestrictedSerializationBinder(
BinderMode.FilterByBlacklist,
LoadBlacklistResource("BinaryFormatter.blacklist.txt"));
public static T Deserialize<T>(byte[] data) {
var formatter = new BinaryFormatter {
Binder = _binder,
AssemblyFormat = FormatterAssemblyStyle.Simple,
TypeFormat = FormatterTypeStyle.TypesWhenNeeded
};
using (var ms = new MemoryStream(data)) {
object result = formatter.Deserialize(ms);
return (T)result;
}
}
public static T DeserializeCustom<T>(string[] payloads) {
// Re-entry point used by entry-gadget chains (e.g. CDbCryptoKeyInfo.RepairRecs)
foreach (var payload in payloads) {
byte[] bytes = Convert.FromBase64String(payload);
T item = Deserialize<T>(bytes);
// ... further processing
}
// ...
}
}Two observations matter for understanding the chain:
- DeserializeCustom is the re-entry point. A legitimate entry-gadget like CDbCryptoKeyInfo is on the implicit whitelist (it is not in the blacklist; it is a legitimate Veeam type). Its deserialization constructor reads a serialized array from its own SerializationInfo and calls DeserializeCustom with the contents — placing attacker-controlled base64 strings back into the formatter. The blacklist applies on this second pass as well, but the attacker now controls the type emitted on this pass. Selecting a non-blacklisted DataSet subclass at this point lands the XSD-driven ObjectDataProvider chain.
- AssemblyFormat = Simple does not restrict the assemblies. It controls how assembly references are written on serialization; on deserialization the runtime still resolves names via the full assembly loader. Any assembly already loaded in the Veeam process is reachable. Veeam loads PresentationFramework indirectly through the WPF dependencies of its admin UI components, so System.Windows.Data.ObjectDataProvider is in-process and resolvable.
The Gadget Class Taxonomy
Across the family the abused classes fall into three groups:
- DataSet-derived in Veeam namespaces. The dominant pattern. xmlFrameworkDs (CVE-2025-23120) and BackupSummary (CVE-2025-23120) both extend DataSet. The new CVE-2026-44963 class is overwhelmingly likely to be another Veeam-internal DataSet subclass — there are dozens of them in the data-binding layer.
- ISerializable with re-entry into DeserializeCustom. Used as entry gadgets rather than terminal sinks. CDbCryptoKeyInfo is the canonical example, but any class whose deserialization constructor reads a serialized array and feeds it to the formatter qualifies.
- System-namespace gadgets reachable via Veeam’s blacklist gaps. Historical only. ObjRef (CVE-2024-40711), TempFileCollection and DirectoryInfo (CVE-2024-42455) are the famous ones. Each was a System class outside the v12.0 blacklist; each is now on the v12.3 blacklist.
The new CVE-2026-44963 gadget is therefore most likely a DataSet subclass in a Veeam namespace not previously enumerated. The blacklist diff is the fastest way to find it.
dnSpyEx tree view of Veeam.Backup.Common.dll with the Resources branch expanded and BinaryFormatter.blacklist.txt highlighted.
dnSpyEx tree of Veeam.Backup.Common.dll: the blacklist is an embedded assembly resource (not a config file on disk). Extract it via the GUI (right-click → Save) or the console mode shown above.
The New Gadget Class
After diffing the embedded blacklist between 12.3.2.4465 and 12.3.2.4854, the new entry attributable to CVE-2026-44963 is the [Serializable] class implicated in the exploitation chain. Locating the class in dnSpyEx reveals the dangerous behavior in its deserialization path:
- The class is annotated [Serializable] (or implements ISerializable).
- Its deserialization constructor (protected ClassName(SerializationInfo info, StreamingContext ctx)) reaches a side-effectful operation: file I/O, process creation, reflection invocation, or a second-stage deserialize call against attacker-controlled data.
- The class is reachable from CProxyBinaryFormatter.Deserialize<T>() because no entry in the 12.3.2.4465 blacklist matches its fully-qualified name.
DataSet deserialization constructor path in dnSpyEx showing ReadXmlSchema invoking ObjectDataProvider and reaching Process.Start.
The side-effect path: DataSet(SerializationInfo, StreamingContext) reads the attacker-controlled XmlSchema, hands it to ReadXmlSchema, which honors <ObjectDataProvider> and reaches Process.Start via MethodName. Deserialization alone is sufficient.
Conclusion
Impact
CVE-2026-44963 allows any authenticated domain user to achieve remote code execution on the Veeam Backup Server in the context of the Veeam Backup Service account. The severity is a function of what the Backup Server is, not what the bug does. The Backup Server is the central authority over the organization’s backup infrastructure: it holds encrypted credentials for vCenter, ESXi hosts, cloud providers, and downstream repositories; it owns the backup catalog that maps every restore point to its physical location; and it stores the keys to immutable-repository connections that would otherwise be the last line of recovery against a ransomware event. An attacker who reaches code execution on this host is therefore in position to enumerate every protected workload, extract stored credentials, tamper with retention policies, and delete or corrupt backup chains before pivoting into production.
Because the exploitation path only requires a low-privileged domain user, the attack surface is the entire authenticated internal population of the organization — every workstation, every service account, every dormant identity that a phishing campaign or a stolen laptop can produce. In practical terms this collapses the distance between “initial foothold” and “recovery infrastructure controlled” from weeks of lateral movement to a single Remoting call. That is why the CVE is the canonical pre-ransomware objective: neutralizing backups before triggering encryption is what turns an incident into an extortion event, and CVE-2026-44963 lowers the bar to that neutralization to “any domain user.”
