hunting-java-deserialization-gadget-chains

Hunting Java deserialization gadget chains: when reading an object runs code

Java native serialization was never a trust boundary, but it is treated as one every time a service accepts a serialized object from a client, a queue, a cache, or a cookie and calls readObject. The danger is not the deserialization call by itself; it is the combination of that call with a gadget, an already-present library class whose own readObject, readResolve, or finalizer performs a side effect an attacker can steer. Chained together, ordinary library classes reconstruct into a sequence that ends in a runtime command, a naming lookup, or a template evaluation. You find these by locating every place untrusted bytes reach a deserializer and then asking which reachable library versions on the classpath carry a chain that fires on reconstruction.

When to use

• A service reads serialized Java objects from a client, a message queue, a cache, a file, or a cookie.
• Untrusted input reaches readObject, an ObjectInputStream, or a framework method that deserializes.
• Reachable library versions on the classpath are known to carry a deserialization gadget.

Scope check

Test deserialization only against services and applications you own or are authorized to assess, on non-production infrastructure. A confirming payload runs code on the target, so treat every proof as a live intrusion and stay inside the authorized scope. If you can't name the authorization, stop.

The loop

1. Establish the deserialization sinks first. Before chasing gadgets, inventory every call that turns bytes into objects: ObjectInputStream.readObject, readUnshared, framework converters that accept a serialized object, and any wrapper that hides one. This is the false-positive killer: a gadget on the classpath is harmless if no untrusted stream ever reaches a deserializer. Name the sinks, then work backward.

2. Trace untrusted bytes into each sink. Follow request bodies, headers, cookies, queue messages, cache entries, and uploaded files into the deserializer. A stream the service itself produced and never exposes is not a source; a stream any client, or any producer on a shared bus, can supply is. Confirm the bytes crossing the boundary are attacker-influenced, not merely internal.