OPEN SOURCE SECURITY DESK — Fourteen months after Microsoft's security response center confirmed that more than 3,000 ASP.NET machine keys had been sitting in public GitHub repositories, code samples, and documentation — any one of which could be lifted and used to forge a ViewState payload and achieve remote code execution — the .NET deserialization problem shows no sign of going away. The February 2025 disclosure, which Microsoft's threat intelligence team tied to active exploitation attempts against ASP.NET Core sites, was not a new vulnerability class. It was old news wearing a new coat: the same insecure deserialization pattern that has haunted the .NET ecosystem since ViewState first shipped, now amplified by how easily leaked keys circulate through public code search engines and AI training scrapes.
That single event is a useful entry point into a broader story. The "dotnet deserialization vulnerability" problem is not one CVE — it is a structural weakness that spans nearly every major serialization primitive Microsoft has shipped over the last two decades: BinaryFormatter, NetDataContractSerializer, LosFormatter, ObjectStateFormatter, and third-party favorites like Newtonsoft.Json's TypeNameHandling. Below is a look at where the landscape stands in mid-2026, why it keeps producing critical findings, and what security and platform teams should be watching.
The ViewState Machine Key Problem, Revisited
ASP.NET Web Forms' ViewState mechanism serializes page state into a Base64 blob and signs (and optionally encrypts) it using a server-side machineKey. If an attacker obtains that key — through a leaked web.config, a copy-pasted Stack Overflow snippet, or a scaffolding template that ships a "placeholder" key developers forget to rotate — they can craft a malicious serialized object, sign it correctly, and have IIS deserialize and execute it on submission. This is not theoretical: Microsoft's own advisory in February 2025 catalogued thousands of exposed keys and confirmed in-the-wild attempts to weaponize them via the ysoserial.net gadget-chain tooling that has circulated in offensive security circles since 2017.
The uncomfortable part for defenders is that the vulnerable ingredient here isn't a patchable bug. A leaked machine key is a secrets-management failure, and the deserialization gadget chain that turns it into RCE lives in framework code that many organizations can't easily rip out because it underpins legacy Web Forms applications still running in production. Rotating keys helps, but it doesn't address the underlying question every security team should be asking: does anything in our dependency tree still call an insecure deserializer on attacker-reachable input?
BinaryFormatter's Long, Overdue Retirement
If ViewState is the ecosystem's oldest deserialization headache, BinaryFormatter is its most infamous. Microsoft has been signaling its death for years — flagged as "dangerous" in .NET Core 2.1 documentation as far back as 2018, formally marked obsolete with build-time warnings starting in .NET 5, and disabled by default for a growing set of project types from .NET 8 onward. The reason is simple: BinaryFormatter was designed to serialize arbitrary CLR object graphs, including type information, which means an attacker who controls the byte stream controls which types get instantiated and which constructors, property setters, and IDeserializationCallback implementations run during the process. Combined with gadget chains built from types already loaded in the process (the same technique ysoserial.net automates), that's a direct path to code execution — no additional bug required, just the presence of the deserializer itself.
The slow-motion deprecation has been the right call, but it has also meant years of applications running with the unsafe path still technically available via opt-in switches, and a long tail of internal tools, legacy WCF services, and remoting endpoints that were never migrated because "nothing public touches them." Security teams that treat BinaryFormatter usage as fully retired because of the newer defaults are frequently wrong; it's an assumption worth verifying against actual shipped binaries and dependency manifests rather than framework release notes.
Gadget Chains Don't Need BinaryFormatter
The more subtle part of the .NET deserialization landscape is that the attack technique generalizes far beyond any single serializer. Newtonsoft.Json's TypeNameHandling setting — when set to Auto or All and fed attacker-controlled JSON — allows the same class of attack: the deserializer reads a $type field from the payload and instantiates whatever type is named, again enabling gadget-chain execution if a suitable chain exists in the loaded assemblies. This was formalized publicly at Black Hat USA 2017 in the "Friday the 13th: JSON Attacks" research, and it remains one of the most commonly flagged misconfigurations in .NET codebases that scanners surface today, in no small part because TypeNameHandling.All shows up in tutorials and Stack Overflow answers as a quick fix for polymorphic deserialization problems.
DataContractSerializer, NetDataContractSerializer, SoapFormatter, and LosFormatter round out the list of serializers with documented unsafe-deserialization behavior when given untrusted input. Each has its own advisory history, its own set of legacy consumers (WCF services and old-school Web Forms controls are especially common), and its own long shelf life inside enterprise codebases that don't get retired as quickly as the advisories suggest they should.
Real-World Exploitation Isn't Hypothetical
The Telerik UI for ASP.NET AJAX vulnerability tracked as CVE-2019-18935 is the clearest cautionary tale in this space. An insecure deserialization flaw in the RadAsyncUpload control allowed remote code execution when combined with a separate cryptographic weakness that let attackers derive the encryption keys protecting the serialized payload. It was picked up and used in real intrusions — including by operators deploying cryptomining payloads and, in later campaigns, ransomware — for years after the patch shipped, because so many organizations were running outdated Telerik component versions bundled deep inside third-party or internally maintained web applications. It is a textbook example of why deserialization findings in the .NET world routinely outlive their patches: the vulnerable component is often several dependency layers removed from the team that would need to update it, and nobody owns the upgrade.
Why the Pattern Persists
Three structural factors keep .NET deserialization vulnerabilities in the news cycle rather than the history books. First, backward compatibility: Microsoft and the broader .NET ecosystem have historically prioritized not breaking existing applications, which means dangerous APIs linger with warnings rather than hard removals for years at a stretch. Second, the code is old and deep: ViewState, WCF remoting, and legacy serialization calls tend to live in the oldest, least-instrumented parts of an application's codebase — exactly where modern security tooling is least likely to be looking. Third, and most important for practitioners: knowing a dangerous API exists somewhere in a dependency tree is very different from knowing whether attacker-controlled data can actually reach it. A BinaryFormatter call buried in an internal diagnostics tool that only deserializes trusted, locally generated files is a very different risk than the same call sitting behind a public API endpoint.
How Safeguard Helps
This is precisely the gap Safeguard is built to close. Rather than flagging every instance of BinaryFormatter, TypeNameHandling.All, or a vulnerable Telerik package version as equally urgent, Safeguard's reachability analysis traces whether attacker-influenced input can actually flow into an insecure deserialization call in your specific application, cutting through the noise that makes teams numb to scanner output. Griffin AI, Safeguard's autonomous triage engine, correlates that reachability data with exploit intelligence — including known gadget-chain research and in-the-wild activity like the ASP.NET machine key attacks — to prioritize the handful of findings that represent genuine risk. Continuous SBOM generation and ingest give teams a live inventory of every serializer-dependent component across their .NET estate, including the legacy WCF services and third-party UI libraries that traditional asset inventories tend to miss. And where a fix is well understood — upgrading a vulnerable Telerik version, swapping TypeNameHandling.All for a safer binder, or migrating off BinaryFormatter entirely — Safeguard can open an auto-fix pull request so the remediation lands in the codebase instead of sitting in a backlog next to last year's advisory.