Modern applications rely on the continuous exchange of data between servers, APIs, and other systems through a process of serialization and deserialization. Both are common mechanisms built into most programming languages and widely used by developers in distributed systems.
But the risk emerges when input data is trusted blindly, giving attackers a path during the deserialization process.
If an application rebuilds objects from untrusted data, malicious logic can be triggered during the process. Powerful features of native serialization mechanisms can then be abused.
In insecure deserializations, if left unchecked, the impact can be severe, ranging from denial-of-service attacks to, in the worst case, a full-blown remote code execution (RCE).
In this blog, we’ll explain what insecure deserialization is, how these attacks occur, how they can be detected, and practical ways to prevent deserialization-related security risks.
What is Serialization?
Let us first explain what serialization is. It is the process of turning complex data structures—for example, objects together with their related fields into a simpler, linear format so that they can be stored or transmitted as a stream of bytes.
Rather than keeping the object exactly as it is in memory, serialization records its structure and values in a form that is portable.
This mechanism makes working with complex data in a variety of environments and across different system boundaries simpler. For instance, serialization enables applications to:
- You can store complex objects in files, databases, or caches and still retain their internal structure.
- Move structured data across networks, for example between microservices or via API requests.
- Data about objects can be shared among the various components of an application or between distributed systems.
One of the key features of serialization is that it keeps track of the object’s state. The attributes of the object together with their present values are stored in order that the same object may be reconstructed later.
The application reconstructs the object with the same properties and values as those it originally had when the serialized data goes through deserialization.
What is Insecure Deserialization?
It starts with a simple data exchange: a system receives a chunk of serialized data and turns it back into a usable object. But when that data comes from outside the organization, and no one checks what’s inside, the process can quietly open the door to security threats.
Attackers have learned to exploit this moment, slipping in instructions that change how the object behaves once it’s rebuilt—sometimes with consequences that only become clear after the damage is done.
In many frameworks, serialized objects may include the following risks:
- Metadata describing the class type and structure can be used to deserialize the object into a completely different class than intended. Their presence in the codebase may modify the runtime environment.
- Insecure deserialization may trigger classes to initiate actions during object reconstruction, such as executing methods, loading files, or interacting with system resources. Attackers can exploit these behaviors to execute malicious logic.
- Attackers can execute remote code, escalate privileges, tamper with data, and carry out denial-of-service conditions.
What makes it dangerous is that it happens during the deserialization process and applications start rebuilding the objects. Before that, it can create malicious code paths.
Types of Insecure Serialization/Deserialization
Not all serialization and deserialization vulnerabilities work the same way. The risk depends on the programming language, the serialization format, and the libraries an application uses. While the underlying issue is similar—accepting untrusted serialized data without proper validation—the exploitation techniques vary across different platforms.
Below are some of the most common types of insecure serialization and deserialization vulnerabilities found in modern applications.
Insecure Deserialization in Java Applications
Insecure deserialization in Java occurs when attackers inject a modified malicious serialized object, causing arbitrary code execution vulnerability.
In the Java deserialization process, the serializable interface enables the reconstruction of Java classes through special methods,such as writeObject() and readObject(). It is done to handle the serialization and deserialization of objects of that class.
Insecure Deserialization Attack with Python Pickle Module
Insecure deserialization in Python pickle module uses binary protocols to serialize and deserialize the object structure. It occurs when the data which is being deserialized exploits the application’s logic to perform unintended tasks, causing Denial of Service (DoS) attacks to execute arbitrary code on the target.
What is the Difference Between Deserialization And Serialization?
Serialization and deserialization processes are complementary to each other during the process of conversion of objects into a storable and transmittable data format. Serialization converts an object’s state into a format, such as JSON, XML, and binary.
This is a critical process for saving projects in the file format, sending objects via a network to preserve the object’s state for the purpose of reconstruction later.
On the other hand, deserialization is used to reconstruct the transmitted data received from a file, database, or a network in the object format. This is necessary to enable the application to use the object as needed.
Both serialization and deserialization are critical processes as they facilitate the secure and efficient transfer of objects between different systems or components of a system.
How Insecure Deserialization Works: Attack Mechanics
The execution flow follows a rigid path from data identification to high-impact compromise.
1. Identification & Baseline:The adversary identifies and monitors application traffic to identify serialized data structures using visual indicators. It includes human-readable PHP strings (O:4:”User”:…) or binary signatures like Java’s hex AC ED (Base64 rO0).
2. Attribute Manipulation: Now, the attacker intercepts and modifies specific fields within the serialized blob. They may do so by flipping a boolean and re-injecting the payload.
3. Type Juggling & Logic Probing: Attackers leverage language-specific quirks, such as PHP’s loose comparison “==”. They modify data types by injecting an integer where a string is expected to bypass authentication checks.
4. Gadget Chain Assembly: The attacker identifies “gadgets” which are existing, legitimate code in the application or its libraries. They together create a path using a “kick-off” magic method like like readObject()) to a dangerous “sink”.
5. Malicious Injection: The final payload is now crafted as an object representing the gadget chain. This is now passed into the vulnerable function.
6. Execution: When the application reconstructs the object, it automatically triggers the attacker’s commands in the application’s context.
Java Deserialization: Example Scenarios
Java deserialization vulnerabilities can appear in several parts of an application, from cookies and session tokens to APIs and message queues. The following examples demonstrate how attackers exploit insecure deserialization in real-world scenarios and the potential impact on application security.
Example Scenario #1: Cookie Manipulation
Let’s consider that a Java application uses native Java serialization to store a Cookie object on the user’s system. This object contains the user’s session identifier that is used by the application to restore the session state.
The serialization code may look like this:
Here, the writeObject() method converts the cookieObj into a byte stream and saves it to a file named cookies.ser. This file now contains a serialized representation of the object.
Later, the application reads this file and reconstructs the object:
The readObject() method takes the byte stream from cookies.ser and reconstructs it into a Cookie object that the application can use again.
This process assumes that the serialized file is trustworthy. If an attacker gains the ability to modify or replace the cookies.User file, they can inject a malicious serialized object.
When the application calls readObject(), it does not just read data, it reconstructs the object in memory. During this process, certain methods inside the object may execute automatically.
An attacker can exploit this behavior by crafting a malicious serialized payload. For example, they could create an object that triggers system commands during deserialization. When the application processes this object, it may unintentionally execute those commands, leading to remote code execution.
Example Scenario# 2: Java Deserialization Exploit Resulting RCE on Thick Client Penetration Testing
While these vulnerabilities are often discussed in the context of web servers, they are equally critical in standalone software.
For a deeper dive into how this looks in practice, our technical breakdown of Java deserialization exploits in thick client penetration testing shows how an attacker can move from intercepting traffic to achieving full Remote Code Execution (RCE) by abusing the way these applications reconstruct Java classes.
Real-World Incidents Involving Insecure Deserialization
Insecure deserialization has been the primary cause of some of the incidents of data breaches recently. Here are a couple of examples:
Example #1 Cisco Identity Services Engine, 2025
A Java deserialization flaw in Cisco ISE allowed authenticated users to send crafted serialized payloads, leading to arbitrary command execution with root-level privileges.
The application accepted serialized input without strict validation or class restrictions. During deserialization, malicious objects triggered unintended execution paths within the system.
Attackers could gain full control over identity infrastructure, risking network-wide compromise, credential exposure, and disruption of access control systems.
Example # 2 Apache Seata, 2026
A deserialization vulnerability in Apache Seata allowed attackers to exploit untrusted data handling, potentially achieving remote code execution across distributed microservices environments.The system processed serialized data from untrusted sources without enforcing integrity checks or safe object constraints, enabling injection of malicious payloads.
Compromise of transaction coordination services could disrupt business operations, corrupt data consistency, and propagate attacks across interconnected microservices.
Mitigation Strategies for Insecure Deserialization
It isn’t a matter of applying one particular solution; rather, it involves reducing trust, tightening the controls, and restricting the kinds of things that the application is permitted to reconstruct. The most secure approach is to entirely avoid deserialising untrusted data—but when that isn’t practical, then these precautions help to mitigate the risk.
- It is advisable not to deserialise untrusted data. If your application fails to deserialise untrusted input then the attack surface is considerably reduced. Whenever possible, redesign the workflows so that safer data exchange formats are used.
- Check the integrity of the data before processing it. Make certain that the data has not been changed. Use digital signatures or message authentication codes (MACs) to guarantee that the object has not been tampered with during transmission. This stops attackers from altering the serialized payloads.
- Impose strict type constraints and do not permit arbitrary object types when deserialising. The deserialisation process should be limited to a predefined list of safe classes. This in turn reduces the likelihood of attackers injecting unexpected or harmful objects into the application.
- Deserialization should be carried out in an isolated environment and it should be executed in a sandbox, container, or in a separate process with the minimum level of permissions. In this way, if malicious code does run, the damage will be contained and will not impact the main system.
- Record and monitor deserialization activity. Make sure you keep thorough records of both successful and failed deserialization attempts.
- Keep an eye on any abnormal system behavior. When deserializing, keep track of CPU usage, memory spikes, file access, and network calls. Changes in system behavior suddenly could be a sign of exploitation attempts, particularly in runtime environments.
- Use simpler and safer data formats; prefer structured formats such as JSON or XML together with strict schema validation over native object serialization. This is because such formats do not automatically rebuild executable objects and are therefore less susceptible to abuse.
- Strengthen the libraries and frameworks. Make use of the secure configurations offered by the modern frameworks. Where possible, turn off the unsafe deserialization features and make use of the built-in protections such as class filtering or safe parsing modes.
- It is important to keep dependencies and software up to date since many deserialization vulnerabilities result from using out-of-date libraries. In order to remove known ways of taking advantage of such vulnerabilities, dependencies should be regularly updated and security patches should be applied, with particular attention being paid to those involving gadget chains.
Wrapping Up
Spotting insecure deserialization rarely happens in a vacuum. Attackers typically chain it with other vulnerabilities, making it tough to catch with source code analysis alone. The real giveaway often surfaces only when you watch how the application behaves at runtime. Dynamic analysis tools and hands-on penetration testing tend to reveal what static scans miss: obscure deserialization paths, risky object handling, and the kinds of exploit chains that show up in real-world breaches.
Looking to strengthen your security posture? SecureLayer7 helps organizations identify vulnerabilities, reduce risk, and defend against evolving cyber threats. Contact our experts to get started.
