Insecure Deserialization: Understanding Java and PHP Gadget Chains

Insecure Deserialization remains one of the most intellectually complex, yet highly destructive, software vulnerabilities listed in the OWASP Top 10. While standard vulnerabilities like XSS trick a browser into rendering a script, insecure deserialization tricks the server's runtime environment into converting malicious byte streams into executing code. This regularly results in unauthenticated Remote Code Execution (RCE).

In this deep-dive article from Cayvora Security, we will explore the underlying concepts of object serialization, how attackers construct property-oriented programming (POP) "gadget chains" in Java and PHP, and definitive mitigation strategies for 2025.

What is Serialization and Deserialization?

Serialization is the process of converting an in-memory object (with its state, attributes, and variables) into a byte stream, JSON string, or XML file. This allows the object to be saved to a database, written to a file, or transmitted over a network.

Deserialization is the exact reverse process: taking that byte stream and reconstructing the object in the computer's memory.

The vulnerability arises when an application receives a serialized object from an untrusted source (like an HTTP cookie, a JSON API payload, or a hidden form field) and deserializes it without first properly verifying its validity and integrity.

The Threat Mechanism: Magic Methods

When an object is deserialized, programming languages automatically invoke specific functions to set up or clean up the object. These are known as "magic methods."

• In PHP, magic methods include __wakeup(), __destruct(), __toString().
• In Java, common methods include readObject().

If an attacker manipulates the serialized data, they can control the attributes of the instantiated object. When the application's runtime naturally calls a magic method on that malicious object, the attacker's manipulated attributes dictate how the method behaves.

Exploiting PHP Deserialization

Let's examine a theoretical, vulnerable PHP snippet utilizing unserialize().

class Logger {
    public $logFile;
    public $logData;

    public function __destruct() {
        // Writes the data to the file when the object is destroyed
        file_put_contents($this->logFile, $this->logData);
    }
}

// The application reads a cookie and unserializes it.
$user_data = unserialize($_COOKIE['pref']);

In standard operation, $user_data might contain user UI preferences. But an attacker realizes that the Logger class is defined somewhere in the application's source code. The attacker crafts a malicious serialized string representing a Logger object:

O:6:"Logger":2:{s:7:"logFile";s:12:"shell.php";s:7:"logData";s:27:"<?php system($_GET['cmd']); ?>";}

The attacker submits this string in the pref cookie.

The Execution Flow: 1. unserialize() reads the string and instantiates a Logger object. 2. The object's properties are set directly from the attacker's string (logFile becomes shell.php, logData becomes the PHP webshell). 3. At the end of the HTTP request, PHP's garbage collector destroys the object, automatically triggering the __destruct() magic method. 4. file_put_contents executes, dropping a backdoor into the web root.

POP Gadget Chains

In modern frameworks with complex autoloading, attackers rarely find a single class with a perfectly vulnerable __destruct() method. Instead, they link multiple classes together. Class A's __destruct() calls a method on an interface, but the attacker sets the interface to point to Class B, whose method inadvertently executes a sensitive function. This sequence of exploiting pre-existing, legitimate code fragments is called a "Gadget Chain." Popular tools like PHPGGC automate the generation of these payloads.

Exploiting Java Deserialization

Java deserialization gained massive notoriety following the discovery of the ysoserial toolkit and the infamous Apache Commons Collections exploitation (e.g., the Equifax breach and WebLogic exploits).

Java handles serialization via the java.io.ObjectInputStream class and its readObject() method. By default, readObject() allows the deserialization of any class that implements the Serializable interface.

// Vulnerable Server Socket implementation
InputStream is = request.getInputStream();
ObjectInputStream ois = new ObjectInputStream(is);
Object obj = ois.readObject(); // VULNERABLE!

The ysoserial Apache Commons Collections Exploit: If the application classpath includes the commons-collections library (version 3.2.1 or prior), attackers can leverage a gadget chain starting with AnnotationInvocationHandler and utilizing ChainedTransformer and InvokerTransformer to achieve arbitrary code execution. The attacker generates the binary payload with ysoserial and sends it to the vulnerable ObjectInputStream. When Java attempts to read the object, it deeply inspects the malicious map, triggering the transformers to execute Runtime.getRuntime().exec().

Prevention and Safe Architectural Design

Insecure deserialization is notoriously difficult to patch cleanly because it relies on the fundamental architecture of the language and installed libraries.

1. Avoid Deserializing Untrusted Data

The only absolute defense is to architectural avoid native deserialization formats (unserialize() in PHP, ObjectInputStream in Java, pickle in Python) when receiving data from the client.

Instead, use safe, standard, language-agnostic data formats like JSON or XML, and parse them securely.

# Unsafe Python:
import pickle
data = pickle.loads(untrusted_input) # RCE Vulnerability!

# Safe Python:
import json
data = json.loads(untrusted_input)

2. Implement Integrity Checks

If you must use native serialization for inter-process communication: 1. Ensure the communication channel is heavily authenticated. 2. Cryptographically sign the serialized object using HMAC or digital signatures before sending it. 3. Before deserializing, verify the signature. If the signature is invalid, reject the payload immediately.

3. Java-Specific: Implement Look-Ahead Validating ObjectInputStream

In Java, if native serialization cannot be removed, you must override resolveClass() in ObjectInputStream to strictly allow-list the classes that are permitted to be deserialized.

public class SecureObjectInputStream extends ObjectInputStream {

    // Define an expansive whitelist of acceptable classes
    private static final List<String> WHITELIST = Arrays.asList("com.cayvora.models.UserSession");

    public SecureObjectInputStream(InputStream in) throws IOException {
        super(in);
    }

    @Override
    protected Class<?> resolveClass(ObjectStreamClass desc) throws IOException, ClassNotFoundException {
        if (!WHITELIST.contains(desc.getName())) {
            throw new InvalidClassException("Unauthorized deserialization attempt of class: " + desc.getName());
        }
        return super.resolveClass(desc);
    }
}

Conclusion

Insecure deserialization allows attackers to hijack the internal workings of the language runtime to execute malicious code using pre-existing code gadgets. By replacing native serialization with strictly typed JSON/XML or enforcing strict object allow-lists, security engineers can permanently close the door on gadget chain exploitation.