Insecure Deserialization
CWE-502: Deserialization of Untrusted Data
Insecure deserialization occurs when an application rebuilds objects from data an attacker controls using a format that can instantiate arbitrary types. During deserialization, constructors, magic methods, and callbacks run automatically, so an attacker can chain existing classes in the application's libraries (gadget chains) into remote code execution without uploading any code. Java native serialization, .NET BinaryFormatter, PHP unserialize, and Python pickle are the classic dangerous formats.
Ranks change between editions as the underlying CVE data changes, so exam questions rarely hinge on an exact rank. Know what each weakness is, how it is exploited, and how it is prevented.
How it shows up in the real world
- A Java application accepts a serialized object in a cookie, and a ysoserial payload built from a common library's classes runs commands on deserialization.
- A PHP application passes a user-controlled value to unserialize(), triggering a __destruct method that deletes or writes files.
- A machine learning service loads a user-supplied pickle file, which executes code the moment it is loaded.
How to mitigate it
- Do not deserialize untrusted data with formats that can instantiate arbitrary types; use data-only formats such as JSON with explicit schemas.
- If native serialization cannot be avoided, apply strict type allow-lists (for example Java serialization filters) before objects are created.
- Sign or MAC serialized data the server issues and reject anything whose integrity check fails before parsing it.
- Keep libraries patched to reduce known gadget chains, and run deserializing services with least privilege.
Go deeper
Practice this topic
Test your knowledge of Insecure Deserialization with exam-style practice questions.