Java serialization and its risks

Java can turn an object graph into bytes (Serializable) and back. It is convenient and built into old frameworks (sessions, RMI, JMS object messages), but it is fragile across versions and a classic source of remote code execution.

A mental model

Flat-pack furniture with instructions in your own language. Fine between two identical workshops, but if you accept boxes from strangers and assemble them blindly, someone can slip in a trap.

How it works

A class implementing Serializable can be written with ObjectOutputStream.writeObject(obj) and read with ObjectInputStream.readObject(). All fields are saved except transient and static ones.

serialVersionUID identifies the class version. If it changes (or is missing and the class changes), reading old bytes throws InvalidClassException.

Hooks readObject, writeObject, readResolve customise the process (for example re-creating a singleton or validating state).

HTTP sessions in a cluster, caches (Redis with the JDK serializer), and JMS ObjectMessage often use it behind the scenes.

Going deeper

Never deserialize untrusted bytes. During readObject the JVM instantiates classes named in the stream and runs their methods; chains of common library classes (gadget chains) turn that into arbitrary code execution. Use an ObjectInputFilter allow-list at minimum, and prefer JSON or Protobuf for anything that crosses a trust boundary.

Serialized form leaks the internal structure of a class. Adding a field, renaming a class or moving a package breaks stored data, so long-lived data should use an explicit schema format instead.

Fields that are not serializable (connections, threads, loggers) must be transient or the write fails with NotSerializableException at runtime, often in production only.

Under the hood

The stream starts with class descriptors (name, UID, field names and types) followed by field values; object references are tracked in a handle table, so shared objects and cycles are preserved. Deserialization bypasses constructors for the serializable class, which is why invariants checked in constructors can be violated unless readObject validates them.

Common mistakes

• Deserializing untrusted input.
• Missing or changing serialVersionUID unintentionally.
• Storing Java-serialized data long-term.
• Non-transient fields holding resources.