Cybersecurity glossary

What is a Deserialization Attack?

Learn what deserialization attacks are, how insecure unmarshalling of untrusted data leads to remote code execution, which formats are commonly abused, and how to prevent insecure deserialization.

Application securityUpdated July 20, 2026
Also known asInsecure deserializationObject injectionUntrusted unmarshalling

Definition

A deserialization attack exploits insecure unmarshalling of untrusted data so that reconstructing objects, structures, or executable graphs from serialized input produces unintended behavior—often remote code execution, authentication bypass, or tampering.

Why deserialization attacks matter

Serialization is a convenience feature: take an in-memory object, turn it into bytes or text, send it somewhere, and rebuild it later. That rebuild step is a mini interpreter. If attackers control the blob and the interpreter can construct powerful types, the application may execute attacker intent while “just loading state.”

Deserialization attacks have produced some of the highest-impact application CVEs because the failure mode is often remote code execution, not merely a display glitch. Message queues and caches make the problem worse: one poisoned message can hit many workers.

How insecure deserialization works

1

Find a serialized trust point

Locate cookies, tokens, queue messages, or API fields that are unmarshalled into objects.

2

Identify the serializer

Determine format and library—Java serialization, pickle, PHP unserialize, .NET BinaryFormatter, and similar.

3

Craft a malicious payload

Build a structure that triggers unsafe types or gadget chains during reconstruction.

4

Deliver the blob

Submit through HTTP, embed in a cache key, or publish to a consumed queue.

5

Trigger unmarshalling

The application deserializes during login, job processing, or request handling.

6

Achieve impact

Execute commands, alter privileges, write files, or pivot deeper into the environment.

High-risk patterns

Native object serializers

Formats designed to recreate rich object graphs are dangerous with untrusted input.

Polymorphic type fields

Attacker-controlled class names or type discriminators enable unexpected object instantiation.

Signed but still dangerous

A signature proves integrity, not safety of the deserializer’s capabilities.

Second-order queue poison

A serialized job accepted today may execute on a privileged worker tomorrow.

Safer alternatives

ApproachGuidance
Simple data formatsPrefer JSON/protobuf into plain DTOs without executable type reconstruction.
AllowlistsIf object deserialization is unavoidable, restrict permitted classes tightly.
Integrity + authAuthenticate producers and verify MAC/signatures before parse—still avoid dangerous parsers.
IsolationDeserialize in low-privilege sandboxes with minimal OS rights and egress controls.
PatchingKeep frameworks updated; gadget chains are frequently library-dependent.

Prevention checklist

  • Never pass untrusted data to native serializers such as Python pickle or historical BinaryFormatter patterns.
  • Replace object serialization in cookies and hidden fields with opaque server-side session references.
  • Disable polymorphic typing features unless absolutely required and strictly allowlisted.
  • Monitor for deserialization exceptions, unexpected class loads, and suspicious child processes.
  • Threat-model every message queue and cache entry that reconstructs objects.
  • Apply least privilege to services that deserialize untrusted or semi-trusted payloads.
  • Review third-party libraries for auto-deserialize convenience features on request bodies.
  • Include insecure deserialization tests in SAST/DAST and manual code review checklists.

The practical takeaway

A deserialization attack turns a data-loading feature into remote attacker control by abusing how objects are reconstructed. The safest design is not “validate harder”—it is to stop deserializing untrusted data with powerful native object serializers.

Use boring data formats, allowlist aggressively when you cannot, and assume every queue message and cookie blob is hostile until proven otherwise.

Related security terms

Frequently asked questions

What is a deserialization attack in simple terms?

Applications often convert objects into a portable format and later rebuild them. If attackers can supply that data and the rebuild process runs dangerous code, they can take over the application.

Is JSON parsing the same as insecure deserialization?

Ordinary JSON into simple data structures is usually safer than native object deserialization with executable types. Risk rises when parsers reconstruct arbitrary classes, run setters with side effects, or evaluate code.

Which languages are commonly affected?

Java, .NET, PHP, Python (pickle), Ruby, and others have historically faced insecure deserialization issues when untrusted input reaches powerful native serializers.

What is a gadget chain?

A gadget chain is a sequence of existing classes or functions that, when deserialized together, produce harmful behavior such as command execution without the attacker uploading new code.

How do you prevent deserialization attacks?

Do not deserialize untrusted data with powerful native serializers. Prefer simple data formats, allowlist types, verify integrity, isolate parsers, and keep libraries patched.

Can signing serialized blobs make them safe?

Integrity protection helps against tampering in transit, but if the application still deserializes attacker-controlled data after a key compromise—or accepts unsigned input elsewhere—risk remains. Avoid dangerous deserializers entirely when possible.

Where does untrusted serialized data appear?

Cookies, hidden fields, caches, message queues, auth tokens, job payloads, mobile API bodies, and file uploads are common carriers.

References

Explore authoritative guidance and frameworks related to deserialization attack.

Explore every security definition

Return to the glossary to search by term, alias, starting letter, or security category.

Browse glossary