What is a gadget chain?

A gadget chain is a sequence of classes already present in the target application or its libraries, whose lifecycle methods are strung together so that deserializing a crafted object triggers a dangerous end effect like running a command. You rarely write your own malicious class, because the deserializer only rebuilds types it knows about. Instead you pick existing classes (gadgets) whose magic methods call other methods, which call others, until the chain reaches a sink such as a process exec. Tools like ysoserial ship ready-made chains for common libraries, which is why a vulnerable endpoint on a well-known stack is often instantly exploitable.

Can JSON cause deserialization RCE?

Not the JSON format itself, but a library configured for unsafe polymorphic type handling can. When a deserializer is told to honor a type hint embedded in the data (Jackson default typing, .NET JSON.NET TypeNameHandling set to anything but None, or fastjson autotype), the attacker names which class to instantiate, which reopens gadget-chain attacks over plain JSON. So JSON is safe only while the library instantiates fixed, known types; the moment it reads an attacker-supplied class name from the document, it behaves like any other dangerous deserializer.

Is PHP unserialize() always exploitable?

No. unserialize() on untrusted input is only dangerous when the application has a usable gadget: a class that is loaded at the time of the call and whose magic method (__wakeup or __destruct) reaches a dangerous action with attacker-controlled properties. Without such a class in scope, you can forge objects but cannot make them do anything useful. In practice frameworks ship many classes, so gadgets are common, and PHAR deserialization can even trigger it without an explicit unserialize() call, so treat any unserialize() on user data as a serious finding to investigate.

ysoserial is the standard tool for exploiting Java deserialization. It carries a catalogue of known gadget chains for popular libraries (Commons Collections, Spring, ROME, and others) and generates a serialized payload that, when deserialized by a vulnerable Java endpoint with that library on its classpath, runs a command you supply. There is a .NET counterpart, ysoserial.net, which does the same for BinaryFormatter, ViewState, and JSON.NET targets. Both turn the hard part, hand-building a working gadget chain, into a one-line command.

How do I stop insecure deserialization without rewriting everything?

The highest-leverage step is to stop deserializing untrusted data in the dangerous format: switch client-facing data to plain JSON parsed into fixed types, and never feed user input to native deserializers like pickle, BinaryFormatter, or Java ObjectInputStream. Where you must accept serialized objects, integrity-protect them (sign with an HMAC and verify before parsing) so an attacker cannot forge a blob, add a class allow-list (Java ObjectInputFilter), and keep gadget-prone libraries patched. These are configuration and small-surface changes, not a rewrite.

Advanced

Insecure Deserialization: From Serialized Blob to Remote Code Execution

How insecure deserialization becomes RCE: serialized blobs, magic methods, gadget chains, ysoserial, phar, pickle, and how to prevent it. With free practice.

Published October 25, 2026

Insecure Deserialization: From Serialized Blob to Remote Code Execution

Serialization turns an in-memory object into a byte stream so it can be stored or sent, and deserialization rebuilds it. The bug appears when an application deserializes attacker-controlled data, because the act of rebuilding an object can trigger code (constructors, magic methods, type handlers) before the app ever validates it. That turns a seemingly inert data blob into one of the most reliable paths to remote code execution, and it is widespread because developers treat serialized data as trusted. Want to feel it rather than read about it? Sign up free and try it on a live target.

Serialization basics

The mental model in one sentence: serialized data can carry behavior, not just values. A serialized object records its class and its properties, so rebuilding it instantiates that class and populates it, which can run lifecycle code. Apps serialize constantly: session state, caches, message queues, and API payloads. The first spoke covers the formats and why the bytes are dangerous: serialization basics.

Why deserializing untrusted data is dangerous

A safe parser reads data into a fixed structure and nothing else. A deserializer reconstructs an object of whatever type the data names, and runs that type's lifecycle hooks, before your code validates anything. So the dangerous work happens during the parse itself, not after. If an attacker controls the bytes, they control which object is built and with what properties, and the hooks do the rest.

