NET Deserialisation is caused when an application deserialises untrusted data into .NET objects without strict type and integrity controls. Attackers exploit this by supplying crafted payloads that trigger unsafe behaviour during object reconstruction. Defenders should avoid deserialising untrusted input, restrict allowed types, use integrity protection, and review any code path that accepts serialized objects from clients.
Why .NET deserialisation becomes dangerous
.NET deserialisation is not inherently malicious, but it becomes dangerous when the application treats attacker-controlled input as a trusted object graph. The risk is not just data corruption, it is that object reconstruction can execute code paths, invoke callbacks, or instantiate unexpected types before the application has a chance to validate intent.
That is why this flaw usually sits at the boundary between parsing and execution. If the code accepts serialized blobs from users, partner systems, queues, or APIs without a strict trust boundary, the attacker is no longer “sending data”, they are influencing how the runtime rebuilds objects.
What attackers are actually trying to achieve
Attackers use deserialisation flaws to move from input control to behaviour control. A crafted payload may trigger logic in the deserialiser, activate dangerous gadget chains, or steer the application into an unsafe state such as command execution, file access, authorization bypass, or denial of service.
The practical problem is that many teams underestimate how much power sits inside object metadata, type binding, and deserialisation callbacks. Even when the payload looks like a harmless byte stream, the application may still be honoring embedded instructions about what to build and how to build it.
How to reduce exposure in .NET code
The safest pattern is to avoid deserialising untrusted input altogether. When deserialisation is required, use a format and library that support explicit type control, refuse polymorphic surprises, and enforce allowlists so the runtime can only create objects you already expect. Integrity protection matters as well, because tampering turns a legitimate serialized payload into a delivery vehicle for unsafe behaviour.
For legacy code, the highest-value review points are any endpoint that accepts serialized objects from clients, any code path that hydrates privileged configuration or session state, and any place where a deserialised object is immediately passed into filesystem, reflection, process, or privilege-sensitive logic. The Insecure Deserialisation Guide gives a broader view of the attack patterns and defensive filters that matter across common platforms, including .NET.
Risk and Threat Considerations
Untrusted deserialisation is dangerous because the trust decision happens too late. By the time the application rejects malformed content, the runtime may already have loaded types, invoked callbacks, or partially reconstructed objects with side effects.
Failure mechanism: The attacker supplies a crafted payload that abuses permissive type handling, gadget chains, or unsafe object reconstruction to trigger behaviour the developer did not intend.
Impact: Depending on the code path, the result can include remote code execution, privilege abuse, data exposure, application crashes, or deeper compromise of the host or service account running the application.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while OWASP ASVS, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V15 — Secure Coding and Architecture | Directly addresses unsafe object handling and trust-boundary design. |
| Recommendation — Eliminate unsafe deserialisation paths and require explicit trust-boundary validation. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | Deserialised input must be validated before the application acts on it. |
| SC-23 — Session Authenticity | Tampered serialized state can subvert trust in application-controlled data. | |
| Recommendation — Validate serialized input before reconstruction or processing. Protect serialized state with integrity controls and reject tampered objects. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Covers secure design and review of risky application behaviors like deserialisation. |
| Recommendation — Review application deserialisation paths and remove unsafe object reconstruction. | ||
| MITRE ATT&CK | T1027 — Obfuscated Files or Information | Crafted serialized payloads may be used to hide malicious structure from defenders. |
| Recommendation — Hunt for hidden payload structure and unusual serialized input handling. | ||
Practitioner Guidance
What to verify: Inventory every deserialisation entry point and confirm whether each one can receive attacker-controlled input. If the answer is yes, require an explicit allowlist, integrity check, and a documented reason why deserialisation is necessary at all.
Decision rule: If the payload can cross a trust boundary, treat the deserialiser as a security boundary, not a convenience function. If the code cannot prove the type and origin of the object stream, replace that path with a safer data model or reject the input.
Common mistake: Teams often focus on the serializer library and miss the downstream effect of the reconstructed object. The real question is not “Can the payload be parsed?”, it is “What can this object do once the runtime has built it?”
Practitioner takeaway: Secure .NET deserialisation by shrinking the number of places where untrusted input can become live objects, and by making every remaining path prove type, origin, and integrity before reconstruction.