Insecure Deserialization Explained: How Broken Data Becomes Code
Attackers manipulate saved data structures to execute commands on your server, bypassing standard input filters and authentication checks entirely.
Insecure deserialization occurs when an application processes untrusted data without verifying its integrity. Attackers craft malicious data payloads that, when reconstructed, execute arbitrary code. This bypasses traditional input validation, allowing remote control of the system. Users should assume any data file from an untrusted source is potentially executable code.
The Postal Service Analogy
Imagine you run a warehouse that receives parcels. Normally, you open the box, check the items, and place them on shelves. This is standard data processing. Now imagine a parcel that contains instructions for rebuilding a machine. When you unpack it, the machine starts moving on its own. It might sort your stock, or it might start breaking other machines. Insecure deserialization is exactly this: the data you receive contains hidden instructions that run automatically when the system processes it.
What Is Deserialization?
Serialisation converts complex data structures into a flat format for storage or transmission. Deserialization reverses this process, rebuilding the original objects in memory. Developers use this to save application state, cache data, or send information between services. The risk arises when the application trusts the incoming data structure implicitly. It assumes the data is safe because it came from a known source or matches an expected format. This assumption is the vulnerability.
| Term | Plain meaning |
|---|---|
| Serialisation | Converting complex data into a linear byte stream for storage or transport. |
| Deserialization | Reconstructing the original data objects from that linear byte stream. |
| Object Injection | Inserting malicious code into a data structure that executes upon reconstruction. |
| Gadget Chain | A sequence of standard library methods that, when triggered, perform harmful actions. |
| Integrity Check | A cryptographic verification that the data has not been altered since creation. |
Why Input Validation Fails
Most security training focuses on cleaning user input. You learn to escape special characters to prevent SQL injection or command injection. These techniques work because the data is treated as text. Deserialization breaks this model. The attacker does not inject text; they inject structure. The application reads the structure and executes methods defined within it. Standard input filters look for keywords like "SELECT" or "DROP". They do not understand object graphs. Therefore, the malicious payload passes through validation checks because it looks like valid, well-formed data to the parser.
The Hidden Cost of Convenience
Developers choose serialisation for speed and simplicity. It preserves complex relationships between data points without manual mapping. This convenience creates a hidden attack surface. Every endpoint that accepts serialised data is a potential entry point for remote code execution. The cost is not just the initial vulnerability; it is the difficulty of detection. Malicious payloads often look identical to legitimate data traffic. Network monitoring tools see valid protocol exchanges. They cannot distinguish between a user saving their preferences and an attacker executing a shell command.
Safety Habits for Users
As an end user, you cannot fix the code running on the server. However, you can reduce your exposure. Never open or upload serialised data files from untrusted sources. These files often have extensions like .ser, .pickle, or .bin. Treat them with the same caution as executable files. If a website asks you to download a "session state" or "configuration backup," verify the source rigorously. Do not assume that a file is harmless because it does not have an .exe extension. Many serialisation formats are executable by design.
Secure Code Review Practices
Developers must treat deserialization as a high-risk operation. The first step is to avoid it entirely if possible. Use text-based formats like JSON or XML for data exchange. These formats do not support object instantiation. If serialisation is unavoidable, implement strict type checking. The deserialiser must only accept specific, whitelisted classes. Reject any object that does not match the expected schema. Additionally, use cryptographic signatures to verify data integrity. This ensures that the data has not been tampered with in transit.
Try This Now
- Audit your application for any endpoints that accept binary or serialised data formats. Identify which libraries handle the reconstruction.
- Implement a deny-list for dangerous classes. Block common utility classes that attackers use in gadget chains, such as those for file manipulation or network sockets.
- Enable logging for all deserialization events. Record the source IP, the timestamp, and the type of object being reconstructed. This aids in post-incident analysis.
Key takeaways
- Data is not inert; reconstructed objects can trigger code execution automatically.
- Standard input sanitisation fails because the threat lives in the structure, not the content.
- Cryptographic signatures prevent tampering but do not stop execution of valid, malicious objects.
Deserialization is dangerous because it executes code hidden inside data structures, bypassing traditional text-based security controls. Move away from binary serialisation formats and use text-based standards like JSON for all new data exchanges.
Frequently asked questions
Is JSON safe from insecure deserialization?
Yes, standard JSON parsers treat data as text and do not instantiate objects or execute code. It is a safer alternative to binary serialisation formats.
Can I fix insecure deserialization with a firewall?
No, standard firewalls cannot inspect the internal structure of encrypted or binary serialised data. You must fix the application logic or use a Web Application Firewall with deep inspection.
Does encryption prevent this vulnerability?
Encryption hides the data but does not validate its safety. An attacker can encrypt a malicious payload, and the application will still execute it upon decryption and deserialization.
How does this relate to prototype pollution?
Prototype pollution targets JavaScript objects by modifying their prototype chain. While the mechanism differs, both vulnerabilities exploit the trust placed in data structures rather than the data content itself.
How this guide was produced: written by the TechSec Observer editorial team with AI assistance, checked against the public references listed below, and reviewed when the facts change. See our editorial policy or report an error.
