The Best Deserialization Tools in 2026

A tools listicle is only useful if the author actually uses the tools. This is the short list of insecure deserialization tools I have spent real engagement hours with in 2026, ranked by how often I reach for each one, with honest notes on where each fits and where each falls short.

If you want the underlying mechanics first, the insecure deserialization deep dive covers gadget chains, magic methods, and the vulnerable language runtimes. This article is for the choice of which tool to run once you have a sink.

The decision matrix

A quick read of the table: ysoserial is the default for Java, ysoserial.net for .NET, PHPGGC for PHP. Marshalsec fills the gaps ysoserial misses on JSON/YAML/XML parsers. Burp's scanner is the manual workflow companion. GadgetInspector is research-grade, not engagement-grade. Python has no canonical tool, and pretending otherwise is dishonest.

1. ysoserial

Repo: github.com/frohoff/ysoserial

The default for Java. If you only learn one tool in this list, learn this one.

ysoserial generates serialized Java objects that, when deserialized by a vulnerable application, trigger arbitrary command execution. It ships gadget chains for the libraries that historically have been on every Java classpath: Commons Collections (3.x and 4.x), Commons BeanUtils, Spring, Groovy, Hibernate, JBoss InterceptorsState, Jdk7u21, JRMPClient/Listener, and roughly thirty more. You pick a chain that matches the target's classpath, give it a command, and out comes a serialized blob you feed to the sink.

What I like:

• It is the canonical reference. Every Java deserialization writeup since 2015 uses ysoserial payloads. The chain names (CommonsCollections1, CommonsBeanutils1) are the lingua franca.
• The CLI is trivial. java -jar ysoserial.jar CommonsCollections5 "id" and you have a payload.
• JRMP listener mode is invaluable when you have a deserialization sink but the target outbound-firewalls everything except your IP. Spin up JRMPListener on a port you control, feed a JRMPClient payload, and the target reaches back.
• Encoding helpers for Base64, hex, and URL-safe forms are baked in.

What I do not like:

• Maintenance has been light since around 2020. New chains exist (CommonsBeansutils2, modern Spring AOT, Log4j-adjacent) that live in forks rather than the upstream tree. Check frohoff/ysoserial first, then community forks (pimps/ysoserial-modified, JackOfMostTrades/ysoserial-plus).
• No JSON / YAML / XML coverage. Pure native Java ObjectInputStream only. For Jackson, SnakeYAML, or XStream sinks, you need marshalsec.
• Some chains require precise classpath versions. CommonsCollections5 works against Commons Collections 3.1; the same chain against 3.2.1 fails silently. The README hints at this; the chain code itself is the source of truth.
• No GUI. The Burp extension below wraps it, but for one-off payloads the CLI is the path.

When to use it. Always start here for Java. If the target deserializes application/x-java-serialized-object, the answer is almost certainly a ysoserial chain. If it does not, move on to marshalsec.

2. ysoserial.net

Repo: github.com/pwntester/ysoserial.net

The .NET equivalent. Better maintained than upstream ysoserial.

ysoserial.net covers the .NET serializers that practitioners actually find in the wild: BinaryFormatter, LosFormatter, SoapFormatter, ObjectStateFormatter (ASP.NET ViewState), NetDataContractSerializer, DataContractSerializer, Json.NET with TypeNameHandling, XmlSerializer, FastJson, and XamlReader. Each formatter has its own set of gadget chains tuned for that serializer's quirks.

What I like:

• Active maintenance. New chains land regularly; recent .NET 8 and ASP.NET Core sinks are covered.
• The --minify and --useprotectedlist flags matter for ViewState attacks where signing/encryption keys are leaked but the payload must stay under request-size limits.
• Excellent ViewState support. Pair with a leaked machineKey and you have unauthenticated RCE on a depressing number of public IIS deployments.
• Documentation is real. The README explains each formatter's threat model rather than dumping a chain list.

What I do not like:

• Windows-first build experience. It runs on Linux via Mono or .NET 8, but the path of least resistance is a Windows VM.
• Some chains require a specific TypeNameHandling setting on the target Json.NET parser, which you cannot always determine without trial and error.
• The CLI flag surface is larger than ysoserial's. The README is essential reading; do not wing it.

When to use it. Any time the target is .NET and deserializes attacker-controlled data. ASP.NET ViewState with leaked keys is the highest-value case, but BinaryFormatter sinks in WCF, message queues, and binary RPC endpoints are still common.

3. marshalsec

Repo: github.com/mbechler/marshalsec

The companion piece to ysoserial. Covers the libraries ysoserial does not.

Marshalsec was released alongside Moritz Bechler's "Java Unmarshaller Security" paper in 2017 and remains the reference implementation for gadget chains against Jackson (enableDefaultTyping), SnakeYAML, XStream, JYAML, BlazeDS AMF, JSON-IO, and several others. Where ysoserial is "you have a native ObjectInputStream sink", marshalsec is "you have a JSON or YAML or XML parser that allows polymorphic type instantiation".

What I like:

