CWE-502 is a weakness where software deserialises data from an untrusted source without adequate validation. It applies when an application turns structured input back into objects or commands and the data can influence program behaviour, leading to code execution, logic abuse, or privilege misuse.
What Deserialization Really Does
Deserialization is the process of turning structured data back into runtime objects, state, or executable behaviour. When that input comes from an untrusted source, the application is no longer simply parsing data, it is also accepting instructions about what types to instantiate, what fields to populate, and sometimes what code paths to trigger. That is why CWE-502 is a design and implementation weakness, not just a parsing bug.
In practice, the danger is not limited to one language or framework. Object models, polymorphic type systems, gadget-rich libraries, and permissive loader settings can all make untrusted payloads far more powerful than they appear. The weakness often survives because the code looks like ordinary data handling until a crafted payload changes the program’s control flow.
Why Untrusted Data Becomes Dangerous
The core problem is trust boundary confusion. A serializer often assumes that the producer and consumer share the same type expectations, but an attacker can feed a payload that violates those assumptions and still passes superficial format checks. That can lead to object injection, altered application logic, or execution of methods that were never meant to run on attacker-controlled input.
The impact depends on the framework and the objects available to the runtime. In some ecosystems, a malicious object graph can reach dangerous helpers, trigger file or network actions, or rehydrate privileged state. In others, the risk is less direct but still serious, because deserialised state may influence authorisation decisions, workflow transitions, or integrity checks.
For a broader view of how deserialisation fits into the wider weakness landscape, the CWE Top 25 Guide helps place this issue alongside other high-impact software weaknesses.
How Organisations Reduce Exposure
Exposure starts with identifying every place the application accepts serialised input, especially across APIs, message queues, caches, session stores, and legacy integrations. Organisations should treat internet-facing deserialisation, cross-service deserialisation, and any path that touches privileged application state as higher risk than local-only use.
The safest pattern is to avoid deserialising attacker-controlled objects altogether, or to constrain the input to fixed, expected types with fail-closed settings. Where a platform allows it, allowlist-based type enforcement, restrictive binders, and secure loader configuration reduce the chance that a payload can instantiate unexpected classes. Signing or integrity checks can help for data that must be reloaded later, but they do not replace type safety.
Implementation guidance is well captured in the Secure Deserialisation Guide, which focuses on fixed-type contracts, safe loader settings, and language-specific hardening. For teams looking for the broader vulnerability pattern and common attack shapes, the Insecure Deserialisation Guide is a useful companion reference.
Detection, Remediation, and Post-Exploitation Review
Detection is difficult because deserialisation abuse often blends into normal application traffic. Useful signals include unexpected object types, parsing failures followed by unusual retries, crashes in deserialisation libraries, and suspicious method calls or command execution occurring near input handling. Logging around type resolution and loader decisions can make post-incident review much easier.
Remediation usually means removing unsafe deserialisation paths, tightening type controls, and replacing insecure serializers where the platform permits it. If exploitation is suspected, teams should assume that application state, session material, signing material, or privileged service credentials may have been affected if those values were reachable from the deserialised object graph or adjacent runtime context.
The OWASP A08 guidance on software and data integrity failures is also relevant because insecure deserialisation often becomes a supply of integrity loss rather than a standalone bug. The OWASP Top 10 A08 Guide connects that pattern to signing, provenance, and pipeline trust decisions.
Where This Weakness Sits in Modern Software
CWE-502 remains important because modern applications exchange structured objects everywhere: session state, cached config, event payloads, workflow messages, and agent or integration callbacks. The more a system relies on rich object graphs and implicit type behaviour, the more carefully teams need to define what is allowed to cross the boundary.
That is why secure deserialisation is not just a code review detail. It is part of a wider trust design problem: the application must know which inputs are data, which inputs can influence behaviour, and which inputs should never be rehydrated into executable state at all.
For teams working across AI-enabled platforms and tool-driven runtimes, the Securing Agent Frameworks Guide shows how deserialisation weaknesses can become dangerous when checkpoints, tools, or executors are allowed to consume untrusted state.
Risk and Threat Considerations
Untrusted deserialisation can turn a parsing surface into an execution surface. Attackers look for it because one successful payload can deliver code execution, workflow abuse, or privilege misuse without needing a direct authentication bypass.
Failure mechanism: The application reconstructs attacker-influenced objects or state, and the runtime honours type metadata, callbacks, or gadget behaviour that was never meant to be reachable from untrusted input.
Impact: The result can include remote code execution, application logic abuse, lateral movement through trusted services, or compromise of sessions and credentials that the deserialised object graph can access.
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 | V1 — Encoding and Sanitization | Covers input handling boundaries that unsafe deserialisation bypasses. |
| V15 — Secure Coding and Architecture | Addresses design choices that prevent attacker-controlled object loading. | |
| Recommendation — Validate and constrain external input before it reaches object reconstruction. Redesign deserialisation paths to avoid unsafe polymorphic or reflective loading. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | Directly supports validating structured input before the application uses it. |
| SA-11 — Developer Testing and Evaluation | Supports testing for unsafe object reconstruction and deserialisation flaws. | |
| Recommendation — Apply SI-10 to reject or constrain untrusted serialised content before parsing. Add security testing for unsafe deserialisation paths in development and CI. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Supports secure application design and verification for flaws like deserialisation abuse. |
| Recommendation — Build secure coding checks that flag unsafe deserialisation patterns before release. | ||
Practitioner Guidance
Why practitioners should care: Treat every deserialisation boundary as a trust decision, not a formatting choice. If the application must accept serialised input, the design should make unsafe types impossible rather than merely improbable.
What to watch for: Review any code path that reconstructs complex objects from external sources, especially where the payload can influence class choice, field coercion, or post-load behaviour. Those are the places where a harmless-looking input can become an execution primitive.
Practitioner takeaway: The safest deserialisation strategy is usually the simplest one: accept the least expressive format that still meets the business need, and keep untrusted input away from runtime object reconstruction whenever possible.
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 November 3, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org