In late 2021, Oracle quietly patched a flaw tracked as CVE-2022-21296. This security bug, found in the JAXP (Java API for XML Processing) component of Oracle Java SE and Oracle GraalVM Enterprise Edition, doesn’t cause devastating data leaks or remote code execution, yet it’s more dangerous than it seems—especially if you’re running sandboxed Java applications that trust the Java security model.
This article aims to shine a light on what’s going on, how exploitation might look, and why this sort of thing matters even if “only” confidentiality is affected. I’ll try to keep it simple and hands-on, with code samples and plenty of helpful references at the end.
Oracle GraalVM Enterprise Edition: 20.3.4 or 21.3.
and your application does XML processing (especially with user-supplied or web-fetched data), you need to pay attention. This applies especially to:
Web services (SOAP, REST) that rely on JAXP
You’re at risk if you run Java code from untrusted sources or care about user data confidentiality.
Summary of the Vulnerability
CVE-2022-21296 is an “information disclosure” flaw. That means an attacker can exploit it to read, but not modify or destroy, data they shouldn’t have access to.
Confidentiality Impact: Low to medium (attacker can read a limited subset of data)
- CVSS Score: 5.3 (see Oracle Advisory and official Oracle Critical Patch Update Advisory - Jan 2022)
Technical Overview: JAXP at the Heart
JAXP (Java API for XML Processing) is Java’s built-in XML parsing API. It’s a core Java technology and is used in everything from web services and configuration files to document viewers. The bug arises from insufficient validation or sandbox enforcement when JAXP parses attacker-controlled data. In some circumstances, this allows the attacker to access files or resources they shouldn’t.
Typical scenario
- The Java sandbox or permission manager is supposed to block file or network access in untrusted code.
- Malicious XML processed by JAXP can reference external resources (like files or URLs) via so-called “XXE” (XML External Entity) injection or similar tricks.
Exploitation: A Walkthrough
Let’s see how this could work using a simple Java example.
Suppose your application parses XML from user input like this
import javax.xml.parsers.*;
import org.w3c.dom.*;
import org.xml.sax.SAXException;
import java.io.*;
public class XmlProcessor {
public void processXml(String inputXml) throws Exception {
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
DocumentBuilder builder = factory.newDocumentBuilder();
Document doc = builder.parse(new ByteArrayInputStream(inputXml.getBytes()));
// Process the document
}
}
If you receive attacker-supplied XML, you’re at risk. Here’s a malicious XML payload for XXE
<?xml version="1." encoding="UTF-8"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:///etc/passwd" >
]>
<foo>&xxe;</foo>
If JAXP isn’t properly configured to disable external entities, the contents of /etc/passwd (on Unix-like systems) could be read and processed as part of the XML document.
Java code parses the XML using JAXP (often without restrictions).
3. External entity is resolved, reading arbitrary files or network resources the Java process can access.
4. Stolen data may end up in error messages, logs, or responses sent back to the attacker, leading to exposure.
Secure Configuration
The right way to mitigate this (also note that Oracle fixed it at the library level) is to explicitly turn off external entity resolution:
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl";, true);
factory.setFeature("http://xml.org/sax/features/external-general-entities";, false);
factory.setFeature("http://xml.org/sax/features/external-parameter-entities";, false);
// many more features should be evaluated based on your use-case
Sandbox Bypass Variant
Why does Oracle highlight sandboxes and untrusted code?
Previously, Java’s “sandbox” security model (using SecurityManager and fine-grained permissions) was supposed to protect host resources from code loaded from untrusted sources. CVE-2022-21296 indicates that an attacker can sidestep these protections by abusing JAXP’s insecure defaults, getting access to things they shouldn’t—even within a supposedly locked-down Java sandbox or applet.
Users *may* run Java Web Start or applet code from the internet, thinking they're protected.
- If you process XML from untrusted sources (such as SOAP web services), attacker-controlled data can leak passwords, private addresses, or even secrets from cloud environments.
Real-World Impact Example
Imagine a financial web app running on Java 8u311 that takes uploaded XML statements for processing. An attacker submits crafted XML using external entities pointing to /proc/self/environ, leaking environment variables (which might include credentials or tokens).
Official References
- CVE-2022-21296 - NVD entry
- Oracle CPU January 2022 Advisory
- Oracle Java SE Critical Patch Update Advisory
- OWASP XML External Entity (XXE) Prevention Cheat Sheet
- Java JAXP Secure Processing Documentation
Harden your XML processing: Set JAXP features to disallow DTDs and external entities.
3. Review code: Especially in web services, applet/Web Start apps, and anywhere user input is parsed as XML.
4. Deprecate untrusted Java codeways: If possible, move away from dangerous deployment options like applets/Web Start.
Conclusion
CVE-2022-21296 is a classic example of why secure defaults matter and why XML and sandboxed execution remain so hard to get right. A simple misconfiguration or a missed patch can let attackers silently exfiltrate sensitive info—even from “locked down” Java apps.
Stay up-to-date, lock down those XML parsers, and never assume the sandbox will save you!
*If this helped, share with colleagues running Java or GraalVM—these small leaks can lead to big headaches, especially in regulated or multi-user systems.*
Timeline
Published on: 01/19/2022 12:15:00 UTC
Last modified on: 05/10/2022 12:50:00 UTC