CVE-2021-28165: Eclipse Jetty DOS Vulnerability

CVE-2021-28165 Overview

CVE-2021-28165 is a Denial of Service vulnerability affecting Eclipse Jetty, a popular Java-based web server and servlet container. The vulnerability allows remote attackers to cause CPU usage to reach 100% by sending a large invalid TLS frame to affected Jetty instances. This resource exhaustion vulnerability impacts a wide range of versions across multiple Jetty release branches, making it particularly significant for enterprise environments running Java-based web applications.

Critical Impact

Remote attackers can render Jetty-based web services completely unresponsive by sending specially crafted TLS frames, causing complete CPU exhaustion without authentication requirements.

Affected Products

• Eclipse Jetty versions 7.2.2 through 9.4.38
• Eclipse Jetty versions 10.0.0.alpha0 through 10.0.1
• Eclipse Jetty versions 11.0.0.alpha0 through 11.0.1
• Oracle AutoVue for Agile Product Lifecycle Management 21.0.2
• Oracle Communications Cloud Native Core Policy 1.14.0
• Oracle Communications Element Manager 8.2.2
• Oracle Communications Services Gatekeeper 7.0
• Oracle REST Data Services
• Jenkins (LTS and weekly releases)
• NetApp Cloud Manager, SnapCenter, ONTAP Tools
• NetApp E-Series SANtricity products

Discovery Timeline

• April 1, 2021 - CVE-2021-28165 published to NVD
• August 27, 2025 - Last updated in NVD database

Technical Details for CVE-2021-28165

Vulnerability Analysis

This vulnerability exists in Eclipse Jetty's TLS/SSL implementation and is classified under CWE-400 (Uncontrolled Resource Consumption) and CWE-755 (Improper Handling of Exceptional Conditions). When Jetty receives an oversized or malformed TLS frame, the server fails to properly handle the exceptional condition, leading to excessive CPU consumption. The vulnerability can be exploited remotely over the network without requiring any authentication or user interaction, making it particularly dangerous for internet-facing Jetty deployments.

The attack exploits improper handling of TLS frame parsing, where malformed frames trigger resource-intensive processing loops. An attacker can send specially crafted TLS handshake data that causes the server to consume all available CPU resources, effectively denying service to legitimate users.

Root Cause

The root cause stems from improper exception handling in Jetty's SSL/TLS connection processing code. When parsing incoming TLS frames, Jetty failed to implement adequate bounds checking and error handling for malformed or oversized frames. This allows an attacker to send crafted TLS data that triggers inefficient processing paths, consuming disproportionate CPU resources relative to the attacker's bandwidth expenditure.

Attack Vector

The attack vector is network-based, requiring only that an attacker can establish a TCP connection to a Jetty server's HTTPS port. The exploitation process involves:

1. Establishing a TCP connection to the target Jetty server on its TLS-enabled port
2. Sending a specially crafted, oversized, or malformed TLS frame during the handshake phase
3. The server attempts to process the invalid frame, triggering excessive CPU consumption
4. Repeated exploitation can exhaust all server CPU resources, causing denial of service

The attack requires no authentication and can be performed by any network-accessible client. The vulnerability is particularly impactful because a single attacker with limited bandwidth can potentially overwhelm a high-capacity server.

Detection Methods for CVE-2021-28165

Indicators of Compromise

• Unusual CPU spikes on Jetty server processes without corresponding increase in legitimate traffic
• High number of incomplete TLS handshakes from single or multiple source IPs
• Jetty server becoming unresponsive while CPU utilization remains at or near 100%
• Increased connection timeouts reported by legitimate clients

Detection Strategies

• Monitor Jetty process CPU utilization and alert on sustained high usage (>90%) without proportional request throughput
• Implement network intrusion detection rules to identify malformed TLS handshake patterns
• Deploy application performance monitoring to correlate CPU spikes with incoming connection patterns
• Analyze TLS handshake logs for abnormal frame sizes or repeated failed handshakes from specific sources

Monitoring Recommendations

• Configure system monitoring to alert when Jetty Java processes exceed CPU thresholds for extended periods
• Enable Jetty access and error logging with sufficient detail to capture TLS connection anomalies
• Implement rate limiting on new TLS connections at the load balancer or firewall level
• Set up automated health checks that can detect and respond to server unresponsiveness

How to Mitigate CVE-2021-28165

Immediate Actions Required

• Upgrade Eclipse Jetty to version 9.4.39, 10.0.2, or 11.0.2 or later immediately
• Review and update all applications embedding Jetty as a dependency
• Implement network-level rate limiting on incoming TLS connections as a temporary measure
• Consider deploying a Web Application Firewall (WAF) capable of inspecting TLS traffic patterns

Patch Information

Eclipse has released patched versions addressing this vulnerability. Organizations should upgrade to the following minimum versions:

• Jetty 9.4.x: Upgrade to 9.4.39 or later
• Jetty 10.x: Upgrade to 10.0.2 or later
• Jetty 11.x: Upgrade to 11.0.2 or later

For Oracle products, refer to the Oracle Critical Patch Update July 2021, Oracle Critical Patch Update October 2021, and Oracle Critical Patch Update January 2022 advisories for specific patch guidance. NetApp customers should consult the NetApp Security Advisory for affected product updates. Additional details are available in the GitHub Security Advisory GHSA-26vr-8j45-3r4w.

Workarounds

• Deploy network-level connection rate limiting to reduce the effectiveness of DoS attacks targeting this vulnerability
• Configure load balancers to implement TLS termination and connection throttling upstream of Jetty
• Implement CPU resource limits using containerization or process control mechanisms to prevent complete system exhaustion
• Consider temporarily disabling direct TLS on Jetty and offloading TLS termination to a hardened reverse proxy

# Example: Configure connection rate limiting with iptables
# Limit new TLS connections to 20 per second per source IP
iptables -A INPUT -p tcp --dport 8443 -m state --state NEW -m recent --set
iptables -A INPUT -p tcp --dport 8443 -m state --state NEW -m recent --update --seconds 1 --hitcount 20 -j DROP