Insecure deserialization is a vulnerability where an application rebuilds (deserializes) objects from untrusted input without validating it, so an attacker crafts a serialized payload that executes code or alters application logic when it is loaded. Because deserialization can instantiate arbitrary objects and trigger their methods, it frequently leads to remote code execution through gadget chains. It is caused by trusting serialized data from users or cookies, and the fix is to avoid deserializing untrusted input or use safe, data-only formats.
What insecure deserialization is
Applications serialize objects (turn them into a byte or text stream) to store or transmit them, then deserialize to rebuild them. The danger is that rebuilding an object can run code: constructors, magic methods, and library callbacks fire during deserialization.
Insecure deserialization is feeding attacker-controlled serialized data into that process. The attacker crafts a payload that, when deserialized, chains existing classes (a gadget chain) into a dangerous action such as running a command.
How it works and example
The attacker supplies a malicious serialized object where the app expects a trusted one (a cookie, a hidden field, an API body, a cache entry):
- Java: a serialized object using a known gadget chain (tools like ysoserial generate these) to reach
Runtime.exec. - PHP: an
O:serialized string crafted so a class’s__wakeup/__destructperforms a dangerous action (PHP object injection). - Python: a malicious pickle that runs code via
__reduce__when loaded. - .NET: gadget chains via
BinaryFormatter.
The payload runs as the application loads it. Examples shown for defensive context.
How to fix it
- Do not deserialize untrusted input with formats that can instantiate arbitrary objects (pickle, Java native serialization, PHP unserialize, BinaryFormatter).
- Use data-only formats like JSON with a strict schema, mapping to known types.
- Integrity-protect any serialized data you must round-trip to a client (sign it) so it cannot be tampered with.
- Restrict allowed classes (look-ahead deserialization / allow-lists) where the format supports it.
- Patch libraries and test endpoints that accept serialized objects.
References
- [1]OWASP: Deserialization(OWASP)
- [2]MITRE CWE-502: Deserialization of Untrusted Data(MITRE CWE)
- [3]OWASP Top 10(OWASP)