Deserialization and gadget chains

01The wire format, verified

A 77-byte stream holding one small object, produced on JDK 21.0.10:

static class Token implements Serializable {
    private static final long serialVersionUID = 1L;
    String user  = "paul";
    int    level = 3;
}

$ xxd -l 32 token.ser
00000000: aced 0005 7372 0009 5365 7224 546f 6b65  ....sr..Ser$Toke
00000010: 6e00 0000 0000 0000 0102 0002 4900 056c  n...........I..l

Spotting it in traffic

Base64-encoded, ac ed 00 05 becomes the prefix rO0AB:

$ base64 < token.ser | head -c 12
rO0ABXNyAAlT
   ^^^^^ this prefix in a cookie, header, form field or JSON string
         means a Java object stream

# Sweep a traffic capture or log for both forms
$ grep -rao 'rO0AB[A-Za-z0-9+/=]*' ./logs | head
$ grep -rlaP '\xac\xed\x00\x05' ./captures

02Why the cast is too late

The ordering inside ObjectInputStream is what makes this unfixable at the call site:

readObject()
  └─ readObject0()
       └─ readOrdinaryObject()
            ├─ readClassDesc()        // resolve the class NAMED IN THE STREAM
            ├─ newInstance()          // allocate, no constructor for Serializable
            └─ readSerialData()
                 └─ invokeReadObject()  // calls the CLASS'S OWN readObject —
                                       // arbitrary code, by reflection
  // ... only now does readObject() return

Session s = (Session) in.readObject();   // <-- your check happens HERE

Each nested object repeats the cycle. A stream containing a graph of a hundred objects runs a hundred readObject methods before a single line of your code executes.

// All three of these are equally too late
Object o = in.readObject();
if (!(o instanceof Session)) throw new SecurityException();
if (!o.getClass().getName().startsWith("com.example")) throw …;
try { Session s = (Session) o; } catch (ClassCastException e) { … }

The payload never needs to be a Session. It only needs to be deserialized. A ClassCastException in your log is often the evidence of a successful attack, not the sign of a blocked one.

03What a gadget chain is

An attacker does not ship code in the stream — bytecode is not transmitted. They ship data that steers classes already on your classpath into doing something useful.

A gadget is any class that, during deserialization or shortly after, calls a method on a field it holds. Chain enough of them and the final call is something dangerous. The requirements:

• An entry gadget whose readObject, readResolve, hashCode, equals or toString is invoked during deserialization.
• Link gadgets that forward a call to a field.
• A terminal that reaches reflection or process execution.

04The CommonsCollections shape

The classic chain, described structurally rather than as a working payload:

// Structure of the transformer array — the "program" in the data.
new ConstantTransformer(Runtime.class),
new InvokerTransformer("getMethod", …,  {"getRuntime", …}),
new InvokerTransformer("invoke",    …,  {null, …}),
new InvokerTransformer("exec",      …,  {command})

Read it as four reflective steps: get the Runtime class, find getRuntime, invoke it, then invoke exec on the result. Every individual operation is legitimate; the composition is the exploit — the same structure as the S2-045 chain, where each step was also ordinary code.

Tooling (ysoserial and successors) maintains dozens of these across Commons Collections, Commons BeanUtils, Spring, Groovy, Hibernate, ROME, C3P0 and more. Assume that if a stream reaches readObject on a realistic classpath, a chain exists.

05ObjectInputFilter

Java 9 added a hook consulted per class, before instantiation — early enough to matter.

ObjectInputFilter filter = ObjectInputFilter.Config.createFilter(
    "com.example.Session;" +      // allow exactly what we expect
    "java.base/java.lang.String;" +
    "!*");                          // reject everything else

try (ObjectInputStream in = new ObjectInputStream(src)) {
    in.setObjectInputFilter(filter);
    Session s = (Session) in.readObject();
}

"!org.apache.commons.**"          // blocks one library, allows the rest

"com.example.**;java.base/*;!*"   // allow-list, closed at the end

A JVM-wide default

# Applies to every ObjectInputStream without its own filter
$ java -Djdk.serialFilter='!org.apache.commons.**;!bsh.**;maxdepth=20;!*' …

# For the lab Tomcat:
$ CATALINA_OPTS="-Djdk.serialFilter=com.example.**;java.base/*;!*" \
    ~/tools/tomcat/bin/catalina.sh run

Useful as a compensating control when you cannot change the code — a legacy application, a third-party WAR. It is a mitigation with real bypass risk if the allow-list is wide, not a substitute for removing the sink.

What it costs you

A filter is a behaviour change. Streams that used to deserialize now throw InvalidClassException: filter status: REJECTED. That is the point, but it means the allow-list has to be derived from what the application legitimately sends — log rejections in a staging environment before enforcing in production.

06The same bug in other parsers

Java serialization is the famous case. The pattern — data naming the type to construct — recurs:

XMLDecoder deserves its own warning. It is not a deserializer that happens to be dangerous — it is a scripting format. A document can express <object class="java.lang.ProcessBuilder"> directly, with no gadget chain required. There is no safe configuration for untrusted input.

07Finding it

# Sinks in source
$ grep -rnE 'ObjectInputStream|readObject\(|XMLDecoder|SerializationUtils\.deserialize' src/

# Polymorphic JSON and YAML
$ grep -rnE 'activateDefaultTyping|enableDefaultTyping|JsonTypeInfo|new Yaml\(' src/

# Classes that implement readObject — your own potential gadgets
$ grep -rn 'private void readObject' src/

# Known chain-bearing libraries actually present in the artifact
$ unzip -Z1 app.war 'WEB-INF/lib/*' | grep -iE \
    'commons-collections|commons-beanutils|groovy|rome|c3p0|javassist|aspectjweaver'

# Is a filter configured anywhere?
$ grep -rn 'setObjectInputFilter\|jdk.serialFilter' src/ conf/ bin/

Reaching a verdict

The questions, in the order that settles the finding:

1. Does untrusted data reach a deserialization sink? Trace it. A readObject on a file the application wrote itself is not the same finding as one on a request body or cookie.
2. Is there a filter, and does it close with !*? An open-ended filter is close to no filter.
3. What is on the classpath? Relevant to exploitability — but absence of a known-gadget library is not a clean bill of health. It bounds your demonstration, not the risk.