The vulnerability is particularly important in applications that accept serialized objects from clients, process untrusted session data or use libraries with dangerous deserialization behaviour.

• Primary risk: Untrusted serialized data influences application behaviour during object reconstruction.

• Common targets: Web applications, APIs, session management systems, background workers and distributed services.

• Potential impact: Authentication bypass, data manipulation, denial of service and remote code execution.

• Key investigation evidence: Request payloads, application exceptions, process execution, file changes and network telemetry.

• Primary defences: Avoid deserializing untrusted data, use safer formats, validate inputs and restrict object construction.

1. When Data Becomes Dangerous

Imagine an application that allows users to save their preferences, shopping baskets or workflow state. To preserve this information, the application converts an object into a serialised representation that can be stored or transmitted.

Later, the application reconstructs the original object from that representation.

This process is known as deserialization.

In a secure design, the application treats incoming data as untrusted and restricts how it is processed. However, some serialization mechanisms can reconstruct complex objects and invoke methods, constructors, callbacks or other functionality as part of that process.

If an attacker can control the serialized input and the application uses unsafe deserialization behaviour, the application may perform actions that the developer never intended.

This creates an insecure deserialization vulnerability.

The risk is not that serialization itself is inherently unsafe. Serialization is widely used in legitimate systems. The danger arises when untrusted data is allowed to influence object reconstruction or trigger powerful application behaviour without adequate controls.

2. Understanding Serialization and Deserialization

Serialization converts an in-memory object into a representation that can be stored or transmitted. Deserialization reverses that process.

A simplified workflow looks like this:

<box border radius="lg" padding={3} gap={2}> <box background="surface-secondary" radius="md" padding={3} align="center" gap={1}> <icon name="box" size="xl" /> **Application Object** <text color="secondary" size="sm">User preferences, session state or application data</text> </box> <box align="center"> <icon name="arrow-down" size="lg" color="secondary" /> </box> <box border radius="md" padding={3} align="center" gap={1}> <icon name="file-code" size="xl" /> **Serialization** <text color="secondary" size="sm">Converts the object into a transferable representation</text> </box> <box align="center"> <icon name="arrow-down" size="lg" color="secondary" /> </box> <box background="surface-secondary" radius="md" padding={3} align="center" gap={1}> <icon name="database" size="xl" /> **Stored or Transmitted Data** <text color="secondary" size="sm">May pass through clients, APIs, queues or storage systems</text> </box> <box align="center"> <icon name="arrow-down" size="lg" color="secondary" /> </box> <box border radius="md" padding={3} align="center" gap={1}> <icon name="shield-alert" size="xl" /> **Deserialization** <text color="secondary" size="sm">Reconstructs the object and may invoke application behaviour</text> </box> </box>

Consider a legitimate application that serializes a shopping basket containing product identifiers and quantities. When the basket is restored, the application reconstructs the corresponding data structure.

Problems arise when the application accepts attacker-controlled serialized objects and trusts the information or behaviour they represent.

Depending on the implementation, deserialization may go beyond reading simple values. It may instantiate classes, resolve types, invoke callbacks or interact with application libraries.

That additional behaviour creates the possibility of exploitation.

3. Why Insecure Deserialization Can Lead to RCE

Remote code execution is one of the most serious potential outcomes, but it is not an automatic consequence of every deserialization vulnerability.

A typical exploitation chain may involve several conditions.

Stage 1 — Attacker-controlled input: The application accepts serialized data that the attacker can influence.

Stage 2 — Unsafe object reconstruction: The application processes the input using a deserialization mechanism that permits dangerous object types or behaviours.

Stage 3 — Reachable application functionality: The reconstructed object interacts with available methods, callbacks, library features or other functionality in an unsafe way.

Stage 4 — Dangerous side effect: Processing the object causes an unintended operation, such as accessing a sensitive resource or invoking a command-execution path.

