When it comes to critical business applications, Java is everywhere—running on desktops, servers, and now, in the cloud via technologies like Oracle GraalVM. But even the most mature platforms sometimes overlook lurking dangers in legacy components. One such risk surfaced in late 2021—CVE-2022-21248—affecting Oracle Java SE and Oracle GraalVM Enterprise Edition, specifically within the Serialization component. In this exclusive, detailed walkthrough, we’ll break down what this vulnerability is, how it can impact you, and share code snippets and exploit details so you can truly understand the risk.
What Is CVE-2022-21248?
CVE-2022-21248 is a vulnerability in Oracle Java SE (versions: 7u321, 8u311, 11..13, 17.01) and GraalVM Enterprise Edition (versions: 20.3.4, 21.3.) within the Serialization component. It allows an unauthenticated attacker (someone who hasn’t logged in) to exploit the service over a network connection using different protocols.
Impact: Unauthorized update, insert, or delete of data (Integrity Impact only)
- Official Advisory: Oracle Security Advisory
Why Serialization?
Serialization is the process of turning an object into a byte stream so it can be saved to disk or sent over a network. Deserialization is the reverse. Bad things can happen when Java applications deserialize data from untrusted sources—this can lead to unpredictable objects and, on occasion, a path to remote code execution or data manipulation.
Who’s At Risk?
This vulnerability strikes Java deployments that run untrusted code—meaning environments such as:
- Java Web Start Applications: Deployed from the web and running in a (supposedly) trusted sandbox.
APIs that Accept Serialized Data: Web services that receive Java serialized objects.
If you run these environments with the affected Java or GraalVM versions and let users hand you serialized data, you are at increased risk.
Here’s how an attacker might take advantage of this bug
1. Attacker crafts a malicious serialized Java object that, when deserialized, can trigger unwanted logic or data manipulation in the Java SE/GraalVM application.
2. That object is sent over the network (via HTTP, RMI, or any protocol/application endpoint that accepts serialized objects).
The vulnerable component reads (deserializes) this data, trusting it is safe.
4. During deserialization, the attacker’s payload allows them to alter or corrupt application data—potentially causing unauthorized updates, inserts, or deletions.
Here’s a simple vulnerable Java code that processes a serialized object from a network connection
// DANGEROUS: Deserializing user-supplied data directly!
ObjectInputStream in = new ObjectInputStream(clientSocket.getInputStream());
Object obj = in.readObject();
// ...use obj for processing, e.g., updating a database
If obj implements certain methods (e.g., custom readObject() or overrides), it can trigger side effects—like running arbitrary code or altering application state. The Java sandbox is supposed to prevent this, but vulnerable components can have logic flaws.
The Exploit in Practice
Attackers typically take well-known gadgets from Java's library or common third-party libraries and chain them to build a serialized object that does something malicious.
Example Exploit Summary
1. Attacker crafts a custom Java class with malicious code in a method like readObject(), which is called when deserialized.
2. That class is serialized and sent (maybe via a web API or service endpoint) to the target Java process.
Why Is This Hard to Exploit?
- Attack Complexity is High: The attacker needs to know a lot about the application internals, the classes available, the configuration, and more.
- No Direct Remote Code Execution: The bug is about unauthorized data manipulation, not about running arbitrary code.
- Integrity Only: The vulnerability doesn’t let the attacker steal confidential data, just alter it.
Upgrade to the latest secure versions
- Java SE update: Oracle Java Downloads
- GraalVM Enterprise Edition: GraalVM EE Downloads
2. Never Trust User-Supplied Serialized Data
Do NOT accept or deserialize objects from untrusted sources.
3. Consider Serialization Filtering
Use Java’s built-in serialization filtering (ObjectInputFilter) to control what classes can be deserialized.
ObjectInputFilter filter = info -> {
if (info.serialClass() != null && info.serialClass().getName().startsWith("java.lang.")) {
return Status.ALLOWED;
}
return Status.REJECTED;
};
ObjectInputStream in = new ObjectInputStream(clientSocket.getInputStream());
in.setObjectInputFilter(filter);
Object obj = in.readObject();
Official Oracle Advisory:
Oracle Critical Patch Update Advisory - January 2022
CVE Details:
Java Serialization Security:
OWASP Deserialization Cheat Sheet
Oracle Patch Guide:
Oracle CPU Patch Documentation
TL;DR
CVE-2022-21248 exposes Oracle Java SE and GraalVM to unauthorized data tampering when deserializing untrusted objects. The risk is highest for apps that accept serialized data from users, such as APIs and legacy web applications. Exploitation isn’t trivial and requires good knowledge of both Java and the target application, but the safest option is to always keep your JDK up to date and never deserialize data from unknown sources. Serialization bugs are tricky and often underestimated—don’t let this one sneak up on you!
Stay secure—patch up, review your APIs, and banish unsafe deserialization from your codebases.
*Authored by SecurityBytes – Exclusive long-read for infosec enthusiasts*
Timeline
Published on: 01/19/2022 12:15:00 UTC
Last modified on: 05/13/2022 15:14:00 UTC