flawopen.com/Insecure Deserialization/Java ObjectInputStream

Is Java's ObjectInputStream safe from deserialization attacks?

Reference page — draft, pending review
ELI5

No — readObject() on untrusted data is one of the most well-documented remote-code-execution vectors in the Java ecosystem, exploited via "gadget chains" built from classes already present on the classpath (including common libraries), not just custom application code.

DANGEROUS
ObjectInputStream in =
  new ObjectInputStream(untrustedStream);
Object obj = in.readObject();
SAFER ALTERNATIVE
// use a data-only format instead
MyDto obj = objectMapper.readValue(
  untrustedBytes, MyDto.class
);

What makes this especially dangerous in Java

Unlike a hypothetical custom exploit, Java deserialization attacks commonly use "gadget chains" — sequences of method calls across classes already present in common libraries (some logging frameworks, collection utilities, and others have historically been implicated) that, when chained together during deserialization, achieve code execution. This means the attack surface isn't limited to your own classes; it depends on every serializable class reachable on the whole application's classpath, including third-party dependencies.

If you must accept serialized Java objects

FAQ

Is this the same underlying issue as Python's pickle?

Same shape — deserialization triggering unintended code execution — different mechanism. Java's risk centers on gadget chains across the classpath; Python's centers on pickle's format directly encoding callable invocations.

References