CVE-2026-22021: Oracle Java SE JSSE DoS Vulnerability

CVE-2026-22021 Overview

CVE-2026-22021 is a denial of service vulnerability affecting the JSSE (Java Secure Socket Extension) component in Oracle Java SE, Oracle GraalVM for JDK, and Oracle GraalVM Enterprise Edition. The vulnerability allows an unauthenticated attacker with network access via HTTPS to cause a partial denial of service condition. This flaw is classified as CWE-400 (Uncontrolled Resource Consumption), indicating that the vulnerability stems from improper handling of resources within the JSSE component.

The vulnerability is easily exploitable and can be triggered through APIs in the JSSE component, including through web services that supply data to these APIs. Additionally, this vulnerability affects Java deployments running sandboxed Java Web Start applications or sandboxed Java applets that load and execute untrusted code from the internet.

Critical Impact

Unauthenticated attackers can remotely cause partial denial of service on affected Java deployments via HTTPS without user interaction.

Affected Products

• Oracle Java SE: 8u481, 8u481-b50, 8u481-perf, 11.0.30, 17.0.18, 21.0.10, 25.0.2, 26
• Oracle GraalVM for JDK: 17.0.18 and 21.0.10
• Oracle GraalVM Enterprise Edition: 21.3.17

Discovery Timeline

• April 21, 2026 - CVE-2026-22021 published to NVD
• April 22, 2026 - Last updated in NVD database

Technical Details for CVE-2026-22021

Vulnerability Analysis

This vulnerability resides in the JSSE component, which is responsible for implementing Java's Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols. The flaw enables an unauthenticated attacker to consume excessive resources within the affected Java runtime, leading to degraded service availability.

The vulnerability requires no privileges or user interaction to exploit, making it accessible to any attacker with network connectivity to the target system. While the impact is limited to availability (partial denial of service) without affecting confidentiality or integrity, the ease of exploitation and lack of authentication requirements make this a notable concern for internet-facing Java applications.

The root cause is classified as CWE-400 (Uncontrolled Resource Consumption), indicating that the JSSE component fails to properly limit resource allocation when processing certain HTTPS requests or TLS handshakes.

Root Cause

The vulnerability stems from uncontrolled resource consumption (CWE-400) within the JSSE component. When processing certain HTTPS connections or TLS-related operations, the component does not adequately constrain resource usage, allowing an attacker to exhaust available resources and degrade service availability. This type of vulnerability typically occurs when input validation or resource limiting mechanisms are insufficient to handle maliciously crafted requests.

Attack Vector

The attack vector is network-based, requiring an attacker to send specially crafted HTTPS requests to a vulnerable Java application. The attack can be executed through:

1. Direct HTTPS connections to web services built on affected Java versions
2. API endpoints that process TLS/SSL data through the JSSE component
3. Java Web Start applications or Java applets loading untrusted code that leverages the vulnerable component

The exploitation is straightforward with no authentication required. An attacker can trigger resource exhaustion by sending malformed or excessive TLS/SSL data to the target application, causing partial service degradation.

The vulnerability manifests during HTTPS/TLS processing within the JSSE component. Attackers can send specially crafted network requests that trigger excessive resource consumption. For detailed technical information, refer to the Oracle Security Alert April 2026.

Detection Methods for CVE-2026-22021

Indicators of Compromise

• Abnormal increase in HTTPS connection attempts from single or multiple source IPs
• Elevated CPU or memory usage in Java processes handling TLS/SSL connections
• Increased latency or timeouts in HTTPS-based services without corresponding traffic increases
• Java application logs showing unusual patterns in SSL/TLS handshake operations

Detection Strategies

• Monitor Java Virtual Machine metrics for unexpected resource consumption spikes during HTTPS processing
• Implement network-level monitoring for anomalous HTTPS connection patterns and incomplete TLS handshakes
• Deploy application performance monitoring (APM) to track JSSE component behavior and resource utilization
• Use SentinelOne Singularity platform to detect abnormal Java process behavior indicative of resource exhaustion attacks

Monitoring Recommendations

• Configure alerting thresholds for Java heap memory and CPU utilization on systems running affected versions
• Monitor network traffic for unusual volumes of HTTPS requests targeting Java-based services
• Review application logs for SSL/TLS errors or connection anomalies that may indicate exploitation attempts
• Implement rate limiting on HTTPS endpoints to mitigate potential denial of service attempts

How to Mitigate CVE-2026-22021

Immediate Actions Required

• Inventory all systems running affected Oracle Java SE, GraalVM for JDK, and GraalVM Enterprise Edition versions
• Apply the latest security patches from Oracle's April 2026 Critical Patch Update immediately
• Implement network-level rate limiting on HTTPS endpoints to reduce exploitation risk
• Consider temporarily restricting network access to critical Java-based services if patching cannot be performed immediately

Patch Information

Oracle has addressed this vulnerability in the April 2026 Critical Patch Update (CPU). Organizations should apply the appropriate patches for their Java distributions:

• Oracle Java SE: Update to the latest patched version available in the April 2026 CPU
• Oracle GraalVM for JDK: Update versions 17.0.18 and 21.0.10 to the patched releases
• Oracle GraalVM Enterprise Edition: Update version 21.3.17 to the patched release

For complete patch details and download links, refer to the Oracle Security Alert April 2026.

Workarounds

• Implement Web Application Firewall (WAF) rules to filter potentially malicious HTTPS traffic targeting Java applications
• Configure connection timeouts and resource limits at the application server level to minimize denial of service impact
• Deploy network-based rate limiting to throttle excessive HTTPS connection attempts
• For sandboxed Java applets or Web Start applications, consider disabling execution of untrusted code until patches are applied

# Configuration example - Rate limiting HTTPS connections (example using iptables)
# Limit new HTTPS connections to 25 per second per source IP
iptables -A INPUT -p tcp --dport 443 -m conntrack --ctstate NEW -m limit --limit 25/second --limit-burst 100 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -m conntrack --ctstate NEW -j DROP