HackproofHacks
Vulnerability walkthrough · Object handling

How to Exploit Insecure Deserialization: A Step-by-Step Lab Walkthrough

13 min read · Lab: PortSwigger Web Security Academy

In one line

Apps sometimes turn objects into a string to store or send, then rebuild them later. Insecure deserialization is when you edit that string, and the app trustingly rebuilds the tampered object.

What this is, for a beginner

Serialization turns an in-memory object into a string of bytes so it can be stored in a cookie or sent over the network, and deserialization rebuilds the object from that string. Insecure deserialization is when an application rebuilds objects from data the user can modify, and trusts the result, so an attacker who edits the serialized data can change the object the application ends up using.

The impact ranges from privilege escalation, by flipping a field like admin from false to true, up to remote code execution in languages and libraries where crafted objects can trigger dangerous behaviour during reconstruction. The beginner-friendly case is modifying a readable serialized object to change your own attributes, which the PortSwigger labs demonstrate cleanly.

The legal lab we use: PortSwigger Web Security Academy

PortSwigger provides free, legal, hosted deserialization labs with isolated targets you are explicitly authorized to attack.

PortSwigger Web Security Academy project page →

Full walkthrough: exploiting it step by step

Step 1 — Open the deserialization lab

Start the PortSwigger lab Modifying serialized objects. It stores a serialized session object in a cookie after you log in with the provided credentials.

Expected result: After logging in, a cookie holds a serialized object describing your session.

Step 2 — Capture and decode the cookie

Proxy through Burp, log in, and find the session cookie. It is often base64-encoded serialized data; decode it to reveal the readable object and its fields.

Burp — session cookie
Cookie: session=Tzo0OiJVc2VyIjoyOntzOjg6InVzZXJuYW1lIjt... (base64)

Expected result: Decoding the cookie reveals a serialized object with fields such as username and admin.

Step 3 — Tamper with a field

Change the admin field from a false value to a true value in the decoded object, keeping the serialized format valid, then re-encode it.

edited serialized object (admin set true)
O:4:"User":2:{s:8:"username";s:6:"wiener";s:5:"admin";b:1;}

Expected result: A valid serialized object identical to the original except that admin is now true.

Step 4 — Replace the cookie and escalate

Put the re-encoded object back into the session cookie in Repeater and request an admin-only page. The app deserialises your tampered object and treats you as an administrator.

Burp Repeater — tampered cookie
Cookie: session=<re-encoded tampered object>

Expected result: The admin panel loads for a non-admin user, completing the lab and proving privilege escalation through deserialization.

Step 5 — Understand the code-execution ceiling

In some stacks, crafted serialized objects trigger dangerous methods during reconstruction, leading to remote code execution through gadget chains. PortSwigger has advanced labs for this; the field-tampering case here is the foundation to build on.

Expected result: You understand why insecure deserialization ranges from privilege escalation up to remote code execution depending on the technology.

Free resource

Get the free 35-week ethical hacking roadmap

The exact order I'd learn this in, every vulnerability and tool, week by week, with the labs to practise each one. Enter your email and I'll send it over, plus one practical lesson each week.

How to detect and fix this

How to detect it

  • Look for serialized data in cookies, hidden fields, and parameters (base64 blobs, language-specific formats) and test whether editing a field changes application behaviour.
  • Identify the technology from the serialization format, since exploitation and available gadget chains are language-specific.
  • In source, find where untrusted input is deserialised into objects; that is the vulnerable sink.

How to fix it

  • Do not deserialise untrusted data into objects. Where you must exchange structured data, use a simple data format such as JSON parsed into plain data, not native object serialization.
  • If native serialization is unavoidable, add integrity protection (a signature) so tampered objects are rejected, and constrain which classes may be deserialised.
  • Keep libraries updated, since many deserialization exploits rely on known gadget chains in outdated dependencies.
  • Treat any serialized object exposed to the client as attacker-controlled.

Common beginner mistakes

  • Breaking the serialized format while editing, so deserialization fails; keep lengths and types consistent with the format.
  • Assuming only remote code execution counts; simple field tampering for privilege escalation is common and impactful.
  • Ignoring the technology stack, when the format dictates the whole approach.
  • Testing against systems you do not own rather than the isolated PortSwigger labs.

FAQ

How severe is insecure deserialization?

It varies by stack. At minimum it often allows privilege escalation by tampering with object fields, and in some technologies it enables remote code execution through gadget chains. Because the ceiling is so high, it is treated as a serious risk wherever untrusted data is deserialised.

How do I know an app is deserialising user data?

Look for serialized blobs in cookies, hidden fields, or parameters, often base64-encoded and in a language-specific format. If editing a field inside that blob changes behaviour, the app is deserialising and trusting your input.

What is the real fix?

Stop deserialising untrusted data into native objects. Prefer plain data formats like JSON, add integrity checks if native serialization is unavoidable, and keep dependencies current to avoid known gadget chains.

Where to go from here

You just exploited one vulnerability in a lab. Here's the structured path.

Scattered tutorials teach you tricks; they don't make you a pentester. My mentorship is 35 weeks of exactly this, every vulnerability and tool in a deliberate order, on real labs, with one-on-one feedback on your work so your mistakes get caught early instead of becoming habits.

Keep practising