VYPR
← All advisories
High severityNVD Advisory· Published Jul 10, 2025· Updated Nov 4, 2025

Apache Tomcat: DoS via integer overflow in multipart file upload

CVE-2025-52520

Description

For some unlikely configurations of multipart upload, an Integer Overflow vulnerability in Apache Tomcat could lead to a DoS via bypassing of size limits.

This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.8, from 10.1.0-M1 through 10.1.42, from 9.0.0.M1 through 9.0.106. The following versions were EOL at the time the CVE was created but are known to be affected: 8.5.0 through 8.5.100. Other, older, EOL versions may also be affected.

Users are recommended to upgrade to version 11.0.9, 10.1.43 or 9.0.107, which fix the issue.

AI Insight

LLM-synthesized narrative grounded in this CVE's description and references.

Integer overflow in Apache Tomcat's multipart upload size tracking can bypass configured limits, leading to Denial of Service under specific uncommon configurations.

CVE-2025-52520 is an integer overflow vulnerability in Apache Tomcat affecting the calculation of request size limits during multipart file upload processing. The root cause is a mismatch between the size tracking variable used by Tomcat (int) and the Jakarta Commons FileUpload library (long). When very large non-file parts are uploaded, the size increment can overflow a 32-bit integer, causing the total to wrap to a small value and bypass the configured maxPostSize limit. [1][3]

Exploitation requires an unlikely configuration where multipart upload is enabled and the application processes large form fields or other non-file parts alongside file uploads. The attacker can craft a multipart request with non-file parts whose combined byte size exceeds the integer overflow threshold. This bypasses the size check, potentially allowing the server to allocate excessive memory or CPU resources, leading to denial of service. [3]

The impact is limited to denial of service; the vulnerability does not expose stored data or lead to remote code execution. An attacker could cause an unresponsive or crashed server by sending specially crafted multipart requests that exhaust server resources. The vulnerability affects Apache Tomcat versions 11.0.0-M1 through 11.0.8, 10.1.0-M1 through 10.1.42, 9.0.0.M1 through 9.0.106, and known EOL versions 8.5.0 through 8.5.100. [1][3]

Mitigation requires upgrading to Tomcat 11.0.9, 10.1.43, or 9.0.107, which include a fix that aligns the size tracking variable by using long arithmetic and Math.addExact to prevent overflow. No workaround is provided for older affected versions. The vulnerability was reported by Saravana Kumar and assigned a low severity. [3][4]

References
  1. NVD - CVE-2025-52520
  2. security - CVE-2025-52520: Apache Tomcat: DoS via integer overflow in multipart file upload
  3. Align size tracking for multipart requests with FileUpload's use of long · apache/tomcat@a51e4be

AI Insight generated on May 19, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.

Affected packages

Versions sourced from the GitHub Security Advisory.

PackageAffected versionsPatched versions
org.apache.tomcat:tomcat-catalinaMaven
>= 11.0.0-M1, < 11.0.911.0.9
org.apache.tomcat:tomcat-catalinaMaven
>= 10.1.0-M1, < 10.1.4310.1.43
org.apache.tomcat:tomcat-catalinaMaven
>= 9.0.0.M1, < 9.0.1079.0.107
org.apache.tomcat:tomcat-catalinaMaven
>= 8.5.0, <= 8.5.100—
org.apache.tomcat.embed:tomcat-embed-coreMaven
>= 11.0.0-M1, < 11.0.911.0.9
org.apache.tomcat.embed:tomcat-embed-coreMaven
>= 10.1.0-M1, < 10.1.4310.1.43
org.apache.tomcat.embed:tomcat-embed-coreMaven
>= 9.0.0.M1, < 9.0.1079.0.107
org.apache.tomcat.embed:tomcat-embed-coreMaven
>= 8.5.0, <= 8.5.100—

Affected products

2
  • Apache/Tomcatllm-fuzzy
    Range: < 9.0.107 || >= 10.1.0-M1 < 10.1.43 || >= 11.0.0-M1 < 11.0.9
  • Apache Software Foundation/Apache Tomcatv5
    Range: 11.0.0-M1

Patches

3
927d66fbc294

Align size tracking for multipart requests with FileUpload's use of long