How to identify deserialization

You exploit what you can recognize. Serialized blobs have distinctive signatures (PHP O:, Java rO0AB, .NET __VIEWSTATE or AAEAAAD, pickle opcodes) and ride in predictable carriers (cookies, hidden fields, query and body params, headers, API payloads). Flipping a byte and watching for a parse error confirms the server deserializes your input. See identifying deserialization.

Per-language exploitation

The mechanics differ by ecosystem, so each has its own spoke:

PHP: unserialize() rebuilds objects and fires __wakeup()/__destruct(). See PHP object injection.
Java: ObjectInputStream.readObject() plus library gadgets. See Java deserialization.
.NET: BinaryFormatter and ViewState. See .NET and ViewState.
Python: pickle.loads() is RCE by design. See Python pickle.

Magic methods and gadget chains

You rarely need your own class. A gadget chain strings together existing classes' lifecycle methods so that deserializing a crafted object reaches a dangerous sink. You attack the libraries, not the app. See magic methods and gadget chains.

PHAR deserialization

In PHP you can trigger deserialization with no explicit unserialize() call: on PHP 7.x the phar:// wrapper deserializes a PHAR archive's metadata whenever a file operation touches it. PHP 8.0 restricted this to an explicit Phar::getMetadata() call, so on modern PHP it is a legacy or getMetadata-reachable technique. See PHAR deserialization.

Beyond RCE: memory corruption

When the deserializer is native code, malformed input can cause type confusion or buffer issues, which matters even in memory-safe languages that call native extensions. See deserialization to memory corruption.

Exploiting with tools

ysoserial (Java), ysoserial.net and viewgen (.NET), and hand-built pickles turn gadget construction into one command. See exploiting with tools.

A worked example

Say a PHP app stores a serialized session object in a cookie. You decode it and see a familiar signature:

O:4:"User":2:{s:4:"name";s:3:"bob";s:7:"isAdmin";b:0;}

That is a serialized User object. First you confirm you can tamper it: flip isAdmin to true and re-encode.

O:4:"User":2:{s:4:"name";s:3:"bob";s:7:"isAdmin";b:1;}

If the app trusts the rebuilt object, you are now admin. But the bigger prize is a gadget. Suppose the codebase also loads a Logger class whose __destruct() writes data to logfile. You never instantiate it normally, but you can forge it in the cookie:

O:6:"Logger":2:{s:7:"logfile";s:23:"/var/www/html/shell.php";s:4:"data";s:26:"<?php system($_GET[0]); ?>";}

When the request ends, PHP destroys the forged object, __destruct() runs, and it writes a webshell into the web root. That is the arc: fingerprint the blob, confirm you can tamper it, then forge an object whose lifecycle method reaches a sink.

Prevention

Do not deserialize untrusted data. This is the only complete fix.
Prefer simple formats (JSON, Protobuf) with no polymorphic type handling. Disable Jackson default typing, JSON.NET TypeNameHandling, and yaml.load. Never pickle external input.
Integrity-protect any serialized data you round-trip to clients: sign with an HMAC or encrypt, and verify before parsing.
Allow-list permitted classes (Java ObjectInputFilter, resolver overrides).
Patch gadget-prone libraries and remove unused ones from the classpath.
Least privilege and isolation so a successful RCE is contained.

The full detail is in preventing insecure deserialization.

Where it connects

Deserialization is one of several routes from a web request to code execution. Server-side template injection reaches RCE through a template engine, and OS command injection through a shell. And file upload feeds PHAR deserialization directly, since a polyglot image that is secretly a PHAR becomes the trigger.

Where to go next

Work through the cluster in order, or jump to what you need. Start with serialization basics, then identifying deserialization and PHP object injection. When you want every payload in one place, the cheat sheet has them. And when you are ready to break something real, sign up free and start hacking.