Deserialization 101: how a decade-old vulnerability still ships in 2026

There's a category of vulnerability that has been represented in the OWASP Top 10 for almost a decade and drove an emergency patching wave across enterprise Java between 2015 and 2018. And yet it once again landed a CVSS 10.0 as recently as December 2025, this time resulting in unauthenticated RCE in React Server Components. It’s called insecure deserialization, and the reason this vulnerability keeps shipping in 2026 is because the vulnerability doesn’t look like one. It looks like ordinary data handling.

How insecure deserialization works

Most websites remember who you are between visits by sending a small piece of data (a session cookie) to your browser, which your browser sends back on every request. The server reads the cookie and recognizes you. In many cases, the cookie is just an ID: the server looks up your session in its own storage. But some servers embed the session data directly inside the cookie. Because cookies essentially store data as text, structured information such as user IDs, settings, or session state must first be converted into a flat representation that can be stored and transmitted. That packing-up step is called serialization; reading it back is called deserialization.

However, this embedded format can do more than just describe a user. It is allowed to contain instructions the server carries out as it reads. This is meant to help the server rebuild complex data, but it has an obvious flaw. The cookie sits in the user's browser between visits, so an attacker can replace theirs with a forged cookie full of malicious instructions. The moment the server reads it, those instructions are carried out.

In Python, the function that reads this kind of cookie is called pickle.loads():

user = pickle.loads(request.cookies['session'])

The application's own login checks never get a chance to stop the attack, because the damage happens during the read itself.

Java, PHP, and .NET have their own equivalents of pickle. All of them work the same way: hand them attacker-controlled data and they may execute whatever is hidden inside.

The Java middleware era (2015 to 2018)

In January 2015, researchers Chris Frohoff and Gabriel Lawrence demonstrated that any Java application with vulnerable libraries on its classpath could be made to run attacker code on deserialization, with Apache Commons Collections supplying the gadget chains that made the technique work.

Later that year, Stephen Breen of Foxglove Security used the same approach to publish working exploits against Jenkins, JBoss, WebLogic, and WebSphere.

The application code itself didn't need to be at fault. Any vulnerable library in the dependency tree could turn a single payload into remote code execution, and emergency patching across enterprise Java ran for three straight years.

Joomla (2015)

Later that year, the same pattern surfaced in PHP. Joomla cached visitor data using PHP's native serialization, including the visitor's User-Agent header. Anyone visiting the site sent a User-Agent that got written to the session cache and deserialized on the next request.

A carefully crafted User-Agent could trigger arbitrary command execution when the session was rebuilt. A single unauthenticated HTTP request was enough to take over a Joomla server, and mass automated exploitation followed within hours.

Telerik UI (2017 onwards)

Between 2017 and 2019, Telerik shipped a chain of vulnerabilities in their popular ASP.NET UI suite: a hardcoded default encryption key in the RadAsyncUpload file upload component, and an unsafe JavaScriptSerializer call that turned key knowledge into remote code execution.

Anyone with the documented default key could send a forged upload configuration and trigger code execution on the server. The vulnerabilities were patched, but many deployments never rotated their keys, and CISA still flags Telerik deserialization in active exploitation reports almost a decade later.

What these incidents have in common

The pattern across all three is identical: each application accepted serialized data from an untrusted source, the deserializer rebuilt it without validating what was inside, and the side effects fired during reconstruction handed the attacker remote code execution. At the network edge, that traffic looks like ordinary HTTP requests with slightly unusual cookie or header values, which is why catching it reliably has to happen at both the application perimeter and inside the application logic.

How to prevent insecure deserialization

Closing the vulnerability class means refusing to accept serialized objects from untrusted sources. Most applications can't switch off native deserialization overnight, so the work has to happen in layers: reduce the attack surface where you can, harden whatever has to stay, and constrain what a deserializer is allowed to do when it runs. The practical checklist looks like this:

• Use safer data formats — JSON, Protobuf, and similar formats describe data only and can’t trigger code or rebuild arbitrary types. Switching removes most of the risk by design.
• Sign anything crossing a trust boundary — If a session token needs native serialization, sign it with a key the client never sees so forged payloads get rejected before they reach the deserializer.
• Use type allowlists — Java’s serialization filters and .NET’s SerializationBinder restrict which types a deserializer can reconstruct. Turning these on stops most known attacks even when a vulnerable library sits in the dependencies.

None of these controls is enough on its own. Safer formats fail if a legacy library still calls ObjectInputStream downstream, signing fails if the key leaks, and type allowlists fail against gadget chains built from allowlisted classes. Stack them so a single failure doesn't hand the attacker remote code execution, with a perimeter control out front buying time to fix the underlying calls.

Catching what code can't: WAF detection for deserialization attacks

A WAF sits between the internet and your application, inspecting every HTTP request and blocking known exploitation patterns before they reach the code. For deserialization specifically, that means catching Java gadget chains and base64-wrapped objects hidden in cookies and headers, regardless of which library the dangerous call is buried in.

Qrator.WAF does this with a mix of signature detection and semantic anomaly detection, which keeps catching variants even after the patches go in. The vulnerability class isn't going away. New variants will keep landing in frameworks that weren't on developers' radar last year. The perimeter helps stop them while the rest of the work catches up.