Miggo Logo

CVE-2025-48988:
Apache Tomcat Multipart Upload Denial of Service Vulnerability

7.5

CVSS Score
3.1

Basic Information

EPSS Score
0.39849%
Published
6/16/2025
Updated
6/16/2025
KEV Status
No
Technology
TechnologyJava

Technical Details

CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Package NameEcosystemVulnerable VersionsFirst Patched Version
org.apache.tomcat:tomcat-catalinamaven>= 11.0.0-M1, <= 11.0.711.0.8
org.apache.tomcat:tomcat-catalinamaven>= 10.1.0-M1, <= 10.1.4110.1.42
org.apache.tomcat:tomcat-catalinamaven>= 9.0.0.M1, <= 9.0.1059.0.106
org.apache.tomcat.embed:tomcat-embed-coremaven>= 11.0.0-M1, <= 11.0.711.0.8
org.apache.tomcat.embed:tomcat-embed-coremaven>= 10.1.0-M1, <= 10.1.4110.1.42
org.apache.tomcat.embed:tomcat-embed-coremaven>= 9.0.0.M1, <= 9.0.1059.0.106

Vulnerability Intelligence
Miggo AIMiggo AI

Miggo AIRoot Cause Analysis

The vulnerability is an 'Allocation of Resources Without Limits or Throttling' issue in Apache Tomcat's multipart upload handling. The provided patches (e.g., 2b0ab14fb55d4edc896e5f1817f2ab76f714ae5e) show modifications primarily in org.apache.catalina.connector.Request.java within the parseParts method and in org.apache.catalina.connector.Connector.java to add new configuration parameters (maxPartCount and maxPartHeaderSize).

The parseParts method in org.apache.catalina.connector.Request is where the actual parsing of multipart request data occurs. Before the patch, the limits on the number of parts were indirectly tied to maxParameterCount, and there was no explicit limit on the size of individual part headers. This lack of fine-grained control allowed a malicious actor to send a multipart request designed to exhaust server resources, leading to a Denial of Service.

The patch modifies parseParts to use two new limits fetched from the Connector: getMaxPartCount() and getMaxPartHeaderSize(). These are used to configure the FileUpload instance (upload.setFileCountMax() and upload.setPartHeaderSizeMax()).

Therefore, the org.apache.catalina.connector.Request.parseParts function is the direct point where the vulnerable processing of multipart data happened due to insufficient resource limiting. During exploitation, this function would be in the call stack as it attempts to parse the excessively large or numerous parts of a malicious request.

Vulnerable functions

org.apache.catalina.connector.Request.parseParts
java/org/apache/catalina/connector/Request.java
The `parseParts` method is responsible for parsing multipart/form-data requests. Prior to the patch, this method did not have separate, adequate limits on the total number of parts or the size of headers for each part. It primarily relied on `maxParameterCount`, which could be bypassed or was insufficient for controlling resource allocation for parts, leading to a potential denial-of-service. An attacker could craft a request with an excessive number of parts or parts with very large headers, consuming server resources. The patch introduces new limits (`maxPartCount` and `maxPartHeaderSize`) that are checked within this function.

WAF Protection Rules

WAF Rule

*llo**tion o* R*sour**s Wit*out Limits or T*rottlin* vuln*r**ility in *p**** Tom**t. T*is issu* *****ts *p**** Tom**t: *rom **.*.*-M* t*rou** **.*.*, *rom **.*.*-M* t*rou** **.*.**, *rom *.*.*.M* t*rou** *.*.***. Us*rs *r* r**omm*n*** to up*r*** to

Reasoning

T** vuln*r**ility is *n '*llo**tion o* R*sour**s Wit*out Limits or T*rottlin*' issu* in *p**** Tom**t's multip*rt uplo** **n*lin*. T** provi*** p*t***s (*.*., ****************************************) s*ow mo*i*i**tions prim*rily in `or*.*p****.**t*l