ASP.NET Deserialization

What This Vulnerability Means in ASP.NET

ASP.NET deserialisation becomes dangerous when an application accepts object state from an untrusted source and turns it back into executable .NET object graphs without strict type and trust boundaries. That is why deserialisation flaws in web applications are often treated as code-execution paths rather than simple parsing bugs, especially when session, cache, or view state data is involved.

For a broader treatment of the attack class, the Insecure Deserialisation Guide explains how object injection and gadget chains arise across platforms, including .NET. In ASP.NET specifically, the danger is not the conversion step itself, but the assumption that the incoming payload is safe enough to rehydrate into objects with behaviour.

Why ASP.NET Deserialisation Is Dangerous

The main risk is that a crafted payload can select unexpected types, influence object state, or activate gadget chains that trigger harmful behaviour during deserialisation. In web applications, that can lead to remote code execution, data tampering, denial of service, or logic abuse, depending on what classes and callbacks the application exposes.

ASP.NET environments can be especially sensitive when developers rely on legacy or permissive serializers, store state in user-influenced locations, or assume framework-managed data is automatically trustworthy. The issue often becomes more severe when deserialised objects feed directly into privileged operations, because the attacker gains a way to smuggle intent through what looks like ordinary application state.

How Organisations Check Exposure and Reduce Blast Radius

Exposure review starts with inventorying every place the application deserialises untrusted or semi-trusted data, including session state, caches, hidden fields, inter-service messages, and custom state containers. Teams should confirm whether those code paths are reachable from the internet, whether they accept attacker-controlled blobs, and whether a safer data format or fixed-type contract is available.

The Secure Deserialisation Guide is useful here because it focuses on fail-closed loader settings, filtering, and safer design patterns. For ASP.NET-specific review, the .NET Security Guide helps teams connect deserialisation risk with wider runtime and application security decisions, while the ASP.NET Core Security Guide covers adjacent controls that reduce the chance that one unsafe component can be turned into full application compromise.

Remediation, Detection, and Post-Compromise Review

Remediation usually means removing unsafe serializers where possible, constraining allowed types, and refusing to deserialize attacker-supplied object graphs unless the format and schema are tightly controlled. If a patch or code change cannot be applied immediately, compensating controls should narrow who can reach the endpoint, limit the data accepted, and reduce the privileges available to the process that performs deserialisation.

Detection should look for unusual payload shapes, parser failures, unexpected type loading, application errors around state restoration, and signs that the application spawned abnormal processes or made outbound connections after processing a request. After any suspected exploitation, review logs, secrets, session state, and service credentials that may have been exposed through the compromised code path, because successful deserialisation attacks often create follow-on access rather than a single isolated event.

The Host Header Attacks and Validation Guide is a useful adjacent reference when an application combines unsafe state handling with weak trust in request metadata, and the IIS Hardening Guide helps when the affected ASP.NET workload depends on web server configuration, logging, and key hygiene to limit post-exploitation persistence.

Why Practitioners Should Treat It as a Design Issue

Common misunderstanding: deserialisation bugs are often treated as low-level implementation mistakes, but in practice they are architecture and trust-boundary problems. If application state can be influenced by a user, a partner, or another service, then the deserialiser becomes part of the attack surface and should be designed as if the input may be hostile.

Practitioner takeaway: the safest ASP.NET pattern is to minimise object rehydration from untrusted data, prefer explicit contracts over opaque object graphs, and treat every deserialisation boundary as a potential code-execution boundary.

Related resources from NHI Mgmt Group

• Deserialization
• Is CVE-2019-18935 (Progress Telerik UI for ASP.NET AJAX Deserialization of Untrusted Data) being exploited in the wild?
• How do you patch or mitigate CVE-2019-18935 (Progress Telerik UI for ASP.NET AJAX Deserialization of Untrusted Data)?
• CVE-2019-18935 (Progress Telerik UI for ASP.NET AJAX Deserialization of Untrusted Data)