What causes Java Deserialisation?

Java Deserialisation is caused when an application accepts untrusted serialized Java objects and reconstructs them without strict controls. Attackers can trigger gadget chains, unexpected object states, or denial of service during object creation. Defenders should avoid deserialising untrusted data, prefer safer data formats, and restrict allowed classes wherever deserialisation cannot be removed.

Why Java deserialisation becomes dangerous

Java deserialisation is risky because the application is not just reading data, it is reconstructing live objects and executing class logic during that process. If the input is untrusted, the attacker can influence which classes are loaded, what methods run, and whether object construction reaches a dangerous code path. That is why insecure deserialisation often turns into code execution, logic abuse, or service disruption.

The core problem is trust. Serialized Java data can carry more than plain values, including object graphs, references, and state transitions that the receiving application did not intend to permit. If the application assumes the payload is safe and rebuilds it without validation, the deserialiser can become an execution boundary instead of a simple parser.

Java-specific behaviour matters because gadget chains often live in ordinary libraries the developer did not consider security-sensitive. A harmless-looking class in the classpath can become part of a chain that performs attacker-controlled actions when the object graph is restored. In practice, the weakness is rarely the serializer alone, it is the combination of untrusted input, available gadgets, and overly broad object acceptance.

What actually triggers the flaw at runtime

Several conditions usually need to line up before deserialisation becomes exploitable. The application must accept a serialized Java stream from outside its trust boundary, it must deserialize that stream automatically, and it must do so without a strict allowlist or filtering policy. When those controls are missing, even a single request can trigger unsafe object creation.

Attackers commonly aim for one of three outcomes. First, they try to reach a gadget chain that produces code execution or command execution. Second, they try to force unexpected object states that alter application behaviour, such as privilege-related logic errors or security control bypasses. Third, they try to induce resource exhaustion through oversized or deeply nested object graphs that cause memory pressure, CPU spikes, or thread starvation.

Insecure Deserialisation Guide is the right parent topic when you need the broader pattern across Java and other runtimes, including object injection, gadget chains, and allowlist filtering.

How defenders reduce exposure without breaking the application

The safest answer is to stop deserialising untrusted Java objects altogether and replace them with a simpler data format that does not reconstruct executable object state. Where Java serialization cannot be removed immediately, the next-best control is to constrain what the application is allowed to instantiate. That means strict class filtering, narrow allowlists, and rejection of unexpected object types before they reach sensitive code paths.

Defensive design also includes reducing gadget availability. Fewer libraries on the classpath means fewer candidate chains for an attacker to abuse. Applications that must accept serialized input should treat the deserialisation boundary as hostile, not as a convenience feature, and should place it behind strong input validation, monitoring, and failure handling that terminates suspicious payloads cleanly.

For Java environments that still rely on object streams, the practical benchmark is whether the application can prove that only known-safe classes are allowed to materialise. If that proof is weak, the control is not strong enough, even if the feature appears to work under normal testing.

Risk and Threat Considerations

Insecure Java deserialisation is dangerous because the exploit happens during object reconstruction, before normal application logic can inspect the data. That makes the vulnerable code path attractive for remote compromise, especially when the deserialiser sits in an API, message handler, or other entry point that processes untrusted traffic.

Failure mechanism: The application accepts attacker-supplied serialized objects, restores them into live Java classes, and allows class initialisation or method execution to occur before type and trust restrictions are enforced.

Impact: The result can be remote code execution, privilege abuse through unexpected object state, denial of service through resource exhaustion, or wider compromise if the payload reaches a privileged component or service account context.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	SI-10 — Information Input Validation	Stops hostile serialized input from reaching object creation unchecked.
	AC-6 — Least Privilege	Limits the blast radius if deserialisation triggers dangerous code paths.
	SC-18 — Mobile Code	Addresses hostile code-like behaviour delivered through deserialised objects.
Recommendation — Validate serialized input and reject unexpected object structures before deserialisation. Run deserialisation code with the minimum privileges needed. Restrict or disable object deserialisation where untrusted code execution paths exist.
CIS Controls v8	CIS-8 — Audit Log Management	Useful for detecting suspicious deserialisation attempts and follow-on abuse.
Recommendation — Log deserialisation failures and suspicious object-type rejections for investigation.
OWASP ASVS	V5 — File Handling	Covers unsafe handling of non-plain-text data that can carry executable object state.
Recommendation — Prefer simple, validated data formats over deserialising complex object graphs.

Practitioner Guidance

What to prioritise: If a code path accepts serialized Java data from outside the trust boundary, treat it as a security hotspot until proven otherwise. The first decision is not how to harden the parser, but whether the format can be removed or replaced with a non-executable alternative.

What to verify: Confirm whether the application enforces an explicit allowlist of classes and rejects everything else, and test whether nested or indirect object references can still reach dangerous library code. Also verify that error handling fails closed rather than partially reconstructing a payload.

Common mistake: Teams often assume a payload is safe because it comes from a trusted upstream system, but trust frequently degrades at integration boundaries. A deserialisation bug in one service can become a compromise path for the next service that consumes its output.

Practitioner takeaway: The real security decision is whether the application needs Java deserialisation at all, because once untrusted object restoration is allowed, the attack surface includes class loading, object state, and any gadget already present in the runtime.