CVE-2023-26048 in Communications Cloud Native Core Security Edge Protection Proxy
Summary
by MITRE • 04/19/2023
Jetty is a java based web server and servlet engine. In affected versions servlets with multipart support (e.g. annotated with `@MultipartConfig`) that call `HttpServletRequest.getParameter()` or `HttpServletRequest.getParts()` may cause `OutOfMemoryError` when the client sends a multipart request with a part that has a name but no filename and very large content. This happens even with the default settings of `fileSizeThreshold=0` which should stream the whole part content to disk. An attacker client may send a large multipart request and cause the server to throw `OutOfMemoryError`. However, the server may be able to recover after the `OutOfMemoryError` and continue its service -- although it may take some time. This issue has been patched in versions 9.4.51, 10.0.14, and 11.0.14. Users are advised to upgrade. Users unable to upgrade may set the multipart parameter `maxRequestSize` which must be set to a non-negative value, so the whole multipart content is limited (although still read into memory).
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 11/08/2023
The vulnerability identified as CVE-2023-26048 affects the Jetty web server and servlet engine, specifically targeting applications that utilize multipart servlet functionality. This issue manifests when servlets annotated with @MultipartConfig process multipart requests containing parts with names but no filenames, combined with exceptionally large content payloads. The flaw represents a classic resource exhaustion vulnerability that exploits the server's handling of multipart data processing, where the default file size threshold setting of zero fails to properly stream large content to disk as intended. The vulnerability operates through a memory management failure in the multipart request parsing logic, creating conditions where the server attempts to load excessive amounts of data into heap memory rather than properly managing disk-based storage for large file uploads.
The technical implementation of this vulnerability stems from the improper handling of multipart request parts that lack filenames while maintaining substantial content sizes. When HttpServletRequest.getParameter() or HttpServletRequest.getParts() methods are invoked on such requests, the Jetty server's multipart processing engine attempts to buffer the entire part content in memory regardless of the fileSizeThreshold setting. This behavior violates the expected memory management principles where zero threshold values should trigger immediate disk streaming for large content. The vulnerability classifies under CWE-400 as an Uncontrolled Resource Consumption, specifically manifesting as an OutOfMemoryError condition that occurs during request processing rather than during application startup or initialization phases.
From an operational impact perspective, this vulnerability presents a significant denial of service risk to affected Jetty deployments, particularly those handling file upload functionality. Attackers can craft malicious multipart requests that trigger memory exhaustion, potentially causing server instability and service disruption. The recovery mechanism post-OutOfMemoryError demonstrates that while the server may continue operating, there is a period of service degradation during which the application must recover from the memory exception. This characteristic makes the vulnerability particularly dangerous in production environments where continuous availability is critical, as the recovery period may be unpredictable and could provide extended service interruption windows. The ATT&CK framework categorizes this under T1499.004 for Network Denial of Service, with potential for escalation to T1566.001 for Initial Access through crafted malicious uploads.
The mitigation strategies for this vulnerability encompass both immediate and long-term approaches. The primary recommended solution involves upgrading to patched versions 9.4.51, 10.0.14, or 11.0.14, which implement proper memory management for multipart processing. For organizations unable to perform immediate upgrades, administrators can implement the maxRequestSize parameter configuration to limit overall multipart content size, though this approach still requires reading content into memory before applying size limits. Additional protective measures include implementing rate limiting for file upload endpoints, monitoring for unusual multipart request patterns, and configuring appropriate JVM memory settings to better handle potential memory spikes. The vulnerability highlights the importance of proper resource management in web application servers and demonstrates how seemingly benign configuration parameters can lead to critical security flaws when not properly validated against large data inputs. Organizations should conduct thorough testing of their multipart handling code paths to ensure proper memory usage patterns are maintained across all supported Jetty versions and configurations.