Object serialisation is the process of converting an in-memory object into a format that can be stored or transmitted and then reconstructed later. It becomes dangerous when untrusted data is deserialised, because attackers may trigger unexpected code paths, tamper with state, or cause denial of service. Restrict trusted sources and use safe formats.
What Object Serialisation Does
Object serialisation turns an in-memory object into a storable or transmissible representation, then reconstructs it later. That makes it useful for caching, messaging, persistence, and cross-process communication, but it also creates a trust boundary whenever data comes back in.
The core security issue is not serialisation itself, but what happens when a system accepts attacker-controlled input and rebuilds objects from it. If the format or runtime will instantiate classes, restore fields, or trigger hooks during reconstruction, the data stream can influence program behaviour before the application has a chance to validate it.
Why Untrusted Deserialisation Becomes Dangerous
Untrusted deserialisation can become a code-execution path because object graphs often carry more than plain data. Some runtimes allow constructors, callbacks, type metadata, or framework-specific behaviours to run during reconstruction, which can expose dangerous methods or unexpected execution paths.
Even when full code execution does not occur, the attack surface still matters. An attacker may tamper with state, bypass business logic, poison caches, alter permissions, or force expensive parsing and object creation that leads to denial of service.
This is why insecure deserialisation is often discussed alongside object injection and gadget chains. The vulnerability is usually not a single bug in one class, but a chain of apparently safe components that become dangerous when combined through untrusted input.
Where Exposure Usually Comes From
Exposure is often broad because serialisation is embedded in application frameworks, session handling, message queues, APIs, and legacy integrations. A system may not look risky until a feature quietly accepts deserialised payloads from users, partner systems, or shared infrastructure.
Trust boundaries also shift over time. A payload source that was once internal can become internet-facing, or a format chosen for convenience can outlive the assumptions that made it safe. That is why teams should inventory every place where objects are serialised and reconstructed, not just the obvious API entry points.
For deeper defensive background, NHIMG’s Insecure Deserialisation Guide covers object injection, gadget chains, and common runtime-specific patterns such as Java, .NET, PHP, and Python.
Safer Design and Detection Patterns
Safer designs favour data-only formats and strict schemas over native object reconstruction wherever possible. If object serialisation is unavoidable, the parser should accept only trusted sources, allowlisted types, and formats that do not execute application logic during decoding.
Detection should look for both exploitation attempts and after-the-fact compromise. Unusual deserialisation errors, type confusion, unexpected class loading, strange outbound connections, or unexplained state changes can all indicate that a payload was rejected, partially processed, or successfully abused.
After a suspected incident, review whether the application accepted sensitive objects, whether any sessions, API tokens, or secrets were embedded in the payload path, and whether the affected runtime could have triggered persistent state changes that remain after patching.
Risk and Threat Considerations
Object serialisation becomes high risk when the application deserialises untrusted data, because the reconstruction step may invoke application logic before validation. That creates a direct path from malformed input to code execution, state corruption, or denial of service.
Failure mechanism: Attackers supply crafted serialised data that manipulates object metadata, triggers gadget chains, or forces resource-intensive reconstruction, which lets them abuse trusted runtime behaviour.
Impact: Successful exploitation can expose credentials, sessions, keys, or privileged state, and may leave the system compromised even after the vulnerable component is patched.
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, CIS Controls v8 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 | Object deserialisation is an external input path that must be constrained before object reconstruction. |
| AC-6 — Least Privilege | Deserialisation abuse often escalates into privileged actions if runtimes or services run with excess access. | |
| SC-18 — Mobile Code | Deserialised payloads can carry executable behaviour or code-like content that must be tightly controlled. | |
| Recommendation — Validate serialised input and reject unexpected object structures before reconstruction. Limit the privileges of services that parse or rebuild untrusted objects. Restrict code-bearing content and ensure only approved formats are accepted from untrusted sources. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Deserialisation flaws are application-layer weaknesses that require secure design and testing practices. |
| Recommendation — Test application inputs and parsing paths for unsafe deserialisation before release. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Unsafe object reconstruction is a software architecture and coding flaw that ASVS addresses through safer design. |
| Recommendation — Design data handling so untrusted input cannot trigger object instantiation or dangerous callbacks. | ||
Practitioner Guidance
Why practitioners should care: The safest posture is to treat deserialisation as an input-validation problem, not just a parsing problem. The risk rises sharply when convenience formats are used across trust boundaries or when legacy code reconstructs complex objects without a tight allowlist.
Common misunderstanding: Teams often assume that a widely used framework or internal transport channel makes serialised data trustworthy. In practice, trust should come from the sender, the format, and the reconstruction rules, not from familiarity with the library.
Practitioner takeaway: Prefer simple data interchange formats, restrict deserialisation to trusted sources, and test every code path that rebuilds objects from external input.
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 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org