CVE-2023-26048: Eclipse Jetty DOS Vulnerability

CVE-2023-26048 Overview

CVE-2023-26048 is a resource exhaustion vulnerability in Eclipse Jetty, a popular Java-based web server and servlet engine. The vulnerability affects servlets with multipart support (e.g., annotated with @MultipartConfig) that call HttpServletRequest.getParameter() or HttpServletRequest.getParts(). When a client sends a malicious multipart request containing a part with a name but no filename and very large content, the server can throw an OutOfMemoryError, leading to a denial of service condition.

This vulnerability is particularly concerning because it occurs even with the default settings of fileSizeThreshold=0, which should stream the entire part content to disk rather than holding it in memory. The improper handling of multipart requests allows an attacker to exhaust server memory resources without proper file-based streaming.

Critical Impact

Remote attackers can cause server-side OutOfMemoryError conditions by sending specially crafted multipart requests, potentially disrupting service availability for legitimate users.

Affected Products

• Eclipse Jetty versions prior to 9.4.51
• Eclipse Jetty versions 10.x prior to 10.0.14
• Eclipse Jetty versions 11.x prior to 11.0.14

Discovery Timeline

• 2023-04-18 - CVE-2023-26048 published to NVD
• 2024-11-21 - Last updated in NVD database

Technical Details for CVE-2023-26048

Vulnerability Analysis

The vulnerability resides in how Eclipse Jetty handles multipart form data uploads. When servlets are configured to handle multipart content using the @MultipartConfig annotation, they process incoming multipart HTTP requests through the HttpServletRequest.getParameter() or HttpServletRequest.getParts() methods.

Under normal circumstances, when the fileSizeThreshold parameter is set to 0 (the default), the servlet engine should stream large content directly to disk storage. However, a flaw in Jetty's multipart parsing logic causes it to load the entire content of a multipart part into memory when that part has a name but lacks a filename attribute.

This behavior deviates from the expected streaming behavior defined in the Jakarta Servlet Specification Document, allowing attackers to craft requests that bypass the disk-based storage mechanism entirely.

Root Cause

The root cause is classified under CWE-400 (Uncontrolled Resource Consumption) and CWE-770 (Allocation of Resources Without Limits or Throttling). The multipart parsing implementation fails to properly enforce memory limits when processing parts that have names but no filenames, regardless of the configured fileSizeThreshold setting.

When a multipart part contains only a name attribute without a filename, Jetty's parser incorrectly treats the content as form data rather than file data, causing it to buffer the entire content in heap memory. This bypasses the streaming-to-disk mechanism that protects against memory exhaustion.

Attack Vector

The attack is network-based and requires no authentication or user interaction. An attacker can exploit this vulnerability by sending a crafted HTTP multipart request with:

1. A multipart boundary containing a part definition with a name attribute
2. No filename attribute in the Content-Disposition header
3. An extremely large body content for that part

The malicious request would look similar to a standard multipart form submission but with an abnormally large data payload in a named part without a filename. When the servlet attempts to process this request using getParameter() or getParts(), Jetty attempts to load the entire content into memory, potentially causing an OutOfMemoryError.

While the server may recover after the error and continue service, repeated attacks can cause sustained service disruption. The vulnerability requires only basic HTTP client capabilities to exploit and can be launched remotely across the network.

Detection Methods for CVE-2023-26048

Indicators of Compromise

• Unusual OutOfMemoryError exceptions in Jetty server logs, particularly those associated with multipart request processing
• Abnormally large HTTP POST requests with Content-Type: multipart/form-data headers
• Repeated requests from single IP addresses containing multipart data with named parts but no filename attributes
• Sudden spikes in JVM heap memory usage during multipart request processing

Detection Strategies

• Monitor Jetty access logs for HTTP POST requests with unusually large Content-Length headers targeting endpoints that handle multipart data
• Implement application-level logging to track multipart request processing times and memory allocation patterns
• Deploy network-level inspection to identify HTTP requests with multipart boundaries containing extremely large individual parts
• Configure JVM monitoring to alert on rapid heap memory growth and garbage collection anomalies

Monitoring Recommendations

• Set up heap memory utilization alerts with thresholds appropriate for your server's configuration
• Monitor garbage collection frequency and duration for anomalous patterns indicating memory pressure
• Track request processing times for multipart endpoints to identify potential exploitation attempts
• Implement rate limiting on endpoints that accept multipart form data to mitigate sustained attacks

How to Mitigate CVE-2023-26048

Immediate Actions Required

• Upgrade Eclipse Jetty to version 9.4.51, 10.0.14, or 11.0.14 or later immediately
• Review application code for servlets using @MultipartConfig annotation and assess exposure
• Implement the maxRequestSize workaround on affected systems if immediate patching is not possible
• Configure web application firewalls to limit the size of incoming multipart requests

Patch Information

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

• Jetty 9.4.x: Upgrade to version 9.4.51 or later
• Jetty 10.0.x: Upgrade to version 10.0.14 or later
• Jetty 11.0.x: Upgrade to version 11.0.14 or later

Technical details of the fix can be found in GitHub Pull Request #9344 and GitHub Pull Request #9345. The GitHub Security Advisory GHSA-qw69-rqj8-6qw8 provides additional context and mitigation guidance.

Debian users should refer to Debian Security Advisory DSA-5507 and Debian LTS Announcement #00039 for distribution-specific patches. NetApp users can find additional guidance at NetApp Security Advisory NTAP-20230526-0001.

Workarounds

• Set the maxRequestSize multipart parameter to a non-negative value to limit total multipart content size (note: content is still read into memory with this workaround)
• Implement reverse proxy request size limits using tools like nginx or Apache HTTP Server upstream of Jetty
• Deploy web application firewall rules to inspect and limit multipart request sizes before they reach the application
• Consider temporarily disabling multipart endpoints that are not business-critical until patching can be completed

# Configuration example for Jetty multipart limits
# In web.xml or programmatic configuration, set maxRequestSize

# Example web.xml multipart-config:
# <multipart-config>
#   <max-file-size>10485760</max-file-size>
#   <max-request-size>20971520</max-request-size>
#   <file-size-threshold>0</file-size-threshold>
# </multipart-config>

# For nginx reverse proxy, add request body size limits:
# client_max_body_size 20m;