Deserialization Bug Bounty — Find, Exploit, Report Java, PHP and Python Unsafe Deserialization | Bug Bounty Course Day 30 of 60

Let me put Day 30 into perspective. Over the first 29 days, we’ve explored different ways to identify weaknesses in web applications, from SQL injection and SSRF to web cache poisoning. Each lesson has helped you develop a better eye for things that don’t look right. Today, I want to build on that experience with a vulnerability that’s a little harder to spot.

Here’s the challenge with deserialization: the clues aren’t always obvious. You might see a Base64-encoded value in a cookie, an unusual binary parameter, or a block of data that looks meaningless at first glance. The real question is what the application does with that data after it receives it. Under the right conditions, unsafe deserialization can lead to serious consequences, including remote code execution.

That’s why I want you to approach today’s lesson with curiosity rather than simply hunting for a ready-made payload. We’ll learn to recognise the clues, investigate application behaviour in a controlled lab, and determine whether the evidence supports a genuine vulnerability. We’re at the halfway point of our 60-day journey, and my goal is to help you think less like someone running tools and more like a security researcher who understands what they’re looking for. Let’s build that instinct together.

What Serialization Is and Why It Matters

Let’s start with the basics, because once you understand how serialization works, the security risk becomes much easier to recognise. Imagine a Java application has a user object in memory containing a username, account settings, and session information. The application may need to save that information or send it to another service. Serialization converts the object’s data into a format that can be stored or transmitted. Deserialization does the opposite: it reads that data and reconstructs an object the application can use.

You’ll find this process in many applications. A Java service might serialize objects for storage or communication between components. A Python application might use a serialization format to send background tasks through a message queue. A PHP application might serialize data before storing it or passing it between parts of a system. The exact format and behaviour depend on the language, library, and implementation.

Now, here’s where I want you to start thinking like a security researcher. What happens when an application accepts serialized data from a source an attacker can influence? That data might arrive through a cookie, a request parameter, a POST body, or a message queue. If the application reconstructs objects without appropriate safeguards, it may allow unexpected object states or behaviours. In some vulnerable implementations, object reconstruction can trigger existing methods in an unsafe sequence, potentially leading to serious security consequences.

One important distinction: an attacker doesn’t necessarily need to inject an entirely new program. In certain deserialization vulnerabilities, the danger comes from manipulating data to make existing application code or library functionality behave in an unintended way. Depending on the available classes, execution paths, and security controls, the impact can range from application errors to denial of service or remote code execution. Simply spotting serialized data, however, does not prove that a vulnerability exists.

Note: You may see older resources refer to this issue as Insecure Deserialization or OWASP Top 10 A8:2017. OWASP’s current Top 10 uses different categories, so don’t treat A8 as the current category number. The underlying vulnerability remains important to understand and test for.

A Simple Serialization Example

Let me show you what serialization looks like in practice. Imagine we’re building a small web application that stores a user’s profile. In Python, we might represent that profile as a dictionary:

user = {
    "username": "elite_hunter",
    "role": "student",
    "active": True
}

This is ordinary Python data stored in memory. If we want to convert it into a JSON string so it can be saved or transmitted, we can use Python’s built-in json module.

import json

# Original object
user = {
    "username": "elite_hunter",
    "role": "student",
    "active": True
}

# Serialization: Python object to JSON text
serialized_data = json.dumps(user)

print(serialized_data)

Output:

{"username": "elite_hunter", "role": "student", "active": true}

Notice what happened? Our Python dictionary has been converted into a JSON string. That’s serialization. The data can now be stored in a file or sent to another service that understands JSON.

Now let’s reverse the process. When the application receives that JSON string, it can convert it back into a Python object using json.loads().

# Deserialization: JSON text back to a Python object
restored_user = json.loads(serialized_data)

print(restored_user["username"])
print(restored_user["role"])

Output:

elite_hunter
student

As a bug bounty hunter, I don’t report an application simply because it accepts serialized data. I investigate how that data is processed, whether an attacker can influence it, and whether I can demonstrate a real security impact in an authorised testing environment. That’s the difference between spotting a format and identifying a vulnerability.

import json

user = {
    "username": "elite_hunter",
    "role": "student",
    "active": True
}

# Serialize the Python dictionary
serialized = json.dumps(user)
print("Serialized data:", serialized)

# Restore the dictionary
restored = json.loads(serialized)
print("Restored username:", restored["username"])
print("Restored role:", restored["role"])

incoming_data = '{"username": "guest", "role": "admin", "active": true}'
restored = json.loads(incoming_data)

print("Username:", restored["username"])
print("Requested role:", restored["role"])

import json

incoming_data = (
    '{"username": "guest", '
    '"role": "admin", '
    '"active": true}'
)

data = json.loads(incoming_data)

