TL;DR:
Insecure deserialisation remains a widespread risk in modern web frameworks, allowing attackers to execute code or steal data. It’s hard to eliminate due to complex architectures, diverse frameworks, and legacy systems. Effective defense relies on verifying sources, strict schema enforcement, isolating high-risk operations, and continuous monitoring.
Table of Contents
Introduction
Insecure deserialisation is one of those vulnerability classes that never seems to go away. It appears in different languages, frameworks, and has done so for decades, often with the same tragic outcome: Remote code execution, data theft, and full system compromise.
Despite years of high-profile, high-scoring CVEs, insecure deserialisation still plagues us today. In my previous article, I examined React2Shell (CVE-2025-55182), which is only the latest example. The underlying issue is not a single framework or implementation mistake, but a deeper architectural challenge.
This article looks at why insecure deserialisation genuinely hard to solve at scale, and what practical defences actually work in modern web architectures and real-world enterprises.
What Is Deserialisation
Serialisation is the process of converting complex objects, such as user profiles held in memory, into a flat format like JSON, XML, or binary so they can be sent over a network.
Deserialisation is the reverse process. It reconstructs those objects back into live structures in memory.
Sounds harmless right? Yes, deserialisation has been around for as long as the web, so it is typically safe. But it can be dangerous when untrusted inputs can cross the porous boundary between client and server to influence how objects are rebuilt and used in areas that should have been well beyond reach.
Why We Need Deserialisation
Deserialisation has been a cornerstone of distributed computing since before web browsers even existed. However, modern frameworks often use complex deserialisation, which make deserialisation exploits more insidious.
The web is built on HTTP, which is a stateless protocol. Each request is independent and the server does not automatically remember previous interactions.
But we want our applications to remember us. We want our sessions, actions, preferences and where we last left off to be remembered even after we’ve logged off the compute, and often even when we delete our browsing history and cache.
Because modern web frameworks want to make this memorising between you, the Client, and them, the Server, easy on the developer, they use forms of deserialisation that can rebuild complex objects in the process.
This is a fundamental, hidden process in many, arguably majority, of the websites you interact with every day to allow you to have a seamless user experience.
Where the Danger Lies
Not all deserialisation is equally risky.
Low risk deserialisation includes parsing JSON into plain data structures, when done correctly.
High risk deserialisation occurs when the runtime:
- Hydrates types that carry behaviour, such as constructors or magic methods
- Follows metadata to rebuild complex object graphs
- Automatically executes code during reconstruction
On this path, a crafted payload can cause the server to construct something that runs unintended code. This is the essence of insecure deserialisation.
A Pattern Across Ecosystems
React Server Components affected by the perfect 10 scoring React2Shell (CVE-2025-55182) is just one example.
High scoring deserialisation vulnerabilities have occurred in pretty much every popular web framework:
- .NET through BinaryFormatter (CVE-2025-53770, Score 9.8)
- Python via unsafe YAML loading (CVE-2020-1747, Score 9.8)
- PHP object injection flaws (CVE-2025-66571, Score 9.3)
- Java framework Apache Struts (CVE-2017-9805, Score 8.1)
The details vary, but the root cause is consistent. Systems trust structured data too much and give it too much influence over execution.
Why Deserialisation Is Hard to Secure
The obvious solution is strict validation and whitelisting. In practice, this is far more difficult than it sounds.
Frameworks must support myriad use cases across thousands, even millions when you reach the scale of a leading framework like React, of applications. Security rules that work in one context may break another. Backward compatibility further constrains how strict these controls can be.
Enterprise architectures amplify the challenge.
Modern systems are often built from dozens or hundreds of microservices. Each service may differ in how it is built and secured, including:
- Frameworks and runtimes in use
- Serialisation and deserialization formats
- Third-party libraries and open source dependencies
- Legacy components and vendor integrations
As a result, security maturity can vary widely, even within the same enterprise.
So it’s usually not for lack of trying, consistent, end-to-end deserialisation safety in a changing landscape where many factors are not within your control is genuinely hard.
5 Rules for Practice Defence
There is no single fix for insecure deserialisation. Effective defence should be simple and practical. It relies on layered controls and disciplined engineering.
1. Verify the source of deserialised data
Only accept payloads from trusted services and identities. Reject unverified sources as early as possible. Where feasible, verify provenance using signatures or mutual TLS.
2. Verify before you deserialise
Enforce strict schemas and fail closed. Avoid permissive parsing. Prefer parsers that return plain data rather than hydrating objects with behaviour. Follow framework guidance on safe loading practices.
3. Minimise the blast radius
Run deserialisation in isolated, least-privileged environments. Restrict filesystem access, environment variables, and outbound network connectivity. Scope credentials narrowly and rotate them regularly.
4. Create a safe zone for high-risk operations
Place validation or gateway layers in front of sensitive server functions. Separate critical operations into hardened services. Deserialise untrusted data away from core systems whenever possible.
5. Keep learning and monitoring
Security is as much about people as technology. Patch frameworks and dependencies promptly. Monitor advisories and CVEs relevant to your stack. Invest in ongoing learning and threat awareness.
Conclusion
I am going to make a bold prediction that React2Shell isn’t the last we’re going to see of insecure deserialisation. These vulnerabilities are a byproduct of us wanting our systems to be user friendly, feature rich, and interconnected. To give users the convenience they demand, we’ve built frameworks that prioritise moving data seamlessly, and sometimes that convenience bites back.
This doesn’t mean we need to build impenetrable walls that are immune to these vulnerabilities. Maybe we just need to think in terms of our home security. Extend a warm welcome to your trusted friends but treat incoming objects like strangers. You verify who they are, limit what they can touch, and have a plan for when things get messy. Deserialisation isn’t going anywhere. It’s up to us to make sure it’s not a door we leave unlocked.
Want to strengthen your application security?
Our team of experts can help you identify, assess, and defend against deserialisation vulnerabilities before they become a threat. Contact us today to discuss how we can secure your systems and protect your data.
