CVE-2025-48988

What it actually does

CVE-2025-48988 is a resource-exhaustion vulnerability in Apache Tomcat caused by insufficient limits or throttling around resource allocation. A remote attacker can cause affected Tomcat versions to allocate excessive server resources, such as memory, CPU, request-processing threads, connections, or HTTP/2-related state, leading to degraded performance or denial of service. The primary impact is availability loss; it does not inherently provide code execution or data disclosure.

Why it matters to the business

Successful exploitation can make applications hosted on vulnerable Tomcat versions slow or unavailable, causing service outages, failed transactions, customer-facing downtime, monitoring noise, and incident response costs. The EPSS score is elevated, indicating meaningful exploitation likelihood, and the issue has been public for over a year, increasing the urgency for remediation even though it is not currently listed in CISA KEV and is not known to be ransomware-associated. Organizations using Tomcat directly or embedded in third-party products should treat this as an internet-facing availability risk.

How an attack unfolds

An attacker identifies an application or service backed by a vulnerable Apache Tomcat release, especially one exposed to the internet and accepting high-volume client traffic. The attacker then sends crafted or sustained request patterns that trigger unbounded or insufficiently throttled resource allocation inside Tomcat. In HTTP/2-enabled deployments, this may resemble MadeYouReset-style abuse, where protocol behavior is used to force the server to spend disproportionate resources handling connections or streams. As resource consumption grows, Tomcat may exhaust request threads, heap memory, file descriptors, connection capacity, or CPU. Legitimate users then experience slow responses, 5xx errors, connection resets, or complete service unavailability until traffic is blocked, Tomcat is restarted, capacity recovers, or the software is upgraded.

How to fix it

Upgrade Apache Tomcat to a fixed release: 11.0.8 or later for the 11.x branch, 10.1.42 or later for the 10.1.x branch, and 9.0.106 or later for the 9.0.x branch. For source-based deployments, ensure the Tomcat code includes fix commit 05ccf0c3e22d388f0cf853e32485d8249d051f2f or a later equivalent. If Tomcat is bundled inside another product, upgrade that product to a version that includes the fixed Tomcat release. As interim mitigations, restrict direct internet access where possible, place Tomcat behind a reverse proxy or load balancer with request-rate and connection limits, enforce per-client throttling, tune connector limits, monitor JVM heap and thread pools, and consider disabling HTTP/2 if it is not required or if compensating controls cannot be applied promptly. The provided affected product data also lists Mageia ffmpeg fixed in 1.1.14-1.mga3.tainted; validate package advisories before prioritizing this item because the described vulnerability is Tomcat-specific.

How to confirm the fix worked

Confirm all deployed Tomcat instances report fixed versions: 11.0.8+, 10.1.42+, or 9.0.106+. Check package inventories, container images, application server banners where available, build manifests, SBOMs, and embedded dependency versions in vendor products. Validate that no affected versions remain: 11.0.0-M1 through 11.0.7, 10.1.0-M1 through 10.1.41, or 9.0.0.M1 through 9.0.105. After upgrading, perform controlled load testing to confirm request handling remains stable and that rate limits, connector limits, heap usage, file descriptors, and thread pools behave as expected under stress. Review reverse proxy, WAF, and load balancer policies to ensure abusive request rates and excessive concurrent connections are throttled before reaching Tomcat.

Typical attack path

1. Scan for publicly reachable services running Apache Tomcat or applications commonly deployed on Tomcat.
2. Determine whether the target is running an affected Tomcat version or appears susceptible based on behavior and exposed protocol support.
3. Send high-rate or crafted requests that cause Tomcat to allocate resources without sufficient throttling.
4. Sustain or distribute the traffic to keep server resources exhausted.
5. Observe service degradation through slow responses, connection failures, HTTP 5xx responses, or timeouts.
6. Continue the attack until defensive controls, traffic filtering, service restart, or patching restores availability.

How to detect it

To determine whether exploitation has already occurred, review Tomcat access logs, Catalina logs, application logs, JVM garbage collection logs, reverse proxy logs, WAF logs, load balancer telemetry, firewall logs, and NetFlow data for abnormal traffic bursts followed by service degradation. Look for sudden spikes in concurrent connections, HTTP/2 streams, stream resets, short-lived requests, request timeouts, 499/500/502/503/504 responses, connection resets, thread-pool exhaustion, heap exhaustion, long garbage-collection pauses, or file descriptor exhaustion. Compare traffic by source IP, ASN, user agent, request path, and protocol version to identify concentrated or distributed abusive patterns. For MadeYouReset-style activity, pay particular attention to HTTP/2-heavy traffic with unusual reset behavior or disproportionate server load relative to completed requests. Because this is a denial-of-service issue, durable host artifacts may be limited; evidence is most likely to appear in logs, performance metrics, packet captures, and upstream network telemetry around outage windows.

• java.lang.OutOfMemoryError
• unable to create new native thread
• Too many open files
• org.apache.coyote.http2
• RST_STREAM
• GOAWAY
• Connection reset by peer
• Broken pipe
• SocketTimeoutException
• ClientAbortException
• All threads
• are currently busy
• HTTP/2
• 503 Service Unavailable
• 504 Gateway Timeout
• 502 Bad Gateway
• MadeYouReset

What your security team should do

• Prioritize remediation for internet-facing Tomcat services and high-availability business applications.
• Upgrade affected Tomcat branches to 11.0.8+, 10.1.42+, or 9.0.106+ as soon as operationally feasible.
• Inventory embedded Tomcat instances in commercial software, appliances, containers, and internally packaged Java applications.
• Apply compensating controls immediately where patching is delayed, including rate limits, connection limits, request throttling, and reverse-proxy enforcement.
• Review whether HTTP/2 is required; disable it temporarily for exposed Tomcat services if risk is high and business impact is acceptable.
• Create monitoring for sudden increases in Tomcat thread exhaustion, heap pressure, garbage collection pauses, file descriptor exhaustion, HTTP 5xx responses, and connection resets.
• Correlate network-layer spikes with Tomcat logs to identify MadeYouReset-style or other resource-exhaustion behavior.
• Prepare operational playbooks for rapid traffic blocking, autoscaling, service restart, and upstream filtering during denial-of-service events.