• Coverage of the JSON/YAML/XML parser landscape that ysoserial does not touch. Jackson enableDefaultTyping and SnakeYAML defaults have been the most common modern Java deserialization sinks for several years, and marshalsec is how you exploit them.
• Bundled LDAP/RMI server modes (MarshallerInvocationServer) for fetch-and-load gadget delivery via JNDI.
• The accompanying paper is one of the best primers on Java unmarshalling security ever written. Read it.

What I do not like:

• Stale. The repository has not seen meaningful updates in years. Newer parser library versions sometimes need chain tweaks that exist only in forks.
• Build process is finicky on modern JDKs; pin to JDK 8 or 11 for a clean build, or grab a pre-built JAR from a reputable mirror.
• Less polished CLI than ysoserial. Argument shapes vary per marshaller, so check the README per chain.

When to use it. When the target deserializes via Jackson, SnakeYAML, XStream, or any JSON/YAML/XML library and the parser is configured to allow polymorphic types. If the sink is ObjectInputStream, stay on ysoserial; if it is a readValue call on a JSON string, marshalsec is the tool.

4. PHPGGC

Repo: github.com/ambionics/phpggc

The PHP equivalent of ysoserial. Coverage across the PHP framework universe.

PHPGGC generates payloads for unserialize() sinks across a long list of frameworks and libraries: Laravel (every major version), Symfony, WordPress, Doctrine, Monolog, Guzzle, Slim, CodeIgniter, ThinkPHP, Magento, Drupal, Phalcon, Yii, Zend, and several dozen more. Each chain is named with the library and version (Laravel/RCE15, Symfony/RCE6), and the tool tells you exactly which versions a chain works against.

What I like:

• Coverage is genuinely good. Most PHP frameworks I run into in 2026 have at least one PHPGGC chain.
• Encoder flags (-b for Base64, -f for fast-destruct, -a for ASCII-safe via S string syntax) cover every PHP serialization quirk I have hit in practice.
• Phar wrapper mode (-p phar) generates the polyglot Phar file used in the file-upload + phar:// deserialization attack pattern. This is a real attack class against PHP applications that accept user uploads; PHPGGC makes it trivial.
• Active maintenance, regular new chains, and a clean issue tracker.

What I do not like:

• The chain list is large enough that picking the right one for a given Laravel version is a guess-and-check exercise. phpggc -l Laravel lists them; expect to try several.
• Some chains require specific library combinations on the classpath. Same problem as ysoserial; same workflow (read the chain source).
• Fast-destruct mode (-f) is essential against partial-deserialization sinks where the unserialize errors silently roll back the trigger. The flag exists; remembering to use it does not.

When to use it. Always for PHP. Any unserialize($_GET['x']) sink, any phar:// stream wrapper attack via file upload, any cookie that round-trips a serialized object.

5. Burp Suite Java Deserialization Scanner

Repo: github.com/federicodotta/Java-Deserialization-Scanner

The manual workflow companion. Lives inside Burp.

A Burp Suite extension by Federico Dotta that wires ysoserial directly into Burp's request flow. Active Scanner integration detects serialized data in requests automatically; the manual tester lets you pick a ysoserial chain and inject it into any request from Repeater or Intruder with the right encoding (Base64, GZIP, ASCII-hex) for the sink.

What I like:

• Inline workflow. You are already in Burp triaging requests; finding a serialized blob, right-clicking, and firing every ysoserial chain at it in turn is two minutes of work instead of twenty.
• Handles encoding wrappers (Base64-of-GZIP-of-serialized) which is the format most modern Java apps use when round-tripping serialized state through cookies or hidden fields.
• Passive detection of serialized data in responses. Useful for finding the sink in the first place.

What I do not like:

• Bundled ysoserial version lags upstream by a release or two. Point it at a current local JAR via the configuration tab.
• Active scanner is noisy. Each chain it tries can briefly DOS a slow sink; tune the chain list per target.
• The extension itself sees only the chains that ship with the bundled ysoserial. New chains in forks need manual integration.

When to use it. Whenever you are doing manual Java app testing in Burp and want ysoserial integrated into the flow rather than alt-tabbing to a terminal. Pair with ysoserial on the CLI for the cases the extension does not cover.

6. Python pickle (and the honest framing)

Stdlib reference: docs.python.org/3/library/pickle

There is no canonical Python tool. The payload is five lines you write yourself.

Pickle is famously insecure: pickle.loads() on attacker-controlled bytes is eval() with extra steps. Despite that, no widely-used PHPGGC-equivalent tool exists for Python. The reason is structural: the attack is so trivial that nobody has bothered to build one. A complete RCE payload looks like this:

import pickle, os

class RCE:
    def __reduce__(self):
        return (os.system, ("id",))

payload = pickle.dumps(RCE())

pickletools.dis(payload) lets you inspect the opcodes when debugging deserialization failures. pickletools.optimize(payload) shrinks the blob when sinks have size limits.

What I like (about the situation, not a specific tool):

• The simplicity. You do not need a chain because __reduce__ is the chain. Any callable plus its arguments is RCE.
• pickletools in the stdlib is enough for triage. No third-party dependency.
• Works against pickle, dill, cloudpickle, joblib, numpy.load(allow_pickle=True), PyTorch .pt checkpoints, scikit-learn .pkl model files. One technique, broad surface.

