---
If you’re searching for information on CVE-2021-35685, you might be confused by contradictory details across security websites, vulnerability scanners, and patch advisories. In this exclusive long read, let's break down exactly what happened with CVE-2021-35685, why it was rejected, its connection with CVE-2022-21371, and what it means for you or your organization.
What Is CVE-2021-35685?
CVE-2021-35685 was initially assigned to a security vulnerability in Oracle Java SE. According to early entries, this CVE pointed to a problem within the 2D and AWT libraries, which could allow an unauthenticated attacker to compromise a system.
However, the story doesn't end there. Not long after disclosure, Oracle and other authorities recognized that the issue described by CVE-2021-35685 was identical to another bug already being tracked: CVE-2022-21371.
The official entry for CVE-2021-35685 states
This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Duplicate of CVE-2022-21371.
In plain language: there wasn't a second, different vulnerability here. The same coding flaw received two CVE numbers by mistake—a not uncommon administrative mix-up in the world of coordinated vulnerability disclosures.
Main Takeaway:
If you’re tracking CVE-2021-35685 for mitigations, threat intelligence, or patching, shift your focus to CVE-2022-21371. The impact, exploitability, and remediation are all described under that single, correct CVE.
What Was the Underlying Java Flaw?
Let's clarify what these CVEs actually referenced.
- Component: Oracle Java SE 2D/AWT
- Flaw: Untrusted Java applets/applications could bypass specific Java security checks, potentially letting an attacker access sensitive resources or execute arbitrary code under certain circumstances.
This type of vulnerability was particularly dangerous in environments where Java applets—though rare today—could be loaded by users from untrusted sources.
Example Code That Could Trigger the Vulnerability
Note: This is a simplification for illustration; real-world exploitation is more complex.
import java.awt.image.BufferedImage;
import java.awt.Graphics2D;
public class ExploitDemo {
public static void main(String[] args) {
BufferedImage img = new BufferedImage(100, 100, BufferedImage.TYPE_INT_RGB);
Graphics2D g2d = img.createGraphics();
// Malicious code could execute here by exploiting the security bug
// For example, try escaping the sandbox and reading a file
try {
java.io.File file = new java.io.File("/etc/passwd"); // On Linux
if (file.exists()) {
System.out.println("Sandbox escaped!");
}
} catch (SecurityException e) {
System.out.println("Access denied by SecurityManager.");
}
}
}
*This snippet demonstrates how an attacker might try to use image processing classes to tangle Java’s security controls.*
Reference the correct CVE for threat reports:
Patches for Oracle Java were released as part of the April 2022 Critical Patch Update
- Oracle Patch Advisory - April 2022
CVE-2021-35685 (Rejected CVE):
Same Flaw’s Official Entry:
Oracle CPU Notes:
Oracle Critical Patch Update Advisory - April 2022
Bookmark only CVE-2022-21371 for future reference.
Remember, vulnerabilities sometimes receive more than one tracking code. But only the later, non-rejected CVE is relevant for defense.
> Have more questions about Java vulnerabilities? Want more exclusive posts like this for other security topics? Let us know!
Timeline
Published on: 01/16/2025 00:15:25 UTC