A common .NET deserialisation example is a web application accepting a serialized object from a request, cache or message queue and then recreating it into a live object graph. If the data is attacker-controlled, that can trigger unexpected code paths or gadget chains. Safer design uses simple formats and rejects untrusted serialized objects at the boundary.
What a .NET deserialisation example looks like in practice
A real-world .NET deserialisation case is a server taking a serialized object from an HTTP request, cache entry, or message queue and turning it back into a live object. In .NET, that can happen with legacy serializers such as BinaryFormatter, but the security issue is the pattern itself: if the input is untrusted, object construction can become code execution.
For example, a service might read a blob from storage and call a deserializer before any validation has happened. That seems convenient because the application gets a ready-made object graph, but it also means the serializer is deciding which types to instantiate and which callbacks to run. A malicious payload can abuse that behaviour to reach unexpected code paths or gadget chains.
Safer examples use simple data contracts, JSON, or other non-object-execution formats, then map the data into explicit application types after validation. The important design choice is not just the library you pick, but whether the boundary accepts arbitrary serialized objects at all. When a boundary must accept structured data, it should treat the input as data, not as executable state.
Why this becomes dangerous in .NET applications
The risk appears when developers assume deserialization is a passive parsing step. In reality, some serializers can invoke constructors, property setters, custom binders, or type resolution logic while rebuilding the object graph. If the application accepts untrusted data, those behaviours can be influenced by an attacker and used to trigger unexpected execution paths.
That is why insecure deserialisation is often grouped with object injection. The issue is not limited to one API call, because the dangerous behaviour may be hidden behind framework code, middleware, cached payloads, or a downstream service that trusts upstream objects. The same mistake also shows up when a team moves serialized data between tiers and forgets that every hop is a trust boundary.
The cleanest mental model is simple: if the source of the serialized payload is not fully trusted, deserialization should be avoided or tightly constrained. If the application only needs structured fields, use a format and parser that do not recreate arbitrary runtime objects. If the application truly needs complex object graphs, then the type set, binder, and input origin all need explicit restriction.
What to look for in code review and remediation
Search for code that accepts serialized objects from external input, especially where the input is read from a request body, hidden form field, queue message, cache, or session-like store. In .NET, legacy object serializers deserve special scrutiny because they can combine convenience with broad type activation. The safest finding is usually not “which serializer is used?” but “can an attacker influence the type being instantiated?”
Remediation usually means replacing unsafe object serialization with explicit data contracts, narrowing allowed types, and rejecting opaque serialized blobs at the boundary. The refactor should also consider where the payload comes from, because deserialization risk often survives even when the immediate code is changed if another service still emits attacker-influenced serialized content.
For a deeper pattern library and defensive framing, the Insecure Deserialisation Guide covers object injection, gadget chains, and safer filtering approaches across .NET and other ecosystems.
Risk and Threat Considerations
Deserialisation becomes a security issue when the application lets untrusted bytes decide which objects exist and which runtime behaviours execute. That creates a trust-boundary failure, and in the worst case it turns a data-processing step into a code-execution path.
Failure mechanism: A crafted payload can steer type resolution, callbacks, or gadget chains during object rehydration, especially when legacy serializers or broad allowlists are used.
Impact: The result can range from application crash to remote code execution, privilege abuse, or exposure of cached data and secrets that were reachable from the affected process.
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 NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | Deserialised input must be validated before use. |
| AC-6 — Least Privilege | Limits blast radius if deserialization is abused. | |
| Recommendation — Validate serialized input at the boundary and reject unexpected object content. Constrain the process and service account privileges around deserialization code. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Secure design should avoid unsafe object reconstruction from untrusted data. |
| V8 — Authorization | Dangerous object creation can undermine expected access decisions in the application flow. | |
| Recommendation — Redesign deserialization paths to use explicit data contracts and safe object mapping. Ensure reconstructed objects cannot bypass authorization decisions. | ||
| MITRE ATT&CK | T1027 — Obfuscated Files or Information | Serialized payloads can conceal malicious content and gadget chains. |
| Recommendation — Inspect suspicious serialized payloads for hidden exploit content and staging. | ||
Practitioner Guidance
What to verify: Confirm whether any .NET deserializer in the request path, background job, or cache layer accepts data that originated outside the application trust boundary. If the answer is yes, treat that path as a candidate for immediate replacement or strict constraint.
Decision rule: If the payload only needs business fields, move to a simple format and explicit mapping. If the payload must remain object-shaped for compatibility, restrict the type universe and make the source of serialized data part of the security review, not an implementation detail.
Practitioner takeaway: The key question is not whether the code “works”, it is whether untrusted input is ever allowed to influence object construction. If it is, the deserializer has become part of the attack surface.
Related resources from NHI Mgmt Group
- How should security teams design an animated code example so it feels like a real developer walkthrough rather than a static demo?
- What is an example of improper certificate validation in real code?
- What is an example of Conditional Access Policy Coverage Gap in real code?
- How should security teams handle device code phishing when users complete real Microsoft MFA?