CVE-2024-20921: Oracle GraalVM Privilege Escalation Flaw

CVE-2024-20921 Overview

CVE-2024-20921 affects the Hotspot component of Oracle Java SE, Oracle GraalVM for JDK, and Oracle GraalVM Enterprise Edition. The flaw allows an unauthenticated attacker with network access to compromise confidentiality through multiple protocols. Successful exploitation grants unauthorized access to critical data across all accessible Java SE and GraalVM instances.

The vulnerability is mapped to [CWE-276] Incorrect Default Permissions. It applies to server deployments processing untrusted data via APIs and to sandboxed Java Web Start applications and Java applets that execute untrusted code. Oracle addressed the issue in its January 2024 Critical Patch Update.

Critical Impact

Remote unauthenticated attackers can extract confidential data from Java workloads exposed via APIs or web services, with no user interaction required.

Affected Products

• Oracle Java SE: 8u391, 8u391-perf, 11.0.21, 17.0.9, 21.0.1
• Oracle GraalVM for JDK: 17.0.9, 21.0.1
• Oracle GraalVM Enterprise Edition: 20.3.12, 21.3.8, 22.3.4

Discovery Timeline

• 2024-02-17 - CVE-2024-20921 published to NVD
• 2024-01 - Oracle releases fix in the Oracle Critical Patch Update Advisory - January 2024
• 2025-11-04 - Last updated in NVD database

Technical Details for CVE-2024-20921

Vulnerability Analysis

The vulnerability resides in the Hotspot virtual machine, the runtime engine responsible for bytecode execution, just-in-time (JIT) compilation, and memory management within Oracle Java SE and GraalVM distributions. The flaw permits an unauthenticated network attacker to access confidential data processed by the Java runtime.

Exploitation difficulty is high, requiring specific conditions to be met. The attack impacts confidentiality only, with no integrity or availability consequences. The EPSS score sits at 0.22%, indicating a low observed probability of exploitation in the wild.

The vulnerability is mapped to [CWE-276] Incorrect Default Permissions. The Hotspot component fails to enforce appropriate access boundaries on certain data structures, exposing sensitive runtime information when invoked through specific code paths.

Root Cause

The root cause is improper default permissions within the Hotspot runtime, allowing access to data that should remain isolated. Java's sandbox model relies on Hotspot to enforce class loading and memory access restrictions. When defaults are too permissive, untrusted code or crafted inputs can bypass these controls and read protected memory regions.

Attack Vector

The vulnerability is exploitable through multiple network protocols. Two scenarios apply:

• Server-side exploitation: Attackers supply malicious data to APIs exposed by Java services, for example through a web service that forwards input to the vulnerable Hotspot code paths.
• Client-side exploitation: Sandboxed Java Web Start applications or Java applets load untrusted code from the internet and rely on the Java sandbox for security boundaries.

No authentication or user interaction is required. The vulnerability does not permit code execution or data modification, limiting impact to disclosure of confidential information.

No public proof-of-concept code has been published, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog.

Detection Methods for CVE-2024-20921

Indicators of Compromise

• Java processes (java.exe, java) running vulnerable versions identified through java -version output matching the affected releases.
• Anomalous outbound traffic from Java application servers to unrecognized destinations following deserialization or API request bursts.
• Unexpected access to JVM memory regions by Java Web Start (javaws) or applet processes loading remote JAR files.

Detection Strategies

• Inventory all hosts running affected JDK, JRE, and GraalVM versions using software asset management or endpoint telemetry queries.
• Monitor Java web services for unusual API call patterns, particularly endpoints accepting serialized objects or complex inputs forwarded to JVM internals.
• Inspect application logs for repeated requests targeting the same API endpoint without successful authentication, indicating reconnaissance against exposed services.

Monitoring Recommendations

• Enable verbose JVM logging on production Java workloads to capture unexpected class loading or reflection activity.
• Correlate network traffic to Java service ports with process telemetry to identify exploitation attempts originating from external sources.
• Track Java Web Start and applet executions on user endpoints, prioritizing systems that still allow browser-launched Java content.

How to Mitigate CVE-2024-20921

Immediate Actions Required

• Apply the Oracle January 2024 Critical Patch Update to all affected Java SE, GraalVM for JDK, and GraalVM Enterprise Edition installations.
• Upgrade Oracle Java SE to a release later than 8u391, 11.0.21, 17.0.9, or 21.0.1 as published in the patch advisory.
• Disable Java Web Start and applet support on endpoints that do not require legacy Java browser content.
• Restrict network access to Java application APIs through firewall rules and Web Application Firewall (WAF) policies.

Patch Information

Oracle published fixes in the Oracle Critical Patch Update Advisory - January 2024. NetApp products bundling affected Java versions are tracked in the NetApp Advisory NTAP-20240201-0002 and NetApp Advisory NTAP-20241108-0002. Administrators should upgrade to the patched releases identified in those advisories.

Workarounds

• Limit exposure of Java-based web services to trusted networks only, blocking direct internet access where possible.
• Run Java workloads under least-privilege service accounts to reduce the scope of data accessible if exploitation occurs.
• Remove Java Web Start runtimes from systems where they are no longer required, eliminating the client-side attack surface entirely.

# Verify installed Java version on Linux/macOS hosts
java -version 2>&1 | grep -E "1\.8\.0_391|11\.0\.21|17\.0\.9|21\.0\.1"

# Windows PowerShell inventory query
Get-WmiObject -Class Win32_Product | Where-Object {$_.Name -like "*Java*" -or $_.Name -like "*GraalVM*"} | Select-Object Name, Version