https://github.com/apache/tomcatMark ThomasJul 1, 2025via ghsa
commit
2 files changed · +11 −6
  • java/org/apache/catalina/connector/Request.java+7 −6 modified
    @@ -2715,23 +2715,23 @@ private void parseParts(boolean explicit) {
             try {
                 List<FileItem> items = upload.parseRequest(new ServletRequestContext(this));
                 int maxPostSize = getConnector().getMaxPostSize();
-                int postSize = 0;
+                long postSize = 0;
                 Charset charset = getCharset();
                 for (FileItem item : items) {
                     ApplicationPart part = new ApplicationPart(item, location);
-                    parts.add(part);
                     if (part.getSubmittedFileName() == null) {
                         String name = part.getName();
                         if (maxPostSize >= 0) {
                             // Have to calculate equivalent size. Not completely
                             // accurate but close enough.
-                            postSize += name.getBytes(charset).length;
+                            // Name
+                            postSize = Math.addExact(postSize, name.getBytes(charset).length);
                             // Equals sign
-                            postSize++;
+                            postSize = Math.addExact(postSize, 1);
                             // Value length
-                            postSize += part.getSize();
+                            postSize = Math.addExact(postSize, part.getSize());
                             // Value separator
-                            postSize++;
+                            postSize = Math.addExact(postSize, 1);
                             if (postSize > maxPostSize) {
                                 parameters.setParseFailedReason(FailReason.POST_TOO_LARGE);
                                 throw new IllegalStateException(sm.getString("coyoteRequest.maxPostSizeExceeded"));
@@ -2748,6 +2748,7 @@ private void parseParts(boolean explicit) {
                         // Adjust the limit to account for a file part which is not added to the parameter map.
                         maxParameterCount--;
                     }
+                    parts.add(part);
                 }
 
                 success = true;
  • webapps/docs/changelog.xml+4 −0 modified
    @@ -128,6 +128,10 @@
         multipart uploads with non-file parts when the parts were processed
         before query string parameters. (markt)
       </fix>
+      <fix>
+        Align size tracking for multipart requests with FileUpload's use of
+        <code>long</code>. (schultz)
+      </fix>
     </changelog>
   </subsection>
   <subsection name="Coyote">
a51e4bedccfa

Align size tracking for multipart requests with FileUpload's use of long

https://github.com/apache/tomcatMark ThomasJul 1, 2025via ghsa
commit
2 files changed · +11 −6
  • java/org/apache/catalina/connector/Request.java+7 −6 modified
    @@ -2575,23 +2575,23 @@ private void parseParts(boolean explicit) {
         try {
             List<FileItem> items = upload.parseRequest(new ServletRequestContext(this));
             int maxPostSize = getConnector().getMaxPostSize();
-            int postSize = 0;
+            long postSize = 0;
             Charset charset = getCharset();
             for (FileItem item : items) {
                 ApplicationPart part = new ApplicationPart(item, location);
-                parts.add(part);
                 if (part.getSubmittedFileName() == null) {
                     String name = part.getName();
                     if (maxPostSize >= 0) {
                         // Have to calculate equivalent size. Not completely
                         // accurate but close enough.
-                        postSize += name.getBytes(charset).length;
+                        // Name
+                        postSize = Math.addExact(postSize, name.getBytes(charset).length);
                         // Equals sign
-                        postSize++;
+                        postSize = Math.addExact(postSize, 1);
                         // Value length
-                        postSize += (int) part.getSize();
+                        postSize = Math.addExact(postSize, part.getSize());
                         // Value separator
-                        postSize++;
+                        postSize = Math.addExact(postSize, 1);
                         if (postSize > maxPostSize) {
                             throw new IllegalStateException(sm.getString("coyoteRequest.maxPostSizeExceeded"));
                         }
@@ -2607,6 +2607,7 @@ private void parseParts(boolean explicit) {
                     // Adjust the limit to account for a file part which is not added to the parameter map.
                     maxParameterCount--;
                 }
+                parts.add(part);
             }
         } catch (InvalidContentTypeException e) {
             partsParseException = new ServletException(e);
  • webapps/docs/changelog.xml+4 −0 modified
    @@ -132,6 +132,10 @@
         multipart uploads with non-file parts when the parts were processed
         before query string parameters. (markt)
       </fix>
+      <fix>
+        Align size tracking for multipart requests with FileUpload's use of
+        <code>long</code>. (schultz)
+      </fix>
     </changelog>
   </subsection>
   <subsection name="Coyote">
fc42bbccb904

Align size tracking for multipart requests with FileUpload's use of long

https://github.com/apache/tomcatMark ThomasJul 1, 2025via ghsa
commit
2 files changed · +11 −6
  • java/org/apache/catalina/connector/Request.java+7 −6 modified
    @@ -2674,23 +2674,23 @@ private void parseParts(boolean explicit) {
             try {
                 List<FileItem> items = upload.parseRequest(new ServletRequestContext(this));
                 int maxPostSize = getConnector().getMaxPostSize();
-                int postSize = 0;
+                long postSize = 0;
                 Charset charset = getCharset();
                 for (FileItem item : items) {
                     ApplicationPart part = new ApplicationPart(item, location);
-                    parts.add(part);
                     if (part.getSubmittedFileName() == null) {
                         String name = part.getName();
                         if (maxPostSize >= 0) {
                             // Have to calculate equivalent size. Not completely
                             // accurate but close enough.
-                            postSize += name.getBytes(charset).length;
+                            // Name
+                            postSize = Math.addExact(postSize, name.getBytes(charset).length);
                             // Equals sign
-                            postSize++;
+                            postSize = Math.addExact(postSize, 1);
                             // Value length
-                            postSize += part.getSize();
+                            postSize = Math.addExact(postSize, part.getSize());
                             // Value separator
-                            postSize++;
+                            postSize = Math.addExact(postSize, 1);
                             if (postSize > maxPostSize) {
                                 parameters.setParseFailedReason(FailReason.POST_TOO_LARGE);
                                 throw new IllegalStateException(sm.getString("coyoteRequest.maxPostSizeExceeded"));
@@ -2707,6 +2707,7 @@ private void parseParts(boolean explicit) {
                         // Adjust the limit to account for a file part which is not added to the parameter map.
                         maxParameterCount--;
                     }
+                    parts.add(part);
                 }
 
                 success = true;
  • webapps/docs/changelog.xml+4 −0 modified
    @@ -128,6 +128,10 @@
         multipart uploads with non-file parts when the parts were processed
         before query string parameters. (markt)
       </fix>
+      <fix>
+        Align size tracking for multipart requests with FileUpload's use of
+        <code>long</code>. (schultz)
+      </fix>
     </changelog>
   </subsection>
   <subsection name="Coyote">

Vulnerability mechanics

Generated on May 9, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.

References

8

News mentions

0

No linked articles in our index yet.