Stage 5 — Potential code execution: If the required conditions are satisfied, the attacker may execute code within the permissions of the affected application process.

Stage 6 — Possible follow-on compromise: An attacker may attempt to access credentials, modify files, establish persistence or reach additional systems, depending on the privileges and network access available.

The outcome depends on the programming language, serialization framework, available dependencies, application configuration and runtime permissions.

A malformed serialized object that triggers an exception may represent an unsuccessful attack attempt rather than successful code execution.

4. Common Serialization Formats and Technologies

Serialization mechanisms differ significantly in their security properties. Some formats represent data structures, while others can encode language-specific object information or participate in object reconstruction with side effects.

Technology or formatTypical useSecurity considerationJava native serializationTransferring or storing Java objectsReview object types, deserialization filters and available gadget chainsPython pickleSerializing Python objectsUnpickling untrusted data can execute arbitrary codePHP serializationRepresenting PHP values and objectsObject reconstruction may invoke magic methods and interact with vulnerable classes.NET object serialization mechanismsApplication state and object transferRisk depends on the serializer, permitted types and application configurationYAMLConfiguration and structured dataUnsafe loaders may construct objects or invoke functionality beyond simple data parsingJSONAPIs and application data exchangeBasic JSON parsing is generally data-oriented, but unsafe type binding and downstream processing can introduce other vulnerabilities

Important distinction: JSON is not inherently equivalent to a native object serialization mechanism such as Python pickle or Java native serialization. Risks associated with JSON often arise from unsafe type handling, automatic object binding or later application logic.

Likewise, not every use of Java, PHP, .NET or YAML is vulnerable. The specific deserialization mechanism and configuration must be assessed.

5. Gadget Chains: How Existing Code Can Become an Attack Path

One concept frequently associated with insecure deserialization is a gadget chain.

A gadget is a piece of existing application or library functionality that can produce a useful side effect when invoked under particular conditions.

A gadget chain connects multiple pieces of functionality so that processing a crafted object may trigger a sequence of unintended operations.

For example, a chain might involve an object being reconstructed, a callback being invoked, and a library function performing an operation with security implications.

In some environments, an attacker does not need to upload a new executable or exploit a memory-corruption flaw. The vulnerable application may already contain the relevant classes and libraries.

However, finding a potentially useful class does not prove exploitability. A successful chain depends on factors such as:

• The libraries and versions present.

• Whether the relevant classes can be instantiated.

• The execution path taken during deserialization.

• Security controls and type restrictions.

• Runtime permissions and environmental constraints.

For defenders, dependency inventories and software composition analysis can help identify libraries that warrant investigation. These findings should be combined with an assessment of whether the vulnerable deserialization path is actually reachable.

6. Investigating Insecure Deserialization in a SOC

Consider a hypothetical alert involving a public-facing application that receives an unusually large or malformed serialized payload. Shortly afterward, the application process generates an unexpected child process and attempts an outbound connection.

The SOC team needs to determine whether the activity represents normal application behaviour, a failed exploitation attempt or successful compromise.

Step 1: Examine the original request

Review reverse proxy, WAF, API gateway and application logs.

Look for:

• Unexpected serialized data in request bodies or parameters.

• Unusually large or deeply nested objects.

• Unexpected type identifiers or class references where the format supports them.

• Repeated malformed requests to the same endpoint.

• Requests that precede deserialization errors or application crashes.

Do not assume that a large payload or unfamiliar object type is malicious. Some legitimate applications exchange complex objects or process large documents.

Preserve the original payload where permitted, along with its timestamp, request path, response code and relevant connection identifiers.

Step 2: Identify the deserialization mechanism

Work with the application team to establish:

• The programming language and framework.

• The serializer or deserializer in use.

• Whether the application accepts serialized data directly from clients.

• Whether authentication is required to reach the affected functionality.

• Which classes, types or callbacks can be reached during reconstruction.

Review source code, dependencies and configuration where available.

