What is insecure deserialization?
Last reviewed June 2, 2026
Insecure deserialization (CWE-502) is a vulnerability where an application reconstructs objects from untrusted serialized data without validating it. Attackers can craft serialized payloads that, when deserialized, manipulate application logic or chain through code to achieve remote code execution. Prevention centers on not deserializing untrusted data and using safe, data-only formats.
What insecure deserialization is
Serialization turns an in-memory object into a byte stream for storage or transport; deserialization reverses it. Insecure deserialization, tracked as CWE-502 (Deserialization of Untrusted Data), occurs when an application deserializes data from an untrusted source without verifying that the data is safe and of the expected type.
The danger is that native serialization formats in many languages can encode arbitrary object types and trigger code during reconstruction. Feeding attacker-controlled data into such a deserializer can do far more than populate a data structure.
How the attack works
An application accepts a serialized object, for example in a cookie or an API request, and deserializes it with a native library. The attacker crafts a payload describing objects whose construction or callback methods perform dangerous actions. As the deserializer rebuilds these objects, those methods fire.
Attackers assemble these into gadget chains: sequences of existing classes already on the application's classpath that, when wired together through deserialization, culminate in command execution. Public tools maintain ready-made gadget chains for popular frameworks, so a single exposed deserializer can mean immediate remote code execution.
Real-world impact
- Remote code execution, the most severe and common outcome.
- Authentication bypass or privilege escalation by tampering with object state.
- Denial of service through objects that consume excessive resources.
- Logic manipulation when trusted application state is forged.
How to prevent it
The strongest control is architectural: avoid deserializing untrusted data at all, and exchange plain data formats bound to expected types instead of serialized objects.
- Do not deserialize data from untrusted sources with native object serializers.
- Prefer simple, data-only formats like JSON and bind them to known, explicit types rather than arbitrary objects.
- If native deserialization is unavoidable, enforce strict type allowlists (look-ahead filtering) and integrity checks such as signatures on the serialized data.
- Keep serialization libraries patched, since new gadget chains are discovered regularly.
- Run the process with least privilege so a successful exploit is contained.
Keep exploring
- CWE-502: Deserialization of Untrusted DataThe MITRE weakness entry this article maps to.
- What is remote code execution?The usual end goal of a deserialization exploit.
- What is SQL injection?Another untrusted-input flaw with severe consequences.
- Browse the CWE directoryExplore the full catalog of weakness types.
Frequently asked questions
- What is insecure deserialization in simple terms?
- It is when an application rebuilds objects from data sent by an untrusted user. A crafted payload can make the rebuilding process run code or tamper with the application's state.
- What is a gadget chain?
- A gadget chain is a sequence of classes already present in the application that an attacker wires together through deserialization so that reconstructing them ends in a dangerous action like command execution.
- How do you prevent insecure deserialization?
- Avoid deserializing untrusted data with native serializers, use plain data formats like JSON bound to known types, apply type allowlists and integrity checks if you must, and keep libraries patched.
- Which CWE covers insecure deserialization?
- It is CWE-502, Deserialization of Untrusted Data.
