In January 2022, Oracle published details about a security issue tracked as CVE-2022-21341 in its Java SE platform and GraalVM Enterprise Edition. This vulnerability exists in the Serialization component, which is a mechanism widely used to convert objects to byte streams and vice versa. This post explains what CVE-2022-21341 is, who is affected, how it can be exploited, and provides original references and sample code for better understanding.

CVSS v3.1 Base Score: 5.3 (Availability impacts)

- CVSS Vector: AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

References:

Oracle CPU Advisory - Jan 2022  
  NVD record - CVE-2022-21341

What is Serialization, and Why Does This Matter?

Java serialization is the process of converting an object into a byte stream for transfer over a network or saving to disk. It’s powerful, but also a risky feature. For years, there have been exploits using dangerous objects that, when deserialized, can cause unwanted behavior like code execution or resource exhaustion.

In a secure application, only trusted sources should provide serialized data. But when untrusted sources (like users over the internet) provide data to serialization APIs, attackers may send crafted data streams to exploit bugs in the serialization logic.

Why Is CVE-2022-21341 Important?

This CVE is labeled as "easily exploitable" (AC:L, PR:N, UI:N) and does NOT require authentication or user interaction. It impacts clients running sandboxed Java Web Start apps, applets, or any Java app loading code from untrusted sources and depending on the Java sandbox for safety.  

Successful exploitation causes partial denial of service (DoS). An attacker can crash or freeze Java applications or services by sending malicious serialized data, thus impacting the application's availability. While the vulnerability isn't about stealing data or remote code execution, even making a Java service unavailable can have significant effects.

Technical Details: How Does the Exploit Work?

While Oracle did not detail the root cause, this class of serialization issues usually relates to “gadget chains” or unsafe handling of certain classes during object deserialization. Attackers can send a specially crafted byte stream through a network socket or web service API that ends up in ObjectInputStream.readObject() (or similar API). When deserialized, the Java process may go into an infinite loop, massive memory consumption, or other resource-intensive state, crashing or considerably slowing down the application.

Vulnerable Scenario Example

Imagine a Java server exposes a web service accepting serialized objects as input. An attacker could POST a maliciously crafted serialized object stream to the API endpoint; the server, upon deserializing it, get stuck or crash.

Example Java Code: Vulnerable Deserialization

import java.io.*;

public class VulnerableServer {
    // Example: Do NOT use such code with untrusted sources!
    public void handleRequest(byte[] data) throws IOException, ClassNotFoundException {
        try (ObjectInputStream in = new ObjectInputStream(new ByteArrayInputStream(data))) {
            Object input = in.readObject();
            // Do something with the input
        }
    }
}

Warning: The above code is a simplified example. In real-world apps, this could happen over HTTP, WebSocket, or RMI. Accepting serialized data from *any* untrusted source without validation or filtering is dangerous.

Demonstration: Malicious Payload

While the specific serialized data that exploits CVE-2022-21341 is not publicly disclosed (and typical for Oracle advisories), many serialization vulnerabilities are abused using crafted payloads like the following:

Let's say the DoS is caused by deserializing certain recursive or faulty object graphs

import java.io.*;
import java.util.*;

public class MaliciousPayload {
    public static void main(String[] args) throws Exception {
        // Create two Lists referencing each other (infinite loop on deserialization)
        List<Object> list1 = new ArrayList<>();
        List<Object> list2 = new ArrayList<>();
        list1.add(list2);
        list2.add(list1);

        ByteArrayOutputStream baos = new ByteArrayOutputStream();
        try (ObjectOutputStream out = new ObjectOutputStream(baos)) {
            out.writeObject(list1);
        }

        byte[] payload = baos.toByteArray();

        // Send payload to vulnerable service (e.g., via HTTP client)
    }
}

When a vulnerable server deserializes this, the process may loop forever navigating the circular references, causing high CPU/memory usage or crash.

Note: The *actual* exploit for CVE-2022-21341 may differ, but conceptually, this is the risk.

Exploitation Vectors

- Direct: Sending crafted object streams to network services expecting Java serialized input (RMI, custom TCP, HTTP endpoints).
- Indirect: Uploading malformed serialized data to web APIs or services (e.g., via SOAP or REST endpoints that internally use Java serialization).
- Sandboxed Applications: Java Web Start or applets running code from untrusted sites processing attacker-provided data.

How to Fix or Mitigate

1. Upgrade Java/GraalVM:

GraalVM EE: 20.3.5, 21.3.1 or later

See: Oracle CPU Advisory

2. Disable/Restrict Serialization Where Possible:  
  Avoid using Java serialization for untrusted input. Use safer formats like JSON/GSON, XML, or Protobuf.

Validate Object Types:

Use a filtering mechanism (Java 9+ ObjectInputFilter, or 3rd party solutions) to allow only expected types.

Additional References

- Oracle CPU Jan 2022 Advisory, Java Section
- NVD Record CVE-2022-21341
- Java Serialization Filter Best Practices

Final Thoughts

CVE-2022-21341 is a reminder of how risky it is to deserialize data from untrusted sources in Java applications. Even if you’re not exposed today, make sure serialization is only used in safe, internal contexts, and always keep your runtimes patched.

If your apps run or depend on Java SE or GraalVM EE in the affected versions, upgrade as soon as you can. Disable Java serialization of untrusted data wherever possible, and review all external-facing endpoints for direct or indirect exposure.

Share and Stay Safe!

If you found this useful, consider sharing with your Java developer team or anyone relying on Oracle Java products. Security is everyone's job!


Disclaimer: The code and exploit information above are for educational purposes only. Never test on systems without permission. Stay legal and ethical.


*Original research and content created for exclusive use. All links provided direct to authoritative sources for further reading.*

Timeline

Published on: 01/19/2022 12:15:00 UTC
Last modified on: 05/13/2022 14:46:00 UTC