allowed_fields = {"username", "role", "active"}
allowed_roles = {"student", "researcher"}

if (
    isinstance(data, dict)
    and set(data.keys()) == allowed_fields
    and isinstance(data.get("username"), str)
    and isinstance(data.get("active"), bool)
    and data.get("role") in allowed_roles
):
    print("Input passed basic validation.")
else:
    print("Input rejected: unexpected data or role.")

Recognising the Surface: Serialization Markers by Language

Now that we’ve covered the basics, let’s talk about how I start looking for potential deserialization surfaces during an authorised security assessment. My first step is to understand how the application handles data between requests. I inspect cookies, POST bodies, query parameters, and other places where an application might store or transmit state. Sometimes the values look readable; other times, they’re encoded or appear to be binary data.

Certain serialization formats have recognisable signatures, headers, or structural patterns. These can give us clues about how data was produced. For example, Java’s native serialization stream commonly starts with the bytes AC ED 00 05. Base64-encoded data may conceal the original representation, while PHP serialized values often contain readable type and length markers. Python’s serialization formats vary, so there isn’t one universal prefix that identifies every pickle payload.

Here’s the important distinction I want you to remember: a recognisable marker is a clue, not proof of a vulnerability. The application might never deserialize that value, the format might be used safely, or the data might be protected by integrity checks. My goal at this stage is to form a hypothesis that I can verify in a controlled lab or within the scope of an authorised bug bounty programme.

What I look for

• Java: The native serialization stream header AC ED 00 05 is a useful recognition clue when inspecting raw binary data.
• PHP: Serialized values may contain patterns such as s: for strings, i: for integers, or a: for arrays. The context and complete structure matter.
• Python: Pickle is a binary-oriented format with protocol-dependent structures. Its representation varies by protocol, so don’t rely on a single byte sequence to identify every instance.
• Encoded values: A Base64-looking string may contain serialized data, but Base64 is only an encoding scheme and can represent many unrelated kinds of content.

For the practical part of this lesson, keep your testing within an intentionally vulnerable local application or another explicitly authorised environment. We’ll use the clues above to understand the attack surface without treating every encoded cookie or unusual request parameter as a security bug.

That rO0AB at the beginning of a Base64-encoded value is one of the most useful patterns I want you to recognise in this lesson. It commonly corresponds to Java’s serialization stream header, whose magic bytes are AC ED 00 05. When I spot this pattern in a cookie or request parameter in Burp Suite, I flag it for investigation. It gives me a starting point, but I still need to establish whether the application actually deserializes the value and whether that behaviour creates a security risk.

There’s one more signal I always check: the Content-Type header. Some Java applications use Content-Type: application/x-java-serialized-object to identify Java serialized data. If you see this header in Burp, record it alongside any serialization markers you find. It provides useful context about the intended data format, although the header alone doesn’t prove that the application deserializes the input or that the implementation is vulnerable.

Replace BASE64_VALUE with the complete Base64-encoded value from your lab. If the value is URL-encoded, decode that representation first. The original sample string is abbreviated and shouldn’t be relied on to reproduce the displayed HashMap bytes; use a complete sample when verifying the output.

Here’s the workflow I follow: recognise the possible serialization marker, inspect the relevant headers, decode a copy of the value, and replay the original request in Burp Repeater to establish a baseline. From there, I investigate how the application handles the data in a controlled environment. I only report unsafe deserialization when the evidence supports the vulnerable behaviour and its security impact.

Gadget Chains — What Makes a Surface Exploitable?

Finding a possible deserialization surface is only the first part of the investigation. The next question I ask is: what can the application actually do with the data it reconstructs? This is where gadget chains become important. A serialization marker might tell me where to investigate, but it doesn’t tell me whether an attacker can turn that behaviour into a meaningful security impact.

So, what exactly is a gadget chain? Think of it as a sequence of existing classes and methods that can be triggered through a particular object structure. Under the right conditions, those calls can produce an unintended result, potentially including remote code execution. In Java applications, researchers have studied gadget chains involving libraries such as Apache Commons Collections, Apache Commons BeanUtils, and components of the Spring Framework.

Here’s an important detail: these libraries are not inherently malicious. They’re legitimate software packages used in real applications. The risk depends on the classes and methods available, how they interact, whether the relevant execution path can be reached during deserialization, and what security controls are in place. A library appearing in a dependency list is a reason to investigate, not proof that the application is exploitable.

When I’m assessing a Java application, I look for evidence about its dependencies and configuration where that information is legitimately available. I also consider whether the suspected deserialization path is reachable and whether protective controls prevent unsafe object reconstruction. A dependency inventory can help me form a hypothesis, but I need additional evidence before claiming that a particular gadget chain works.

You don’t need to memorise every historical gadget chain to become a capable bug bounty hunter. What matters is understanding the relationship between the input, the deserialization process, the available application code, and the resulting impact. That’s how you distinguish a potentially interesting surface from a substantiated security finding.

