What Is Insecure Deserialization and Why Is Java So Vulnerable?

Insecure deserialization lets attackers execute arbitrary code by sending crafted serialized objects to any endpoint that deserializes them without verification. Java is especially vulnerable because its native serialization format is widely used, the attack gadget chains are well-documented, and millions of production applications still accept serialized Java objects from untrusted sources.

Analysis Briefing

• Topic: Insecure deserialization vulnerability mechanics in Java applications
• Analyst: Mike D (@MrComputerScience)
• Context: A structured investigation kicked off by Claude Sonnet 4.6
• Source: Pithy Cyborg | Pithy Security
• Key Question: How does accepting a serialized Java object from an untrusted source lead to remote code execution?

---

Why Deserialization Executes Code You Did Not Write

Java’s serialization mechanism reconstructs objects from byte streams by calling class constructors and methods during the deserialization process. Some classes execute code in their readObject() method, which is called automatically during deserialization. An attacker who controls the serialized stream controls which classes are instantiated and which methods are called during reconstruction.

Gadget chains are sequences of existing, legitimate Java classes whose normal methods, when invoked in a specific order during deserialization, collectively perform a malicious action. The Apache Commons Collections library contains a well-known gadget chain that, when deserialized, executes an operating system command. Every Java application that has Apache Commons Collections on its classpath and deserializes untrusted data is potentially vulnerable to remote code execution through this chain, regardless of whether the application ever intentionally uses the gadget chain classes.

The ysoserial tool, released publicly in 2015, automates the generation of malicious serialized payloads for dozens of known gadget chains across common Java libraries. Any developer or attacker can generate a payload targeting Commons Collections, Spring Framework, Hibernate, and many other common dependencies in minutes. The attack is not theoretical and does not require deep Java expertise to execute.

Where Insecure Deserialization Appears in Java Applications

Java RMI (Remote Method Invocation) endpoints accept serialized Java objects by design. Legacy enterprise applications that use RMI for inter-service communication expose a deserialization endpoint on every RMI port. These ports are often firewalled internally but visible within the corporate network, making them attractive lateral movement targets.

JMX (Java Management Extensions) ports accept serialized objects for management operations. JMX is enabled by default in many application servers and often exposed without authentication in internal environments. It is a common finding in enterprise penetration tests.

HTTP endpoints that accept serialized Java objects in request bodies are the broadest attack surface. Applications that use Java serialization for session state, caching, or inter-service communication may expose endpoints that deserialize user-supplied data. The Content-Type: application/x-java-serialized-object header in request traffic is a reliable indicator of such endpoints.

Custom binary protocols in thick client applications frequently use Java serialization for client-server communication. The thick client serializes requests and sends them to the server. An attacker who can modify the serialized stream before it reaches the server has a deserialization attack surface.

The Fixes That Eliminate the Vulnerability Class

Avoiding Java native serialization is the most reliable fix. Modern Java applications should use JSON with Jackson or Gson, Protocol Buffers, or other format-specific serializers that do not execute arbitrary class constructors during deserialization. Replacing Java serialization with a format that does not support arbitrary object instantiation eliminates the gadget chain attack surface entirely.

For applications that cannot migrate away from Java serialization, the Java Serialization Filtering introduced in JDK 9 and backported to JDK 8u121 allows applications to specify which classes are permitted to be deserialized. A whitelist that permits only the specific classes the application legitimately deserializes blocks gadget chain exploitation even when vulnerable libraries are present on the classpath.

// Configure global serial filter to block dangerous classes
ObjectInputFilter.Config.setSerialFilter(info -> {
    String className = info.serialClass() != null ?
        info.serialClass().getName() : "";
    // Reject known gadget chain classes
    if (className.startsWith("org.apache.commons.collections") ||
        className.startsWith("org.springframework") ||
        className.startsWith("com.sun.org.apache.xalan")) {
        return ObjectInputFilter.Status.REJECTED;
    }
    return ObjectInputFilter.Status.UNDECIDED;
});

The modern buffer overflow vulnerabilities that persist despite decades of awareness follow the same pattern as insecure deserialization: the vulnerability class is well understood, the fixes are documented, and it keeps appearing because existing code is never fully migrated.

What This Means For You

• Grep your codebase for ObjectInputStream and audit every usage. Any code that creates an ObjectInputStream from an untrusted source is a deserialization vulnerability candidate. There should be very few legitimate uses of Java native deserialization in modern code.
• Enable Java Serialization Filters if you cannot eliminate native deserialization. A class whitelist that permits only the specific types your application deserializes blocks gadget chain exploitation without requiring a full migration.
• Scan for open RMI and JMX ports in your internal network and disable or authenticate them. These ports are common findings in penetration tests precisely because they are enabled by default and frequently forgotten.
• Add application/x-java-serialized-object to your WAF blocking rules for any external-facing endpoint. Legitimate external clients should not be sending serialized Java objects to your web application.

---

Enjoyed this deep dive? Join my inner circle:

• Pithy Cyborg → AI news made simple without hype.
• Pithy Security → Stay ahead of cybersecurity threats.