Deserialisation is the process of converting stored or transmitted data back into in-memory objects or structured values. It becomes dangerous when the input is attacker-controlled, because the application may recreate objects with unexpected properties, behaviour, or side effects that were never meant to be reachable.
What Deserialisation Does
Deserialisation converts data from a stored or transmitted form back into objects or structured values the application can use. The operation itself is normal and necessary, but it becomes security-sensitive when untrusted input can influence what gets reconstructed.
At that point, the problem is not just parsing data. The runtime may be persuaded to instantiate a type, restore fields, or trigger logic that the developer did not intend to expose to external control.
Why Deserialisation Becomes Dangerous
The core security issue is that object reconstruction can do more than restore plain data. In some ecosystems, deserialising a crafted payload can invoke constructors, setters, callbacks, or framework hooks that change application state or trigger side effects.
That makes deserialisation a common entry point for integrity compromise, because the attacker is no longer limited to supplying values. They may be influencing program behaviour, trust decisions, or downstream processing in ways the application never expected.
In practice, the risk rises when the format carries type information, when the application accepts objects from clients or other untrusted systems, or when the code assumes anything already serialised is safe to restore. Secure input handling still matters here, but the deeper issue is trust in the reconstructed object graph itself.
Common Failure Modes
unsafe deserialisation often shows up as gadget-based abuse, where an attacker combines legitimate classes or framework behaviour into a dangerous sequence. The individual components may be benign on their own, but together they can produce file access, command execution, denial of service, or unexpected privilege-sensitive actions.
Another failure mode is type confusion, where the application accepts a payload that resolves to a different class or structure than the developer assumed. Even when this does not lead to code execution, it can still corrupt logic, bypass validation, or create application-state inconsistencies.
These failures are especially serious in systems that use serialised objects for session state, message passing, cache storage, or internal service communication, because the blast radius can extend beyond a single request boundary.
Safe Handling Patterns
Safer designs avoid restoring complex object graphs from untrusted sources unless there is a strong reason to do so. Where deserialisation is unavoidable, the application should constrain the allowed types, validate the source and context, and prefer data-only formats that do not carry executable behaviour.
Reviewing which libraries and framework versions are present matters too, because deserialisation risk often depends on available classes and their side effects. The right control is not just “use a safer parser”, but “limit what the parser can ever reconstruct and what that reconstruction is allowed to do.”
For broader security guidance on control design and hardening, see NIST SP 800-53 Rev 5 Security and Privacy Controls and the CIS Benchmarks, which both support disciplined configuration and integrity protection.
Risk and Threat Considerations
Deserialisation is a high-value attack surface because attackers only need one unsafe reconstruction path to turn a data format into behaviour. The most damaging outcomes usually come from object injection, gadget chains, and unexpected invocation of framework logic during parsing.
Failure mechanism: A crafted payload reaches a deserialiser that trusts embedded type information or reconstructs classes with harmful side effects, allowing the attacker to influence execution flow or application state.
Impact: The result can be remote code execution, logic bypass, denial of service, privilege-sensitive abuse, or compromise of internal services that process the same format.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 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 | Deserialisation security depends on validating untrusted input before object reconstruction. |
| AC-6 — Least Privilege | Limiting runtime privilege reduces the impact if a deserialisation flaw triggers harmful behaviour. | |
| Recommendation — Validate and constrain deserialised input before it reaches object construction or business logic. Apply least privilege to services that process deserialised input. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Unsafe deserialisation is an application-layer weakness that belongs in secure coding and review practices. |
| Recommendation — Review deserialisation code paths and remove unsafe object reconstruction patterns. | ||
Practitioner Guidance
Why practitioners should care: Deserialisation is often treated as plumbing, which makes it easy to overlook during code review and threat modelling. Treat any untrusted deserialisation path as a security boundary, not just a parsing detail.
What to watch for: Complex object serializers, language-native binary formats, framework auto-binding, and any code path that accepts externally supplied blobs for sessions, caches, RPC, or queues deserve special scrutiny. If the application can reconstruct more than plain data, the risk profile changes immediately.
Practitioner takeaway: Prefer simple data-only interchange, and when object reconstruction is unavoidable, restrict the accepted types as tightly as the business use case allows.
Related resources from NHI Mgmt Group
- What breaks when prompt loading or deserialisation is not constrained?
- What breaks when unsafe deserialisation affects AI serving APIs?
- How do security teams know whether unsafe deserialisation is still present in production?
- Why do BI platforms become especially dangerous when authentication bypasses can be chained with file read, SQL injection, and deserialisation flaws?