Finding Deserialization Clues with Burp Suite

Now let’s bring the concepts into Burp Suite. When I’m assessing a web application, I start with the traffic the application naturally generates. Burp’s HTTP history gives me a convenient place to review requests, responses, cookies, parameters, and headers that might contain serialized data. If Burp Scanner is available in my setup, I can also use its findings as additional leads, although automated detection won’t identify every deserialization issue.

Once I find something suspicious, I send the original request to Repeater. This lets me examine the request and response carefully and establish a baseline before making any changes. I can also review available extensions, including deserialization-focused research tools, to understand what they detect and what their results actually mean. I always check an extension’s documentation and keep active testing within the programme’s authorised scope.

You may encounter deserialization research tools that use out-of-band interactions, including DNS callbacks, to investigate certain behaviours. These tests can be useful in an appropriately authorised environment, but their results need careful interpretation. A callback might demonstrate that a particular operation was triggered; it does not automatically prove that unsafe deserialization occurred, nor does it establish remote code execution. You need to understand exactly what the test sent and what the observed callback demonstrates.

For this lesson, I want you to focus on building a reliable evidence trail. Record the suspicious parameter, the format indicators you observed, the original response, any scanner findings, and the limitations of your conclusions. If you need to demonstrate potentially dangerous behaviour, reproduce it in your own lab rather than escalating tests against a live service without explicit permission.

# Decode a Base64 sample into raw bytes
printf '%s' 'BASE64_SAMPLE_HERE' | base64 --decode > decoded.bin

# Inspect the first 32 bytes as hexadecimal
xxd -l 32 decoded.bin

# Identify the file format using local file-signature hints
file decoded.bin

Lab: Confirming Behaviour Safely in WebGoat

WebGoat is OWASP’s deliberately vulnerable web application, designed to help learners understand common web security weaknesses in a controlled environment. In this lab, I’ll use a compatible WebGoat release to study insecure deserialization and learn how to distinguish a recognizable serialization format from evidence of unsafe application behaviour.

Safety first: Run this lab only on your own machine or in an environment you are explicitly authorized to test. The commands below publish ports on the Docker host, so use a trusted machine and ensure those ports are not exposed to an untrusted network.

What I Verify in the Lab

I start by capturing a normal request in Burp Suite and identifying where the application receives the relevant input. If the lab provides a serialized value, I inspect its representation using Burp Decoder or a hexadecimal viewer without executing unknown data.

• Identify: Record the input location and any format indicators.
• Establish a baseline: Send the normal lab request and note the response.
• Compare safely: Follow the lesson’s instructions and use only its intended test cases.
• Observe: Record response changes, validation errors, and other reproducible evidence.
• Conclude carefully: A serialization marker or an error by itself does not establish an exploitable vulnerability.

When finished, stop and remove the lab container:

Writing the Report That Gets Paid

A deserialization finding reported as “I found Base64 in a cookie; it might be deserializing” gives triage very little to verify. A strong report identifies the affected input, explains the observed behaviour, provides reproducible evidence, and separates confirmed impact from potential impact. Report quality can make a finding much easier to validate, but no wording guarantees acceptance or a particular bounty. Let me show you a structure that works.

Notice the distinction: the report documents what was observed, explains why it may indicate a security weakness, and identifies what remains unproven. A lab reproduction demonstrates the technique in that lab; it does not establish that a production target behaves the same way. Likewise, a known gadget library being present does not by itself prove that a usable gadget chain is reachable.

Severity, CVSS and What to Claim

One question I hear often about deserialization findings is: “Can I claim Critical without proving remote code execution?” My answer is: you can report a potentially serious weakness without demonstrating RCE, but your severity must match the evidence. A deserialization surface, a library that may support a gadget chain, or a DNS callback does not automatically establish Critical impact or a CVSS score of 9.8.

CVSS is based on defined metrics, not on the vulnerability name or the worst-case outcome someone can imagine. The score depends on the demonstrated attack path, network reachability, required privileges, user interaction, and the impact on confidentiality, integrity, and availability. A library appearing in a dependency manifest does not prove that a usable gadget chain is reachable, and a callback does not by itself prove RCE or even establish that deserialization caused the callback.

Where researchers get into trouble is claiming impact they have not demonstrated. If I report RCE, I need authorised, reproducible evidence supporting that claim. If I have confirmed that user-controlled input reaches an unsafe deserialization operation but have not demonstrated code execution, I state that limitation clearly. For example: “Testing confirmed that user-controlled input reaches the application’s deserialization path. The available evidence does not establish remote code execution. The dependency information suggests a potential avenue for further assessment, subject to reachability, configuration, and applicable mitigations.” That is a defensible technical conclusion; triage will determine severity under the programme’s policy.