CVE-2025-61795

What it actually does

Apache Tomcat fails to immediately clean up temporary files created while processing multipart/form-data uploads when multipart parsing exits through an error path, such as exceeded upload limits or malformed input. The orphaned temporary upload parts remain on disk until JVM garbage collection later releases them. Under sustained or parallel upload error conditions, disk space in the servlet multipart temporary directory, CATALINA_BASE/temp, or the configured java.io.tmpdir can be consumed faster than garbage collection removes the files, causing application errors or service unavailability. The flaw impacts availability only; it does not provide code execution, privilege escalation, or direct data disclosure.

Why it matters to the business

An attacker with the ability to submit multipart uploads to an affected Tomcat-hosted application can cause disk exhaustion and interrupt business services, especially applications that expose file upload, form submission, API import, attachment, or media upload features. The issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, and has low EPSS probability, but it has been public for 286 days and remains operationally relevant for internet-facing or high-volume upload services. Outages may affect customer portals, internal workflows, API availability, and incident response capacity due to disk cleanup and service recovery work.

How an attack unfolds

An attacker identifies a Tomcat-hosted application endpoint that accepts multipart/form-data uploads. Using a valid low-privilege account or any reachable upload workflow, the attacker sends requests that cause multipart parsing to fail after Tomcat has already written temporary upload parts to disk. Common triggers include oversized parts, excessive request sizes, malformed multipart boundaries, or other inputs that exceed configured limits. In affected versions, those temporary files are not immediately removed on the error path and are left for JVM garbage collection. By repeating the requests or running them concurrently, the attacker can accumulate temporary files faster than garbage collection clears them. Once the relevant temporary filesystem fills, Tomcat and hosted applications may fail to create temporary files, write logs, process requests, or continue normal operation, resulting in denial of service.

How to fix it

Upgrade Apache Tomcat to a fixed release: 11.0.12 or later for the 11.x line, 10.1.47 or later for the 10.1.x line, or 9.0.110 or later for the 9.0.x line. Apache Tomcat 8.5.x is end-of-life and affected through 8.5.100; migrate to a supported fixed branch rather than relying on continued 8.5.x maintenance. For source-based deployments, include the upstream fix identified by Apache Tomcat commit dbccb8cba2bf667a0e1b5da02187bda3e1a74120 or a later release containing it. As interim risk reduction, enforce strict upload size limits at the reverse proxy and application layers, restrict upload endpoints to authenticated and authorized users, rate-limit multipart POST requests, place temporary upload directories on monitored filesystems with sufficient headroom, and configure alerting for rapid growth in Tomcat temporary directories. These mitigations reduce exploitability but should not replace upgrading.

How to confirm the fix worked

Confirm the running Tomcat version is 11.0.12 or later, 10.1.47 or later, or 9.0.110 or later using version.sh/version.bat, package manager metadata, container image manifests, catalina.jar manifest Implementation-Version, or runtime startup logs. Verify no unsupported Tomcat 8.5.x or older branch remains in use. Check application configuration for multipart upload locations and confirm temporary files are cleaned promptly after rejected uploads in a controlled non-production test. Review reverse proxy, WAF, and application limits for maximum request body size, multipart part count, and upload rate. Validate monitoring alerts trigger on low free space and abnormal growth under CATALINA_BASE/temp, java.io.tmpdir, or explicitly configured multipart locations.

Typical attack path

1. Discover a Tomcat-hosted application endpoint that accepts multipart/form-data uploads.
2. Authenticate with a low-privilege account if the upload workflow requires login.
3. Submit malformed, oversized, or limit-exceeding multipart upload requests that trigger multipart parsing errors.
4. Repeat the failed upload requests at sufficient volume or concurrency to accumulate temporary files on disk.
5. Exhaust the filesystem used for multipart temporary storage, CATALINA_BASE/temp, or java.io.tmpdir.
6. Cause application errors, failed uploads, failed request processing, degraded performance, or Tomcat service outage.

How to detect it

To determine whether this was already exploited, review web server, reverse proxy, WAF, Tomcat access, and application logs for bursts of multipart/form-data POST requests that returned 400, 413, 500, or other upload-related errors. Correlate these requests with filesystem telemetry showing rapid growth or exhaustion of CATALINA_BASE/temp, java.io.tmpdir, or configured multipart upload directories. Look for repeated multipart parser exceptions, upload size limit exceptions, malformed boundary errors, and disk-full messages in catalina.out, localhost logs, application logs, container stdout/stderr, system journal logs, and JVM logs. Check endpoint metrics for spikes in failed uploads, long request times, thread exhaustion, or sudden availability drops. On hosts or containers, inspect temporary directories for large numbers of upload-related .tmp files with creation times matching suspicious request bursts. Because exploitation does not require malware or persistent artifacts, absence of files after garbage collection or manual cleanup does not rule out prior abuse; rely on time-correlated access logs, error logs, disk metrics, and incident timestamps.

• Content-Type: multipart/form-data
• java.io.IOException: No space left on device
• No space left on device
• SizeLimitExceededException
• FileSizeLimitExceededException
• MalformedStreamException
• Stream ended unexpectedly
• org.apache.tomcat.util.http.fileupload
• org.apache.tomcat.util.http.fileupload.impl
• org.apache.tomcat.util.http.fileupload.FileUploadBase
• DiskFileItem
• jakarta.servlet.MultipartConfigElement
• javax.servlet.MultipartConfigElement
• CATALINA_BASE/temp
• java.io.tmpdir
• upload_
• Request body is larger than the configured limit
• HTTP/1.1" 413
• POST

What your security team should do

• Inventory all Apache Tomcat instances, including embedded Tomcat in Java applications and container images, and prioritize internet-facing systems with file upload or multipart API endpoints.
• Upgrade affected Tomcat deployments to 11.0.12+, 10.1.47+, or 9.0.110+; migrate any 8.5.x deployments to a supported branch.
• Apply compensating controls until upgrades complete: request body size limits, upload endpoint rate limits, authentication requirements, and WAF/proxy controls for abnormal multipart traffic.
• Monitor disk utilization and temporary upload directories for rapid growth, especially around upload-heavy endpoints and repeated multipart parsing errors.
• Review access logs for repeated failed multipart POST requests from the same source, credential, session, or autonomous system.
• Ensure temporary upload directories are isolated from critical OS, log, and application data filesystems where practical to reduce blast radius of disk exhaustion.
• Add incident runbooks for safely clearing orphaned Tomcat upload temporary files and restarting services after confirming active requests are not using those files.