CVE-2025-61795: Apache Tomcat DoS Vulnerability

CVE-2025-61795 Overview

An Improper Resource Shutdown or Release vulnerability has been identified in Apache Tomcat that can lead to a Denial of Service (DoS) condition. When errors occur during multipart upload processing—including scenarios where upload limits are exceeded—temporary copies of uploaded file parts written to disk are not cleaned up immediately. Instead, these temporary files are left for the Java garbage collection (GC) process to delete.

Depending on JVM configuration, application memory usage, and server load, the disk space allocated for temporary file storage can be exhausted faster than the garbage collector can clear it. This resource exhaustion condition enables attackers to trigger a DoS against affected Apache Tomcat servers.

Critical Impact

Attackers can exhaust server disk space through crafted multipart uploads, causing service unavailability and potentially affecting all applications hosted on the Tomcat instance.

Affected Products

• Apache Tomcat 11.0.0-M1 through 11.0.11
• Apache Tomcat 10.1.0-M1 through 10.1.46
• Apache Tomcat 9.0.0.M1 through 9.0.109
• Apache Tomcat 8.5.0 through 8.5.100 (End of Life)

Discovery Timeline

• 2025-10-27 - CVE-2025-61795 published to NVD
• 2025-11-14 - Last updated in NVD database

Technical Details for CVE-2025-61795

Vulnerability Analysis

This vulnerability is classified as CWE-404 (Improper Resource Shutdown or Release). The flaw exists in how Apache Tomcat handles temporary file cleanup during multipart upload processing. Under normal operations, when a multipart upload request is processed, Tomcat writes temporary copies of the uploaded file parts to disk. If an error occurs during this process—such as exceeding configured size limits or encountering I/O errors—the temporary files should be immediately deleted to free disk space.

However, due to improper resource management, these temporary files are not cleaned up synchronously when errors occur. Instead, the cleanup is deferred to the JVM's garbage collection cycle. This design flaw creates a race condition between file creation and cleanup, where an attacker can generate temporary files faster than they are removed.

Root Cause

The root cause lies in the improper handling of temporary file resources within Tomcat's multipart upload processing code. When the upload encounters an error condition, the associated temporary DiskFileItem objects are not explicitly deleted. The cleanup relies on Java's finalization mechanism and garbage collection, which is non-deterministic and may not execute in a timely manner—especially under high load conditions or with specific JVM heap configurations.

This behavior violates secure resource management principles, as temporary resources acquired during error paths should be released immediately rather than relying on eventual garbage collection.

Attack Vector

The attack vector is network-based and requires low privileges to execute. An attacker can exploit this vulnerability by sending a series of multipart HTTP POST requests to any endpoint on the Tomcat server that accepts file uploads. The attack methodology involves:

1. Crafting multipart upload requests that trigger error conditions (e.g., exceeding maxFileSize or maxRequestSize limits)
2. Sending these requests repeatedly at high volume to generate many temporary files
3. Continuing the attack until the temporary directory's disk partition is exhausted
4. The DoS condition prevents legitimate users from uploading files and may cause application failures if the same partition is used for other operations

The attack requires network access to the target Tomcat server but does not require authentication to endpoints that accept file uploads. The complexity is high due to the dependency on JVM settings and server load conditions for successful exploitation.

Detection Methods for CVE-2025-61795

Indicators of Compromise

• Unusual disk space consumption in the Tomcat temporary directory ($CATALINA_BASE/temp or system temp directory)
• Rapid accumulation of temporary files with patterns like upload_*.tmp or multipart file naming conventions
• High volume of multipart POST requests from single or distributed sources resulting in HTTP 400/413 error responses
• Application errors or failures due to disk space exhaustion

Detection Strategies

• Monitor the Tomcat temporary directory for abnormal file accumulation and disk usage growth rates
• Implement rate limiting on endpoints that accept multipart uploads to prevent request flooding
• Configure web application firewall (WAF) rules to detect and block repetitive failed upload attempts from the same source
• Review Tomcat access logs for patterns of repeated multipart upload requests with error responses

Monitoring Recommendations

• Set up disk space monitoring alerts for partitions containing Tomcat temporary files with thresholds below 80% utilization
• Enable JMX monitoring for Tomcat to track request processing metrics and error rates
• Implement log aggregation to correlate high volumes of upload error responses with disk usage anomalies
• Deploy SentinelOne agents to detect resource exhaustion attacks and anomalous file system activity

How to Mitigate CVE-2025-61795

Immediate Actions Required

• Upgrade Apache Tomcat to version 11.0.12 or later, 10.1.47 or later, or 9.0.110 or later immediately
• If running Apache Tomcat 8.5.x, migrate to a supported version as 8.5 is End of Life
• Review and reduce multipart upload size limits (maxFileSize, maxRequestSize) to minimize temporary file size
• Ensure the temporary directory is on a partition with adequate space and separate from critical system partitions

Patch Information

Apache has released patched versions that properly clean up temporary files when errors occur during multipart upload processing:

For additional details, refer to the Apache Mailing List Discussion and the OpenWall OSS Security Update.

Workarounds

• Configure a dedicated partition for the Tomcat temporary directory to prevent disk exhaustion from affecting other services
• Implement an automated cleanup script that runs periodically to remove stale temporary files from the upload directory
• Deploy rate limiting at the load balancer or reverse proxy level to restrict multipart upload requests per client
• Consider disabling multipart upload functionality on endpoints where it is not required

# Configuration example: Set up a dedicated tmpdir for Tomcat with automated cleanup
# Add to setenv.sh or catalina.sh
CATALINA_TMPDIR=/var/tomcat/temp
export CATALINA_TMPDIR

# Create cleanup cron job (run every 15 minutes)
# Add to crontab: */15 * * * * find /var/tomcat/temp -type f -mmin +30 -delete