CVE-2025-52520

What it actually does

CVE-2025-52520 is an integer overflow in Apache Tomcat multipart upload handling that can, in uncommon multipart upload configurations, allow an attacker to bypass configured request or upload size limits. By causing Tomcat to miscalculate multipart body sizes, an attacker may force the server to process data it should have rejected, potentially exhausting memory, CPU, disk-backed temporary storage, request-processing threads, or other application resources. The practical impact is denial of service rather than code execution or data disclosure.

Why it matters to the business

Affected Tomcat-based applications may become slow, unresponsive, or unavailable if exposed endpoints accept multipart file uploads and are configured in a vulnerable way. This can disrupt customer-facing services, internal applications, APIs, and dependent business workflows. The issue is not listed in CISA KEV and has low EPSS, but Tomcat is widely deployed and upload endpoints are commonly internet-facing, so organizations should still prioritize patching where public multipart upload functionality exists.

How an attack unfolds

An attacker first identifies a Tomcat-hosted application endpoint that accepts multipart/form-data uploads, such as file upload, form submission, import, attachment, or media upload functionality. The attacker then crafts multipart requests that interact with the vulnerable size-accounting logic in a way that triggers integer overflow conditions. If the application and connector configuration match the affected edge case, Tomcat may fail to enforce intended multipart size limits and continue processing oversized or resource-intensive request bodies. Repeating these requests can consume server resources or worker threads until legitimate users experience timeouts, errors, or service unavailability. No public exploit maturity is indicated in the supplied data, and exploitation should be treated primarily as a resource-exhaustion scenario rather than compromise of confidentiality or integrity.

How to fix it

Upgrade Apache Tomcat to a fixed release: 11.0.9 or later for the 11.x branch, 10.1.43 or later for the 10.1.x branch, and 9.0.107 or later for the 9.0.x branch. For source-based deployments, ensure the Tomcat codebase includes fixed commit 43d5ad023d2eee2ca162eded597a23afa0b92296 or a later equivalent. If immediate upgrade is not possible, reduce exposure by restricting access to upload endpoints, enforcing request size limits at a reverse proxy or web application firewall, limiting request body sizes before traffic reaches Tomcat, rate-limiting upload requests, requiring authentication for upload functionality, and monitoring or cleaning temporary upload storage. Review multipart-related application and connector settings to ensure conservative limits are applied consistently at the proxy, Tomcat, framework, and application layers.

How to confirm the fix worked

Confirm the running Tomcat version is 11.0.9 or later, 10.1.43 or later, or 9.0.107 or later. Validate container images, packaged distributions, embedded Tomcat dependencies, and application server bundles, because applications may include Tomcat indirectly. Check startup banners, package metadata, Maven/Gradle dependency trees, container image SBOMs, and deployed library versions. Perform safe functional testing against multipart upload endpoints to verify oversized requests are rejected consistently by the proxy, Tomcat, and application before excessive resource consumption occurs. Confirm monitoring shows stable memory, CPU, request-thread utilization, and temporary upload storage under normal and intentionally bounded upload test traffic.

Typical attack path

1. Identify Tomcat-hosted web applications that expose multipart/form-data upload or form endpoints.
2. Probe upload endpoints to determine whether multipart requests are accepted and whether size limits are enforced.
3. Send specially crafted multipart upload requests designed to trigger integer overflow in size-limit calculations.
4. Repeat or parallelize requests to consume memory, CPU, temporary storage, or Tomcat request-processing threads.
5. Cause degraded performance, HTTP errors, request timeouts, application restarts, or full service outage.

How to detect it

To determine whether exploitation has already occurred, review web access logs, reverse proxy logs, WAF logs, application logs, Tomcat catalina logs, JVM logs, and infrastructure metrics around periods of latency, outages, restarts, or resource exhaustion. Look for bursts of multipart/form-data POST requests to upload-capable endpoints, unusually large request bodies, many incomplete or long-running uploads, repeated requests from the same source or small source set, elevated HTTP 400, 413, 500, 502, 503, or 504 responses, and correlation with increased heap usage, garbage collection pressure, thread pool exhaustion, or temporary directory growth. On hosts, check for Tomcat process restarts, Java OutOfMemoryError messages, excessive disk usage in temporary upload locations, and alerts for high CPU, memory, file handles, or request queue depth. If MadeYouReset-related intelligence is available in existing threat feeds, correlate source IPs, user agents, infrastructure, and timing, but treat generic multipart DoS behavior as non-attributable without additional evidence.

• Content-Type: multipart/form-data
• java.lang.OutOfMemoryError
• OutOfMemoryError: Java heap space
• OutOfMemoryError: GC overhead limit exceeded
• org.apache.tomcat.util.http.fileupload
• SizeLimitExceededException
• FileSizeLimitExceededException
• HTTP/1.1" 413
• HTTP/1.1" 500
• HTTP/1.1" 503
• HTTP/1.1" 504
• catalina.out
• localhost_access_log
• MadeYouReset

What your security team should do

• Inventory internet-facing and internal applications using Apache Tomcat versions 11.0.0-M1 through 11.0.8, 10.1.0-M1 through 10.1.42, and 9.0.0.M1 through 9.0.106.
• Prioritize patching systems that expose multipart/form-data upload endpoints, especially unauthenticated or internet-facing upload functionality.
• Upgrade to Tomcat 11.0.9, 10.1.43, or 9.0.107, or ensure source deployments include commit 43d5ad023d2eee2ca162eded597a23afa0b92296 or later.
• Add compensating controls at reverse proxies and WAFs to cap request body size, limit upload rates, and block abnormal multipart request patterns until patching is complete.
• Review application upload configurations and confirm multipart size limits are enforced at multiple layers, not only inside application code.
• Monitor for spikes in multipart upload traffic, large request bodies, HTTP 413/400/500 responses, request timeouts, Tomcat thread exhaustion, OutOfMemoryError events, and temporary upload directory growth.
• Investigate any suspicious activity referencing the reported threat actor or campaign name MadeYouReset, while avoiding attribution based only on generic denial-of-service traffic.