The objective is to establish whether untrusted input reaches a dangerous deserialization operation, not merely whether the application uses serialization.

Step 3: Correlate application errors

Look for deserialization exceptions, type-resolution failures, unexpected class-loading activity and repeated application errors.

Compare the timestamps with the original HTTP requests and determine whether failures occur consistently with specific input patterns.

Errors can reveal that an application attempted to process unexpected data, but they do not by themselves prove that an attacker achieved code execution.

Step 4: Review process execution

Examine endpoint telemetry for unexpected processes created by the web server, application runtime or background worker.

Investigate:

• Parent-child process relationships.

• Command-line arguments.

• Unexpected shell or scripting interpreter activity.

• File creation and modification.

• Changes to application configuration.

• Unusual network connections.

• EDR detections around the same time.

For example, a Java application unexpectedly launching a shell process may warrant investigation, but the finding must be assessed against the application's legitimate functions and deployment design.

Step 5: Investigate network activity

Review DNS, firewall, proxy and network flow records for connections initiated by the affected host after the suspicious request.

Determine whether the application contacted an unfamiliar external destination or an internal service that it does not normally use.

Where possible, correlate the connection with the responsible process and request timeline.

An outbound connection following a suspicious payload is supporting evidence, not proof that deserialization caused the connection.

Step 6: Assess credentials and downstream impact

If code execution or sensitive-data access is confirmed, investigate whether the attacker could access:

• Application configuration and secrets.

• Database credentials.

• Cloud workload identities.

• Service account tokens.

• Files and data accessible to the application.

• Internal services reachable from the affected host.

Review identity and cloud audit logs for unusual credential use or API activity.

Determine the scope of the incident from evidence rather than assuming that every deserialization alert resulted in a full server compromise.

7. Evidence and Indicators to Review

Insecure deserialization does not have a universal indicator of compromise. Effective investigations combine request-level evidence with application, endpoint and network telemetry.

Evidence sourceWhat to investigateWAF and proxy logsSuspicious payloads, unusual request sizes and repeated probingApplication logsDeserialization exceptions, unexpected types and processing failuresSource code and dependenciesUnsafe deserialization APIs and vulnerable librariesEDR process telemetryUnexpected child processes or execution chainsFile integrity monitoringUnexpected scripts, binaries or configuration changesNetwork telemetryUnusual outbound connections after suspicious requestsAuthentication logsUnexpected access to application or service accountsCloud audit logsUnusual activity by the application's workload identityDeployment recordsRecently introduced libraries, configuration changes or exposed endpoints

Patterns that may warrant investigation

• Repeated requests containing unexpected serialized object structures.

• Deserialization exceptions followed by unusual process activity.

• An application runtime launching a shell or scripting interpreter without a clear business reason.

• Unexpected file modifications after a suspicious request.

• Outbound connections from an application host to previously unseen destinations.

• Unusual access to secrets or cloud resources following suspected exploitation.

These signals should be correlated before classifying an incident as successful remote code execution.

8. Detection Engineering and MITRE ATT&CK

A practical detection strategy combines suspicious serialized input with behavioural evidence.

Example detection logic

1. Identify endpoints that accept serialized or complex structured objects.

2. Detect abnormal payload structures or repeated deserialization failures.

3. Correlate suspicious requests with unexpected process creation by the application runtime.

4. Enrich the event with application identity, host criticality, process lineage and network activity.

5. Investigate follow-on access to secrets, internal services or cloud APIs.

6. Assign severity based on confirmed behaviour and potential impact.

Avoid relying solely on payload signatures. Attackers can use different serialization formats, and legitimate traffic may contain unusual structures.

MITRE ATT&CK mapping

The relevant mappings depend on the behaviour demonstrated by the evidence.

• T1190 — Exploit Public-Facing Application: Relevant when an attacker exploits a vulnerability in an internet-facing application.

• T1059 — Command and Scripting Interpreter: Relevant when command or scripting interpreter execution is observed and supported by the investigation.

