WSUS unauthenticated SYSTEM RCE: inside the BinaryFormatter deserialization of CVE-2025-59287

Windows Server Update Services is the built-in role that lets an organization approve and distribute Microsoft updates to its fleet from a central server rather than sending every host to the public update endpoints. It is boring, load-bearing infrastructure, and that is exactly why this bug matters. Only servers with the WSUS Server Role enabled are affected, but where it is enabled the role listens on 8530/TCP for HTTP and 8531/TCP for HTTPS, and a meaningful number of those servers were reachable from the internet. Affected platforms span Windows Server 2012, 2012 R2, 2016, 2019, 2022 including 23H2, and 2025. This piece walks the root cause and the exploitation path, then gives you the readable facts that tell you whether you are exposed, without sending a single malicious byte. Verifiable security.

Root cause: a legacy formatter on a pre-auth path

The defect is the oldest deserialization mistake in the .NET playbook: calling a type-permissive binary deserializer on bytes that came from the network. WSUS accepts a client-supplied AuthorizationCookie as part of its client-server protocol. On the vulnerable code path, the server reaches GetCookie() and deserializes the encrypted cookie contents using BinaryFormatter, the legacy .NET serializer that Microsoft has itself deprecated precisely because it reconstructs arbitrary object graphs from attacker-controlled input. A second route to the same class of bug reaches unsafe deserialization through SoapFormatter in the WSUS ReportingWebService. These are two distinct sinks, and it is worth keeping them distinct: the AuthorizationCookie path runs through BinaryFormatter at GetCookie(), while the reporting path runs through SoapFormatter. Both share the same fatal property, which is that the format they parse is powerful enough to describe not just data but the shape and construction of live objects.

BinaryFormatter does not merely read fields into a struct. It reconstructs a full object graph, invoking type constructors, setters, and callbacks along the way. That behavior is the entire vulnerability class. If an attacker can hand the deserializer a stream describing a graph of types that happen to exist in the loaded assemblies, and those types perform interesting work during their own deserialization, the attacker has effectively scripted a small program that runs inside the target process. The deserializer trusts the stream to tell it which types to build. The stream is untrusted. That contradiction is CWE-502.

The gadget chain in practice

Turning "the deserializer builds attacker-chosen objects" into "the deserializer runs attacker-chosen code" is the job of a gadget chain. A gadget is a method on some already-loaded type that does something useful to an attacker when it is invoked during deserialization, for example inside a constructor, a property setter, an ISerializable callback, or a TypeConverter. The .NET ecosystem has well-known, publicly documented chains that stitch these gadgets together so that reconstructing one outer object cascades into invoking a command. The canonical building blocks come from the ysoserial.net family, and they lean on types that ship in the standard libraries, so no attacker-supplied code needs to be planted on disk first.

The mechanics, without providing a weaponized payload, look like this. The attacker crafts a serialized stream whose top-level object, once reconstructed, forces the runtime to materialize a chain of intermediate objects. One link in that chain is a type whose deserialization triggers method invocation, commonly through a delegate, a data-binding sink, or a type-conversion path. The final link resolves to a call that launches a process or evaluates a command line. Because BinaryFormatter honors the type information embedded in the stream, the attacker chooses every type in the chain. The server obligingly builds all of them.

The unauthenticated path from a crafted cookie to SYSTEM. Structural illustration, not a working exploit.

Why WSUS is a devastating pivot

Plenty of servers run as SYSTEM. What makes WSUS special is what it is for. A WSUS server exists to push software to every client that trusts it. Its entire function is authenticated, high-volume distribution of executable content to managed hosts. An attacker who owns the WSUS server does not just own one box at SYSTEM; they sit astride the update channel for everything downstream. That is a position most red teams would spend weeks trying to reach, handed over by one unauthenticated request.

The observed post-exploitation activity fits that opportunity. Defenders reported wsusservice.exe and w3wp.exe, the WSUS service and its IIS worker process, spawning cmd.exe and powershell.exe children that decoded base64 command blocks to enumerate hosts, users, and network configuration. That reconnaissance is the opening move of lateral movement: inventory the environment from a trusted vantage point, then use the position to reach further. When the compromised host is the one that ships updates to the fleet, the enumeration is not idle curiosity, it is target selection.

A WSUS server exists to push executable content to every host that trusts it. Owning it is not a foothold at the edge of the network. It is a seat at the center of it.

Be precise about the scope of the claim, because precision is the brand. This is dangerous where WSUS is internet-exposed on an unpatched build. It is not a universal Windows Server bug. A server without the WSUS role enabled does not expose the sink at all. A server whose 8530/8531 ports are reachable only from an internal management network carries a fraction of the risk of one answering from the public internet. The work is to determine which of those is true for your estate, rather than assuming the worst everywhere or dismissing it everywhere.

How to recognize your exposure without firing a payload

Three readable facts decide your risk, and none of them require sending a malicious cookie.

1. Is the WSUS Server Role enabled, and is 8530 or 8531 reachable from outside your management network? The dangerous surface only exists where the role is installed and its ports answer. An internet-facing listener on those ports is the single highest-signal fact.
2. Is the out-of-band update from 23 October 2025 applied? That build supersedes the 14 October Patch Tuesday release and is the fix. An exposed server missing it is a catalog-listed, actively exploited target, which means it should be treated as an incident rather than a queued ticket.
3. What account does the WSUS service run as? On these servers the effective answer is SYSTEM, which is why the impact rating is C:H/I:H/A:H. Confirming the run-as account confirms the blast radius before any bug is touched.

What to do about it

How Celvex catches this

The lesson underneath CVE-2025-59287 is not new, which is exactly the point. A legacy deserializer on a network-reachable, pre-authentication path is a known-lethal pattern, and it landed on one of the most trusted servers in a Windows estate. The defenses are equally known: patch, remove the sink where you cannot patch, and keep the management surface off the public internet. The discipline is to ask the boundary question of every trusted internal system, not only of the obvious web apps: which of them take outside input before authentication, on what build, running as what account. Answer that for your WSUS servers, and this stops being a surprise.

Verifiable security. Find it. Prove it. Fix it. Verify the fix held. That is what we ship.