What I do not like:

• No tool means no leverage on edge cases. Restricted unpicklers (pickle.Unpickler subclass overriding find_class) need bypass research per implementation; there is no community-maintained chain set to draw on.
• The lack of a canonical tool means each engagement reinvents the wheel for non-trivial constraints (size limits, character restrictions, restricted globals).
• A handful of half-finished GitHub projects pose as "the Python ysoserial". None of them are maintained or worth depending on. Write the five lines yourself.

When to use it. Any Python application that deserializes attacker-controlled pickle bytes. Especially common in ML model-serving infrastructure, where .pkl and .pt files are exchanged as if they were data when they are in fact arbitrary code.

7. GadgetInspector

Repo: github.com/JackOfMostTrades/gadgetinspector

Research-grade. Not engagement-grade. Use when no existing chain fits the target.

GadgetInspector is a static-analysis tool that reads a Java classpath and tries to discover gadget chains automatically by tracing call graphs from readObject and friends through to dangerous sinks (Runtime.exec, ProcessBuilder, Method.invoke). Output is a list of candidate chains; you then validate each one by hand.

What I like:

• The right tool when you have a fat application classpath with custom libraries that ysoserial does not cover. Drop in the JARs, run the analysis, get a candidate list.
• The published academic context (Ian Haken's original Black Hat USA 2018 talk) is excellent reading on how gadget-chain discovery works in principle.
• False positives are expected, but the true-positive rate is high enough on real applications to be worth the time.

What I do not like:

• Stale. Last meaningful update predates several years of new gadget-chain research patterns.
• Slow on large classpaths. An hour of CPU on a real enterprise WAR is normal.
• High noise. Most "discovered" chains will not work in practice; expect to validate every candidate manually.
• Steep learning curve. Knowing what the output means requires understanding gadget-chain construction at the bytecode level.

When to use it. Last resort. When ysoserial has no chain that fits the target's classpath, when marshalsec has no chain that fits the parser, and when you have time to do real research. Not for time-boxed engagement work.

What I do not recommend

Random "all-in-one deserialization scanners" on GitHub

A handful of repositories advertise themselves as "the all-in-one deserialization toolkit" and bundle outdated forks of ysoserial, PHPGGC, and marshalsec behind a wrapper script. In practice the bundled binaries are months out of date, the wrapper script adds nothing useful, and you lose the per-tool flag flexibility. Run the upstream tools directly. If you want orchestration, write a 30-line shell script.

Closed-source "commercial deserialization fuzzers"

I have evaluated three of these over the past two years. In every case the engine underneath was ysoserial plus a request fuzzer, and the markup over running ysoserial yourself was the entire price tag. The exception would be a vendor that genuinely owns novel gadget-chain research, which I have not yet seen in a commercial product.

Tools I dropped from this year's list

• JavaSerialKiller (Burp extension). Functional in its day; the Java Deserialization Scanner extension above does everything JavaSerialKiller did, with active maintenance and better passive detection.
• Serializekiller. Standalone Java deserialization scanner from 2016. Effectively unmaintained; ysoserial plus a request-fuzzer wrapper is more reliable.
• SerializationDumper. Useful for inspecting serialized blobs at the byte level; kept on my disk but does not generate payloads, so it is a debugging aid rather than an attack tool. Not on the main list, but worth knowing about.

Which tool should I use? (Decision tree)

A short flow for the common cases:

• Is the target Java, deserializing via ObjectInputStream?
  • Yes. Start with ysoserial. Match a chain to the target classpath. If you cannot find a fit, try marshalsec for non-ObjectInputStream sinks (JSON/YAML/XML).
• Is the target Java, deserializing via Jackson, SnakeYAML, XStream, or another JSON/YAML/XML parser?
  • Yes. Marshalsec. Confirm the parser allows polymorphic types.
• Is the target .NET (ASP.NET, WCF, message queues)?
  • Yes. ysoserial.net. For ViewState specifically, pair with a leaked machineKey and use ObjectStateFormatter chains.
• Is the target PHP?
  • Yes. PHPGGC. Run phpggc -l <Framework> to find applicable chains; remember -f for partial-deserialization sinks and -p phar for the file-upload attack pattern.
• Is the target Python?
  • Yes. Write the __reduce__ payload by hand. Five lines. Do not wait for a tool that does not exist.
• Are you doing manual workflow inside Burp Suite?
  • Yes. Install the Java Deserialization Scanner extension and point it at a current ysoserial JAR.
• No existing chain fits the target classpath, and you have time for research?
  • GadgetInspector. Expect a long day of manual validation.

A note on the year stamp

I will refresh this list every twelve months. The slug stays stable (best-deserialization-tools-2026 is a redirect target you can rely on; future years update the H1 and title). Tools added, dropped, and re-ranked here will appear in the next refresh with a short changelog at the top.

Where to go next

• Insecure deserialization: gadget chains and runtime sinks for the underlying mechanics
• Web application security vulnerabilities taxonomy for the broader map
• Remote code execution: classes, vectors, and defence for where deserialization ranks among RCE paths