Home / Knowledge hub / Insecure deserialisation
Knowledge hub
Insecure deserialisation
Turning data from outside back into live objects without checking it.
What it means
Serialisation flattens an object into bytes or text so a program can store it or send it somewhere. Deserialisation reads that back and rebuilds a live object from it.
It turns dangerous when the data came from outside and the code trusts it on the way in. Rebuilding an object can run code, because some languages call setup methods as the object comes to life. Whoever controls the stored form controls what gets built. MITRE tracks this as CWE-502, deserialisation of untrusted data.
Why it matters
The usual outcome is remote code execution. PortSwigger calls it an entry point to a massively increased attack surface, often ending in code execution and sometimes in privilege escalation or arbitrary file access. At that point the attacker has stopped reading your data and started running commands with your application's rights.
It is rarer than injection or broken access control, and harder to exploit. It also arrives quietly, since nobody chooses to deserialise untrusted input. It comes as a convenience: a session kept in a cookie, a queue passing objects between services, a cache on disk.
How it shows up
Find the places your application accepts a serialised blob it did not create in this process. Session cookies holding more than an id. Message queues. Cached objects. Import features. Any API taking an encoded object rather than named fields.
OWASP's advice is to avoid native formats in favour of JSON or XML. Restrict which classes your code may rebuild, and deserialise signed data where you can. Keep those libraries current too, because many of these are published flaws in popular packages rather than mistakes in your own code.
Questions people ask
Insecure deserialisation, answered
Is JSON safe to deserialise?
Plain JSON is fine, because it carries values rather than types and methods. Parsing it into known fields gives an attacker nothing to build with.
The danger returns when a library gets configured to resolve type information from the document. Several popular parsers offer that switch, and turning it on reintroduces the whole problem.
How common is this really?
Much rarer than access control or injection findings. Most applications never deserialise anything an attacker controls.
When it does appear, it tends to be severe, which is why it keeps its own place on risk lists despite the low frequency.
Is it still in the OWASP Top 10?
Not as its own entry. It stood alone in the 2017 list and now sits inside the 2021 category covering software and data integrity failures.
The renaming changed the label rather than the risk. The weakness still has its own CWE and its own well-known exploit chains.
Can I just sign the serialised data?
Signing helps a lot, because you can tell your own output from somebody else's before you rebuild anything. It is the right move when you cannot change the format.
It is not a cure. A leaked signing key, or a bug that verifies after parsing rather than before, puts you back where you started.
How do I know if my application does this?
Search for the language's native calls first, such as unserialize, pickle or Java object input streams. Then look at what crosses a boundary: cookies, queues, caches and file imports.
Anything that looks like a base64 blob going in and coming back out deserves a closer read.
Sources
Where this comes from
Related
Terms that sit next to this one
Remote code execution
Getting a server to run commands of an attacker's choosing.
Untrusted input
Anything that arrived from outside your own code, and is therefore suspect.
Known-vulnerable component
A library or runtime with a published flaw that you are still shipping.
XXE
An XML parser tricked into fetching files or internal addresses.
Injection
Input that ends up running as a command instead of being read as text.
What does your app rebuild?
Anything your application turns back into a live object deserves a hard look. We test it beside injection and configuration, then prove each finding with a working request. Get in touch about a pilot.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.