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:

Establishing a TCP connection to the target Jetty server on its TLS-enabled port
Sending a specially crafted, oversized, or malformed TLS frame during the handshake phase
The server attempts to process the invalid frame, triggering excessive CPU consumption
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

bash

# 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