CVE-2025-48989

What it actually does

This is a remotely triggerable denial-of-service weakness in Apache Tomcat caused by improper release of resources during reset/abort handling associated with the MadeYouReset attack pattern. An unauthenticated network client can cause Tomcat to retain or consume server-side resources tied to HTTP request or stream processing after the client-side interaction is reset or otherwise terminated. Repeated triggering can exhaust worker threads, connection handling capacity, memory, CPU, or related request-processing resources, reducing or preventing availability of applications hosted on the affected Tomcat instance. The issue affects Apache Tomcat 11.0.0-M1 through 11.0.9, 10.1.0-M1 through 10.1.43, and 9.0.0.M1 through 9.0.107; older end-of-life versions may also be affected.

Why it matters to the business

Successful exploitation can make Tomcat-hosted applications slow, unstable, or unavailable without requiring attacker authentication. For organizations using Tomcat for customer portals, APIs, administrative consoles, internal services, or embedded application components, this can cause service outages, failed transactions, degraded user experience, incident response costs, and potential SLA impact. The vulnerability is not currently listed in CISA KEV, is not marked as ransomware-associated, and has a relatively low EPSS value, but its network-reachable, low-complexity nature and high availability impact make internet-facing Tomcat deployments a priority for remediation.

How an attack unfolds

An attacker first identifies a reachable service backed by an affected Tomcat version. They then open network connections and send crafted request traffic that exercises the reset/abort behavior associated with the MadeYouReset denial-of-service technique. Because the vulnerable Tomcat versions do not consistently release resources when the request or stream is reset, each malicious interaction can leave server-side processing capacity consumed longer than intended. By repeating this at scale, potentially from a single host or a small set of hosts, the attacker can drive up active connection counts, busy request processors, HTTP/2 reset activity, garbage collection pressure, or thread utilization until legitimate users experience timeouts, 5xx responses, or total service unavailability.

How to fix it

Upgrade Apache Tomcat to a fixed release: 11.0.10 or later for the 11.x line, 10.1.44 or later for the 10.1.x line, or 9.0.108 or later for the 9.0.x line. For source-based deployments, use Apache Tomcat commit c63765c906c86af8afa43281f591d11ac5c9e5c1 or a later fixed revision. For affected Amazon ECS Agent Go package usage, upgrade github.com/aws/amazon-ecs-agent to 1.97.1 or later; for source-based Amazon ECS Agent deployments, use commit 285536952db15aafab623050c4bce27720bc183c or later. Where immediate upgrade is not possible, reduce exposure by placing Tomcat behind a reverse proxy, load balancer, or WAF with connection and request-rate controls; enforce per-client connection limits; tune request, keep-alive, and idle timeouts; restrict access to trusted networks where feasible; and consider disabling HTTP/2 on exposed connectors if operationally acceptable and relevant to the deployment. End-of-life Tomcat branches should be migrated to supported fixed versions rather than backported informally.

How to confirm the fix worked

Confirm the deployed Tomcat version is not within the affected ranges: 11.0.0-M1 through 11.0.9, 10.1.0-M1 through 10.1.43, or 9.0.0.M1 through 9.0.107. Validate runtime version using startup logs, package manager inventory, container image manifests, application server banners where available, and the Tomcat lib/catalina.jar implementation version. For Amazon ECS Agent dependencies, confirm github.com/aws/amazon-ecs-agent is 1.97.1 or later, or that source builds include commit 285536952db15aafab623050c4bce27720bc183c or later. After patching, restart affected services and verify that health checks, access paths, and application transactions function normally. If HTTP/2 or reset-rate mitigations were added, test that legitimate clients still connect successfully while rate limits and timeout controls are enforced. External exposure should be re-scanned to ensure no reachable Tomcat instance remains on an affected version.

Typical attack path

1. Identify an internet-facing or internally reachable application served by Apache Tomcat.
2. Confirm that the target appears to be running an affected Tomcat release or an unpatched downstream component embedding affected behavior.
3. Establish repeated HTTP connections to the service, commonly focusing on reset/abort behavior such as HTTP/2 stream reset patterns where applicable.
4. Send crafted request sequences that cause Tomcat to allocate request-processing resources and then trigger reset handling before normal completion.
5. Repeat the sequence rapidly or concurrently to accumulate resource pressure on the Tomcat process.
6. Sustain traffic until worker threads, connection capacity, CPU, memory, or request-processing queues are saturated.
7. Legitimate clients begin seeing slow responses, connection resets, HTTP 503/504 errors, failed health checks, or application outage.

How to detect it

Because this is an availability-focused vulnerability, successful exploitation may not leave a single definitive compromise artifact; detection should focus on traffic patterns and operational symptoms. Review Tomcat access logs, catalina logs, application logs, reverse proxy logs, load balancer telemetry, WAF logs, and network packet captures for bursts of short-lived or aborted requests, high connection churn, abnormal HTTP/2 reset activity, and repeated requests from the same source or source ranges followed by service degradation. Look for time-correlated increases in Tomcat busy threads, rejected requests, garbage collection pressure, CPU usage, connection counts, request queue depth, and HTTP 503/504 responses. In environments with HTTP/2 frame visibility, investigate unusually high RST_STREAM rates, stream creation followed quickly by resets, or resets disproportionate to completed requests. For historical review, correlate these indicators with application outages, health-check failures, autoscaling events, container restarts, JVM out-of-memory events, or watchdog restarts. If MadeYouReset-themed scanning or exploit traffic is suspected, preserve packet captures and load balancer/WAF request metadata before log rotation, as standard access logs may not capture all stream-reset details.

• MadeYouReset
• RST_STREAM
• HTTP/2 RST_STREAM
• ClientAbortException
• org.apache.catalina.connector.ClientAbortException
• java.io.IOException: Connection reset by peer
• java.io.IOException: Broken pipe
• Connection reset by peer
• Broken pipe
• HTTP 503
• HTTP 504
• All threads are busy
• maxThreads
• currentThreadsBusy
• catalina.out
• logs/catalina.log
• logs/localhost_access_log

What your security team should do

• Inventory all Tomcat deployments, including embedded Tomcat in Java applications, containers, appliances, CI/CD images, and vendor-supplied products.
• Prioritize patching internet-facing, partner-facing, and mission-critical Tomcat services to 11.0.10, 10.1.44, or 9.0.108 or later.
• Upgrade affected Amazon ECS Agent dependency usage to github.com/aws/amazon-ecs-agent 1.97.1 or later where applicable.
• Apply compensating controls immediately for systems that cannot be upgraded, including reverse-proxy rate limiting, per-source connection limits, request timeout hardening, and HTTP/2 exposure reduction where feasible.
• Review load balancer, reverse proxy, WAF, Tomcat, and application monitoring for historical spikes in reset/abort behavior, connection churn, 5xx responses, thread exhaustion, or service health-check failures.
• Create alerting for abnormal rates of HTTP/2 RST_STREAM frames, client aborts, connection resets, busy Tomcat threads, and elevated 503/504 responses.
• Remove or isolate unsupported end-of-life Tomcat versions because older branches may also be affected and may not receive reliable security fixes.
• Document patch status in vulnerability management records and validate that base images and deployment templates have been updated to prevent reintroduction.