Deserialization Attacks: Exploiting Data Processing Vulnerabilities to Execute Malicious Code on Servers

To understand the attack, we must first firmly grasp the legitimate mechanisms involved.

What is Serialization?

Imagine a complex Java object representing a UserSession. This object exists in the server's memory and contains various attributes (username, role, preferences) and methods. You cannot simply send this memory structure directly over an HTTP connection or save it to a text file.

Serialization is the process of translating this complex in-memory object state into a standardized, sequential format (like a byte stream, JSON, XML, or YAML) that can be easily stored or transmitted across a network. It is akin to taking a fully built LEGO castle and breaking it down into a list of specific bricks and their exact coordinates, writing that list on a piece of paper, and mailing it to someone else.

What is Deserialization?

Deserialization is the exact reverse of this process. The receiving application takes the byte stream or formatted text (the list of LEGO instructions) and reconstructs the complex object perfectly back into the server's memory, ready to be used by the application logic.

Languages like Java, Python (Pickle), PHP, and Ruby have native serialization capabilities deeply integrated into their core libraries.

The vulnerability arises entirely from a failure of trust. A deserialization attack succeeds when an application takes serialized data provided by the user (such as via a cookie, an API payload, or a hidden form field) and deserializes it without first verifying that the data has not been tampered with.

The attacker's goal is not necessarily to manipulate the data within the object (e.g., changing their role from "user" to "admin," though that is a related vulnerability). The advanced goal is to manipulate the code execution flow during the actual reconstruction process.

Magic Methods and the "Gadget Chain"

In object-oriented languages, certain methods (often called "magic methods" in PHP, or specific readObject methods in Java) are executed automatically by the language's runtime environment during the deserialization process. They are designed to help the object re-establish its state (e.g., automatically reopening a database connection when the object is rebuilt).

An attacker exploits this by analyzing the application's source code and its dependencies (third-party libraries) to find classes that have dangerous operations inside these automatically executed magic methods—for example, a class whose __destruct() method accidentally allows command execution or file deletion.

The attacker then crafts a serialized payload containing an instance of this specific, vulnerable class. When the vulnerable server deserializes the payload, the language runtime automatically calls the magic method on the newly constructed object, inadvertently executing the dangerous operation.

Often, a single vulnerable class isn't enough to achieve RCE. Attackers must string together multiple classes present in the application's environment. The output of one class's magic method feeds into the input of another, creating a complex, Rube Goldberg-esque sequence of executions known as a "Gadget Chain." The ultimate goal of the gadget chain is to eventually reach a method that executes arbitrary system commands (e.g., Runtime.exec() in Java or system() in PHP).

Deserialization vulnerabilities are notoriously difficult to identify through automated scanning, but when successfully exploited, they yield total system compromise.

Perhaps the most infamous example is the Apache Struts 2 vulnerability (CVE-2017-5638), which led to the massive 2017 Equifax data breach. The vulnerability existed in the Jakarta Multipart parser, which improperly deserialized HTTP Content-Type headers. Attackers crafted malicious OGNL (Object-Graph Navigation Language) expressions within the header. When the Struts framework attempted to parse (deserialize) the header, it automatically evaluated the malicious expressions, granting the attackers unauthenticated Remote Code Execution on the Equifax web servers, ultimately leading to the theft of personal data belonging to 147 million people.

Another classic example involves Java deserialization vulnerabilities found in common middleware like WebSphere, WebLogic, and JBoss. Security researchers (notably Chris Frohoff and Gabriel Lawrence, creators of the ysoserial tool) discovered that widely used Java libraries, such as Apache Commons Collections, contained classes that could be assembled into gadget chains. Any application that accepted serialized Java objects and had Commons Collections on its classpath was instantly vulnerable to RCE. Attackers could simply generate a payload using ysoserial and send it to an exposed endpoint, gaining total control over the enterprise server.

Defending against deserialization attacks is complex because the vulnerability lies deep within the language runtime and how the application handles data architecture. There is no simple "patch" or input sanitization technique that can fully mitigate the risk if native serialization is used improperly.

1. Avoid Native Serialization Formats

The most effective defense is architectural: do not use native serialization formats (like Java Object Serialization, Python Pickle, or PHP serialize()) for data that crosses trust boundaries. If you must accept data from a user or an external system, use safe, data-only formats like JSON or simple XML. These formats only transfer primitive data types (strings, numbers, booleans) and do not allow the instantiation of arbitrary classes or the execution of magic methods during parsing. While JSON parsers can have vulnerabilities, they do not inherently suffer from the object reconstruction flaws that make native serialization so dangerous.

2. Implement Cryptographic Signatures (HMAC)

If an application absolutely must use native serialization to maintain state (e.g., passing a serialized object in a session cookie), the serialized data must be cryptographically signed. The server should generate an HMAC (Hash-based Message Authentication Code) using a strong, secret key and append it to the serialized data before sending it to the client.

When the client returns the data, the server must recalculate the HMAC and verify that it matches the one provided. If an attacker tampers with the serialized payload to inject a gadget chain, the HMAC will be invalid. Crucially, the server must reject the data before any deserialization occurs.

3. Strict Type Checking and Deserialization Allow-lists

If you are forced to deserialize untrusted native objects, you must strictly control what classes are allowed to be instantiated. Modern languages and frameworks provide mechanisms to enforce strict type checking during the deserialization process.

Implement an "allow-list" (or whitelist) approach. You explicitly define the exact, safe classes that the application is permitted to deserialize. If the incoming byte stream attempts to instantiate a class not on the allow-list (such as a class known to be part of an exploit gadget chain), the deserialization process throws an exception and halts immediately, neutralizing the attack.

4. Isolate and Monitor (Defense in Depth)

Assume that a deserialization zero-day might eventually bypass your controls. Apply robust defense-in-depth principles. Run the application service with the absolute lowest privileges necessary. Implement strict network egress filtering; if an attacker achieves RCE via deserialization, they will typically try to download a secondary payload or establish a reverse shell. Restricting outgoing network traffic from the application server can effectively break the kill chain of a successful exploit. Furthermore, deploy Runtime Application Self-Protection (RASP) agents that can monitor the execution flow in real-time and block unexpected command executions originating from the application process.