Attackers use Deserialisation Attack by sending crafted data that a vulnerable application deserialises into objects or commands it should not create. This can lead to code execution, privilege abuse, or data tampering. Defenders reduce exposure by avoiding unsafe deserialisation of untrusted input, restricting allowed types, and watching for unexpected object creation or gadget-chain behaviour.
How attackers turn unsafe deserialisation into execution
Deserialisation becomes dangerous when an application accepts attacker-controlled data and reconstructs it into objects without strict validation. The attacker is not just “sending bad input”, they are trying to influence how the runtime interprets that input so that methods, constructors, or callbacks fire in an unsafe order. The practical result is often code execution, but it can also be logic abuse or tampering before any obvious crash appears.
A useful way to think about the attack is that the payload is rarely valuable on its own. Its value comes from the target’s class graph, library behaviour, and trusted object handling. That is why deserialisation flaws often depend on web application attacks that allow the attacker to reach a parser, message handler, cache, session store, or API endpoint that accepts structured data from outside the trust boundary.
Attackers usually look for parsing flows that automatically instantiate objects, resolve types, or restore state without an allowlist. If the application exposes a dangerous gadget chain, the payload can trigger unintended behaviour even when the original code never explicitly calls a shell, file API, or admin function. That is why deserialisation attacks are often described as a trust failure in the object reconstruction process, not just a malformed-input problem.
What the attacker is actually exploiting
The core weakness is excessive trust in data that should have been treated as inert. Once a deserialiser accepts untrusted input, the attacker may be able to influence object properties, internal references, or type resolution in ways that alter program flow. In mature exploit chains, the attacker does not need to understand the entire application, only enough of the runtime and dependencies to find a reachable gadget path.
That is why insecure deserialisation frequently overlaps with gadget-chain exploitation, object injection, and library abuse. The payload may be designed to reach a sink such as command execution, file write, remote fetch, or privilege-sensitive business logic. Insecure Deserialisation Guide is the best internal reference for the common patterns and the kinds of allowlist filtering that reduce exposure.
The attack often succeeds because developers assume the format itself is safe, for example JSON, XML, or native binary serialisation. The format is not the guarantee, the trust decision is. If untrusted users can supply the payload and the application reconstructs privileged objects from it, the attacker is already in a position to abuse the parser’s assumptions.
What defenders should validate when the payload is blocked or suspicious
When deserialisation is suspected, the immediate question is whether the vulnerable path is reachable from unauthenticated input, a low-privilege user, or an internal integration. That matters because the same flaw can be a nuisance issue in one flow and a full system compromise in another. Defenders should confirm which endpoints deserialize data, what types are permitted, and whether the application ever accepts serialized blobs from logs, cookies, queues, or third-party services.
Then verify whether the environment already contains indicators of earlier abuse, such as unexpected object creation, unusual exceptions in deserialisation libraries, new outbound connections triggered during parsing, or unexplained changes in application state. If the flaw can expose tokens, sessions, or privileged runtime state, rotation and invalidation may be needed after containment. The main decision point is whether the payload merely failed, or whether it reached a dangerous sink before being detected.
Because deserialisation bugs are often hidden in middleware and dependencies, the safest response is usually to reduce trust at the boundary rather than rely on downstream sanitisation. That means strict type restrictions, reject-by-default parsing, and removing features that automatically materialise objects from untrusted data. The control is strongest when the application can no longer treat attacker input as executable structure.
Risk and Threat Considerations
Unsafe deserialisation is attractive to attackers because it can bypass normal input validation and turn a data-handling feature into a code-execution path. The risk is highest where the application deserialises attacker-controlled content into rich objects, especially if the runtime or libraries contain known gadget chains or privileged side effects.
Failure mechanism: A crafted payload reaches a deserialiser that restores object state or resolves types without strict allowlisting, then triggers unintended methods, constructors, or chained library behaviour that changes control flow.
Impact: The attacker may gain code execution, privilege abuse, data tampering, or access to secrets and sessions stored in application memory or reachable through the affected process.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
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 | Deserialisation flaws arise from insecure object handling in application design. |
| V16 — Security Logging and Error Handling | Suspicious parse failures and gadget-chain attempts should be visible in logs. | |
| Recommendation — Remove unsafe deserialisation paths and enforce reject-by-default object handling. Log deserialisation errors and alert on unexpected object creation patterns. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Input Validation | Untrusted serialized input must be validated before it is interpreted as objects. |
| SA-11 — Developer Testing and Evaluation | Deserialisation weaknesses should be found in testing before release. | |
| Recommendation — Validate and constrain serialized input before parsing it. Test for unsafe deserialisation and gadget-chain exposure during development. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Application security controls should reduce exploitable parser and object-handling flaws. |
| Recommendation — Harden application code to avoid unsafe deserialisation of untrusted data. | ||
Practitioner Guidance
What to verify: Identify every code path that deserialises untrusted input, including sessions, caches, queues, webhooks, and internal APIs. If the application cannot prove that the source is trusted and the type set is tightly constrained, treat the path as exposure, not as a benign parser.
Common mistake: Teams often harden only the visible endpoint and miss indirect deserialisation through frameworks, plugins, or background jobs. The dangerous path is frequently one layer away from the obvious request handler.
Decision rule: If the payload can influence type selection, object creation, or privileged post-deserialisation behaviour, prioritise removing the trust boundary over adding more downstream filtering. If patching or redesign must wait, isolate the affected component and watch for anomalous parse-time behaviour and unexpected object instantiation.
Practitioner takeaway: The real control objective is not to inspect every blob after it is parsed, but to prevent untrusted data from becoming trusted program structure in the first place.