What is Insecure Deserialization?

Serialization converts data or an object into a representation that can be stored or transmitted. Deserialization later reconstructs values or objects. Insecure deserialization occurs when an application processes untrusted serialized data while accepting types, properties or side effects that an attacker can control.

What happens during serialization?

Applications serialize sessions, cache entries, queue messages, cookies, API payloads and stored objects. A simple format contains primitive values such as text and numbers. Native object formats can also carry class names, type information, references and object state. During reconstruction, the runtime creates classes and may invoke constructors, setters, destructors or special “magic” methods.

Why is deserialization dangerous?

The data stream appears passive but can determine which objects are created and which methods run indirectly. Public cookies or hidden fields, messages from less-trusted queues, modified cache entries and imported files are risky. Base64 or encryption without verified integrity does not make data trustworthy. A signature helps only when checked before deserialization, keys are protected and no other path admits unsigned objects.

What are gadget and POP chains?

A gadget is existing code in the application or a library with a useful side effect during object processing, such as a file operation, process launch or dynamic call. Attackers chain gadgets by serializing suitable objects and properties. PHP discussions often use POP chain, while Java and .NET commonly use gadget chain. No new code needs to be uploaded; existing classes are abused. Adding a library can therefore make a previously non-exploitable deserialization dangerous.

What impact exists besides code execution?

Is JSON automatically safe?

Plain JSON describes values and has no executable classes, preventing many classic native gadget chains. Unsafe polymorphic type binding can nevertheless use a JSON type field to instantiate arbitrary classes. Mass assignment, unexpected properties, prototype manipulation, and missing schema or authorization checks remain possible. What matters is how parser and downstream code interpret data, not the filename extension.

How is the risk prevented?

1. Avoid native objects: Use simple data transfer objects with an explicit schema across trust boundaries.
2. Restrict types: Disable polymorphic or dynamic resolution and tightly allowlist required types.
3. Validate fields: Check type, range, size, depth and unknown properties before business logic.
4. Protect integrity: Prefer server-side state or authenticate data cryptographically, verifying before any side-effecting parse.
5. Reduce dependencies: Keep libraries current and remove unnecessary classes or dangerous gadgets.
6. Isolate: Process unavoidable input with low privileges, limits and no unnecessary network access.

Code example: replace native objects with a validated data schema

Vulnerable: A cookie controls which PHP objects are created.

$state = unserialize(
    base64_decode($_COOKIE['checkout_state'])
);
processCheckout($state);

Safer approach: Only expected primitive values are accepted.

$data = json_decode(
    base64_decode($_COOKIE['checkout_state']),
    true,
    16,
    JSON_THROW_ON_ERROR
);

$validated = validator($data, [
    'cart_id' => ['required', 'uuid'],
    'currency' => ['required', Rule::in(['EUR', 'USD'])],
])->validate();

// Reload price, ownership and permissions server-side
$cart = $request->user()->carts()->findOrFail($validated['cart_id']);

allowed_classes => false can further constrain legacy PHP, but does not replace an explicit data schema. Security-relevant state should preferably not come from the client at all.

How is the vulnerability tested?

Testers recognize formats in cookies, binary data, Base64, type fields, errors and framework markers. Harmless property changes or type errors first prove server-side deserialization. Gadget discovery and code execution are controlled and require approval because parsing itself can cause side effects. Size limits, signature verification, alternative input channels and dependency versions are assessed as well.