Deserialisation converts stored or transmitted data back into an in-memory object, structure or message that software can use. It must validate format, type and length before rebuilding the object, because untrusted input can trigger unexpected behaviour, resource exhaustion or code execution. Restrict accepted types, reject malformed data, and avoid deserialising data from untrusted sources unless necessary.
What deserialisation actually does
Deserialisation is the reverse of serialisation. Software takes data that was stored on disk, sent over the network, or received from another process and rebuilds it into an object, message, or structured value that the application can work with. The key point is that the input is data first, not trusted program state, so the parser has to decide what shape it is willing to reconstruct.
That reconstruction step is where the security boundary matters. If the format is ambiguous, the type is unexpected, or the payload is larger or more complex than intended, the runtime may allocate excessive memory, recurse too deeply, or invoke application logic the developer did not expect. Deserialisation becomes risky when the software treats untrusted bytes as if they were already safe, well-formed application objects.
Why type, length, and structure checks matter
A safe deserialiser should not merely "read" the payload, it should enforce what the application expects to accept. That means checking the format, bounding the length, and validating the type or schema before any object is rebuilt. The controls exist to stop malformed or malicious inputs from becoming executable application state, and to prevent oversized payloads from exhausting CPU, memory, or downstream resources.
In practice, the most important design decision is whether the application accepts a narrow, explicit set of data shapes or tries to be flexible with many object types. Narrow acceptance is safer because it reduces the attack surface and makes parsing predictable. Flexible deserialisation often becomes fragile when the software has to support legacy types, optional fields, or object graphs that were never meant to come from outside the trust boundary.
The NHIMG Web Application Attacks Guide places insecure deserialisation in the wider set of application-layer attack patterns, which is useful because deserialisation flaws rarely exist in isolation. They often combine with input validation failures, parser confusion, or other request-processing weaknesses.
What makes untrusted deserialisation dangerous
The core danger is that deserialisation can turn attacker-controlled data into an object that carries behavior, not just content. In some runtimes, that behavior may be triggered by hooks, constructors, callbacks, or gadget chains that execute during object reconstruction. Even when code execution does not occur, the same flaw can still be used to tamper with application state, bypass logic, or force denial of service through resource exhaustion.
Attackers like deserialisation weaknesses because they sit close to the application's internal trust model. Once the parser accepts a crafted payload, the rest of the program may treat the rebuilt object as legitimate. That is why the line between "data parsing bug" and "security issue" is often crossed very quickly, especially when the application accepts input from a client, a queue, a cookie, a cache entry, or another service without strong validation.
The Insecure Deserialisation Guide is the most direct reference for the attack pattern itself, including object injection, allowlisting, and the risks of deserialising untrusted data across common languages and frameworks.
Risk and Threat Considerations
Deserialisation is risky whenever external input can reach the object reconstruction path, because the application may transform hostile bytes into trusted internal state before validation is complete. The danger is not limited to remote code execution: malformed payloads can also trigger crashes, memory pressure, logic corruption, or hidden parser behavior that is hard to detect in testing.
Failure mechanism: The application accepts an untrusted payload, reconstructs an object graph or message without strict type and size controls, and then executes implicit behavior or consumes excessive resources during parsing.
Impact: The result can be application compromise, denial of service, integrity loss, or a foothold for broader exploitation if the deserialised object influences authentication, authorisation, or downstream processing.
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 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V2 — Validation and Business Logic | Deserialisation depends on strict input validation and safe handling of untrusted data. |
| V15 — Secure Coding and Architecture | Safe deserialisation is an application-architecture concern that should minimise unsafe parsing paths. | |
| Recommendation — Validate deserialised input against explicit schemas and reject unexpected types before object creation. Design parsing flows so untrusted data cannot reach object creation without an explicit trust check. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Application security controls cover unsafe parsing, dependency abuse, and prevention of code-execution paths. |
| Recommendation — Review application parsing paths and remove unsafe deserialisation patterns from production code. | ||
| MITRE ATT&CK | T1059 — Command and Scripting Interpreter | Insecure deserialisation can lead to code execution through attacker-controlled object behavior. |
| Recommendation — Correlate deserialisation flaws with post-exploitation execution paths in detection and hunting. | ||
Practitioner Guidance
What to verify: Confirm where deserialisation actually occurs in the request path, not just where objects are eventually used. The most useful review is to trace every inbound source, including APIs, message queues, caches, cookies, session stores, and inter-service calls, and verify whether each source is trusted by design or merely assumed to be trusted.
Decision rule: If the payload can originate outside a tightly controlled boundary, treat deserialisation as a security-sensitive parser, not a convenience function. Prefer explicit schemas, fixed message formats, and allowlisted types; if the application needs to accept arbitrary object graphs, assume the risk is high until proven otherwise.
What practitioners underestimate: Many teams focus on gadget chains and miss the simpler failure modes, such as oversized payloads, parser recursion, or type confusion that causes unsafe branching. Those issues may be enough to create a serious incident even when code execution is not demonstrated.
Practitioner takeaway: The safest deserialisation path is the one that reconstructs only the smallest necessary data shape from trusted sources, with every other input treated as hostile until validated.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org