Insecure Deserialization: How Gadget Chains Turn Data Into Application Risk

Serialization is routine plumbing in web applications, but deserializing data from an untrusted source can turn that plumbing into an execution path. The risk comes from what an application does while rebuilding an object, especially when the input can select unexpected data types or trigger actions embedded in the language’s object-handling behavior.

For engineering teams, the practical question is not simply whether an application uses serialized data. It’s where that data comes from, which deserialization mechanisms process it, and what those mechanisms can do during reconstruction. A vulnerable path can expose information, alter or delete files, or, in some cases, enable remote code execution.

Serialization carries more than a data shape

Applications often need to store or transmit complex structures between a client and server, or between internal components. Serialization converts those structures into a form suitable for storage in a database or file, or for transmission over a network. Deserialization reverses the process, rebuilding the original structure so the application can use it.

JSON and XML are examples of formats designed to work across programming languages. Other formats are tied to a particular language, including PHP and Java serialization. Language-specific formats can support richer object behavior than simpler, language-independent formats. That extra capability can also mean extra assumptions about what data is safe to deserialize.

Names such as marshalling, pickling, and flattening are also used for serialization. Whatever the label, the underlying workflow has two sides: convert a structure into a transferable representation, then reconstruct it later. The security boundary becomes important when that representation comes from a user or another source the application doesn’t control.

Why object reconstruction can become an execution path

Insecure deserialization describes the unsafe handling of untrusted input during deserialization, commonly involving language-native formats. Two conditions make these flaws exploitable: reconstruction may trigger additional actions, and the application may not restrict which types of data it will rebuild.

In PHP, some of these behaviors are associated with magic methods. Similar object lifecycle behavior can occur in other environments. During reconstruction or cleanup, application code may open a file, make a network connection, or close a socket. These actions may be ordinary features when invoked in the intended context. The danger is that crafted serialized input can cause them to run in an unintended sequence.

Security researchers call a useful action in this sequence a gadget. An attacker may combine several gadgets into a gadget chain, arranging for the application’s own code to perform a harmful operation. The payload doesn’t simply supply arbitrary executable code: it has to use object types and behaviors that the application can recognize and reach.

That constraint makes the available application code central to the risk. A crafted input containing unfamiliar data may fail or cause a recoverable error. A payload that matches usable objects and methods can have a very different result. Libraries reused across applications can make known gadget chains portable. Collections such as phpggc for PHP and Ysoserial for Java document chains that can help researchers and attackers identify relevant behaviors.

The source’s microwave analogy captures the distinction: an unexpected object might merely disrupt normal processing, while an object that triggers a known harmful behavior can cause serious damage. In application terms, a successful chain could expose information or modify or remove files. In more severe cases, it may provide a route to remote code execution.

Reduce the exposed deserialization surface

The safest approach is to avoid deserializing user-controlled data. Some applications need to accept serialized input to function, so teams can reduce risk by documenting the paths that remain and limiting what those paths accept.

• Inventory and document every mechanism that serializes or deserializes data. This gives teams a clearer view of data sources, formats, and code paths to review.

• Reduce deserialization of user-controlled input wherever the application can work without it. Fewer reachable paths mean fewer places where crafted data can trigger object behavior.

• Prefer simpler formats, such as JSON, where they meet the application’s needs. This can reduce the complexity of the data the application reconstructs.

• Use an allow-list of expected data types. Rejecting unexpected types limits the chance that input can invoke behaviors the application did not intend to expose.

• Apply strict signature verification where appropriate so the application can check whether serialized data has been altered or comes from a trusted source.

Error logs can also help teams identify suspicious behavior and uncover flaws. Fastly says that analysis of error logs led to its discovery of CVE-2023-30534, an insecure deserialization vulnerability in Cacti.

These controls work best as layers. Input restrictions and safer formats reduce the chance of an exploitable path; a web application firewall can add another layer when an application still needs to process serialized input. The key implementation detail is distinguishing harmful payloads from the benign data the application depends on.

Where a WAF fits

Fastly describes its Fastly Next-Gen WAF as detecting malicious serialized inputs while allowing benign serialized data. The company says it can detect gadget chains involving PHP, Java, FastJSON, and other formats. That approach is intended to protect applications without blocking normal serialized traffic or affecting performance.

A WAF can help identify and block suspicious input, but it doesn’t replace knowing which application paths deserialize data or limiting what those paths accept. Teams evaluating this protection should consider how detection fits with their formats, traffic patterns, and application behavior. The first useful step remains an inventory: find every deserialization boundary, then decide which types and sources each one actually needs to support.