• T1105 — Ingress Tool Transfer: Relevant if evidence shows that an attacker transferred tools or files into the compromised environment.

• T1552 — Unsecured Credentials: Potentially relevant if the attacker obtains credentials from accessible files, configuration or other unsecured locations.

Insecure deserialization is a vulnerability class rather than a single ATT&CK technique. Do not assign every listed technique to every suspected event.

9. Preventing Insecure Deserialization

The strongest defence is to avoid deserializing untrusted data using mechanisms that can instantiate dangerous objects or trigger unintended behaviour.

Avoid unsafe native deserialization

Where possible, use formats and APIs designed to represent data rather than arbitrary language-specific objects.

For example, Python applications should not use pickle to process untrusted input. Similar care is required when choosing native object serialization mechanisms in other languages.

Use strict schemas and type allowlists

Define which fields, types and values are permitted. Reject unexpected properties and types instead of attempting to reconstruct arbitrary objects.

Validation must be applied before sensitive application operations, and it should be enforced consistently across every endpoint that accepts the data.

Use safe framework features

Where deserialization is necessary, use supported filtering, type restrictions and security controls provided by the framework.

For Java applications, review the available deserialization filtering mechanisms. For .NET and other platforms, select serializers appropriate to the use case and avoid unsafe legacy mechanisms.

Keep dependencies updated

Track vulnerable libraries and remove unnecessary dependencies. Review software composition analysis findings to determine whether potentially dangerous classes or components are present in reachable code paths.

Enforce least privilege

Run application processes with minimal operating-system permissions. Restrict filesystem access, outbound network connectivity and access to sensitive credentials.

These controls can reduce the impact of successful exploitation even when an application vulnerability remains.

Protect application secrets

Store secrets using appropriate secret-management controls and grant access only to workloads that require them. Avoid embedding sensitive credentials in serialized objects or exposing them through application state.

Monitor application behaviour

Alert on unusual process creation, unexpected outbound traffic, suspicious file modifications and repeated deserialization failures.

Combine application-level detection with EDR and network telemetry to improve confidence and investigation speed.

10. Incident Response Checklist

When insecure deserialization exploitation is suspected:

1. Preserve evidence: Collect relevant HTTP requests, application logs, endpoint telemetry and network records.

2. Identify the affected code path: Establish the serializer, framework, endpoint and vulnerable processing operation.

3. Confirm the impact: Determine whether the evidence supports input manipulation, information disclosure or code execution.

4. Contain the affected service: Restrict or disable the vulnerable functionality where necessary.

5. Assess credential exposure: Review accessible secrets and rotate affected credentials when warranted.

6. Investigate follow-on activity: Examine process execution, file changes, network connections and identity events.

7. Remediate the root cause: Replace unsafe deserialization, apply strict type controls and patch affected dependencies.

8. Validate the fix: Retest in a controlled environment and monitor for renewed exploitation attempts.

Conclusion

Insecure deserialization can turn an ordinary data-processing operation into a security boundary failure. When an application reconstructs attacker-controlled objects using unsafe mechanisms, existing application or library functionality may be triggered in unexpected ways.

The consequences range from parsing errors and information disclosure to remote code execution. The actual impact depends on the serialization mechanism, reachable functionality, application permissions and security controls.

For SOC analysts, the priority is to correlate suspicious payloads with application behaviour, process execution and network activity. For developers, the most effective approach is to minimise the use of unsafe deserialization, restrict permitted object types and ensure that application processes have only the privileges they need.

The key lesson: Serialized data should never be trusted simply because it can be converted back into an object.

Further Reading

• OWASP — Deserialization Cheat Sheet

• PortSwigger Web Security Academy — Insecure Deserialization

• CWE-502 — Deserialization of Untrusted Data

• Official documentation for the application's programming language and serialization framework

• MITRE ATT&CK — T1190: Exploit Public-Facing Application