CVE-2024-22201: Eclipse Jetty HTTP/2 DoS Vulnerability

CVE-2024-22201 Overview

CVE-2024-22201 is a resource exhaustion vulnerability in Eclipse Jetty, a Java-based web server and servlet engine widely used in enterprise applications and embedded systems. The vulnerability exists in the handling of HTTP/2 SSL connections under TCP congestion conditions, where connections are improperly leaked when they time out.

An attacker can exploit this vulnerability by establishing multiple HTTP/2 SSL connections to a vulnerable Jetty server and inducing TCP congestion. As connections time out under these conditions, they are not properly released, leading to file descriptor exhaustion. This can ultimately cause the server to stop accepting new connections from legitimate clients, resulting in a denial of service condition.

Critical Impact

Successful exploitation allows remote attackers to cause denial of service by exhausting server file descriptors, preventing legitimate client connections without requiring authentication.

Affected Products

• Eclipse Jetty versions prior to 9.4.54, 10.0.20, 11.0.20, and 12.0.6
• Debian Linux 10.0
• NetApp Active IQ Unified Manager (Linux and Windows)
• NetApp BlueXP

Discovery Timeline

• 2024-02-26 - CVE-2024-22201 published to NVD
• 2025-02-13 - Last updated in NVD database

Technical Details for CVE-2024-22201

Vulnerability Analysis

This vulnerability is classified under CWE-400 (Uncontrolled Resource Consumption) and CWE-770 (Allocation of Resources Without Limits or Throttling). The flaw resides in how Jetty manages HTTP/2 SSL connections during network congestion scenarios.

When an HTTP/2 SSL connection is established and the underlying TCP connection becomes congested, the connection handling code fails to properly clean up resources upon connection timeout. Each leaked connection consumes a file descriptor, and since operating systems impose limits on the number of file descriptors a process can hold, an attacker can systematically exhaust this resource.

The attack requires network access to the vulnerable Jetty server but does not require any authentication or user interaction. The impact is limited to availability—there is no confidentiality or integrity breach, but the denial of service can be significant for production systems.

Root Cause

The root cause lies in the improper resource lifecycle management within Jetty's HTTP/2 implementation. When TCP congestion occurs on an SSL connection and the connection subsequently times out, the code path responsible for connection cleanup does not execute properly. This results in the connection resources, particularly file descriptors, remaining allocated even though the connection is no longer usable.

The issue specifically affects the interaction between the HTTP/2 protocol implementation, SSL/TLS layer, and TCP connection timeout handling. Under normal conditions, connection timeouts trigger proper resource cleanup, but the combination of HTTP/2, SSL, and TCP congestion creates an edge case where this cleanup is bypassed.

Attack Vector

The attack can be executed remotely over the network by any unauthenticated attacker with network access to the target Jetty server. The attack methodology involves:

1. Establishing multiple HTTP/2 SSL connections to the target server
2. Inducing TCP congestion on these connections (through slow-read attacks, bandwidth saturation, or other network manipulation techniques)
3. Waiting for the connections to timeout while congested
4. Repeating the process until the server's file descriptor limit is exhausted

The attack does not require special privileges, user interaction, or valid credentials. The attacker simply needs to be able to initiate network connections to the vulnerable server. Once file descriptors are exhausted, the server cannot accept new connections from any client, effectively denying service to all users.

Technical details about the vulnerability mechanism can be found in the GitHub Jetty Issue #11256 and the GitHub Jetty Security Advisory.

Detection Methods for CVE-2024-22201

Indicators of Compromise

• Abnormally high number of file descriptors consumed by the Jetty process
• Increasing count of stale or orphaned HTTP/2 SSL connections in server metrics
• Server logs showing connection timeout errors during periods of high TCP congestion
• Legitimate client connections being refused with "too many open files" errors

Detection Strategies

• Monitor file descriptor usage for Jetty processes and alert on approaching system limits
• Implement network traffic analysis to detect patterns consistent with slow-read or congestion-inducing attacks
• Track HTTP/2 connection lifecycle metrics to identify connections that timeout without proper cleanup
• Deploy SentinelOne Singularity Platform to detect anomalous resource consumption patterns indicative of DoS attacks

Monitoring Recommendations

• Configure system-level monitoring for file descriptor usage with alerts at 70%, 85%, and 95% thresholds
• Implement Jetty-specific metrics collection for HTTP/2 connection states and SSL session tracking
• Monitor network interface congestion metrics to correlate with connection leaks
• Set up log aggregation to detect patterns of connection timeouts under congestion conditions

How to Mitigate CVE-2024-22201

Immediate Actions Required

• Upgrade Eclipse Jetty to patched versions: 9.4.54, 10.0.20, 11.0.20, or 12.0.6 or later
• Review and potentially increase system file descriptor limits as a temporary measure while planning upgrades
• Consider implementing connection rate limiting at the load balancer or firewall level
• Monitor file descriptor consumption actively until patches are applied

Patch Information

Eclipse has released patches addressing this vulnerability in the following versions:

Detailed patch information and security advisory are available at the GitHub Jetty Security Advisory. For NetApp products, refer to the NetApp Security Advisory NTAP-20240329-0001. Debian users should consult the Debian LTS Announcement.

Workarounds

• Implement network-level rate limiting to prevent rapid connection establishment from single sources
• Configure firewall rules to limit the number of concurrent connections from individual IP addresses
• Increase operating system file descriptor limits to provide additional headroom (temporary mitigation only)
• Consider disabling HTTP/2 support if not required for your deployment until patches can be applied

# Configuration example - Increase file descriptor limits (temporary mitigation)
# Add to /etc/security/limits.conf
jetty_user soft nofile 65535
jetty_user hard nofile 65535

# Verify current limits for the Jetty process
cat /proc/$(pgrep -f jetty)/limits | grep "Max open files"

# Monitor file descriptor usage
watch -n 5 'ls -la /proc/$(pgrep -f jetty)/fd | wc -l'