CVE-2026-41284

What it actually does

This is a remotely reachable denial-of-service weakness in Apache Tomcat caused by allocation of resources without sufficient limits or throttling. An unauthenticated network attacker can send requests or maintain traffic patterns that cause Tomcat to consume excessive server resources such as worker threads, memory, CPU, sockets, or request-processing capacity. Successful exploitation does not provide code execution or data access, but it can make hosted Java web applications slow, unstable, or unavailable. Affected ranges include Apache Tomcat 11.0.0-M1 through 11.0.21, 10.1.0-M1 through 10.1.54, and 9.0.0.M1 through 9.0.117; older unsupported versions may also be affected.

Why it matters to the business

Organizations running affected Apache Tomcat versions may experience application outages, degraded response times, failed transactions, increased infrastructure costs from resource exhaustion, and operational disruption for services hosted on Tomcat. Because the flaw is network-accessible, requires no authentication, and has high availability impact, internet-facing Tomcat services should be prioritized even though EPSS is currently low at 0.0078, the 30-day trend is flat, there is no known KEV listing, and no public exploit maturity is reported in the provided data.

How an attack unfolds

An attacker first identifies an exposed Apache Tomcat service running an affected version. They then generate requests or connection patterns that trigger unbounded or insufficiently throttled resource allocation inside Tomcat. As the traffic continues, Tomcat consumes available execution capacity such as request threads, heap memory, file descriptors, or CPU. Legitimate requests are delayed, rejected, or time out, and the service may eventually return errors, stop responding, or require restart. The attacker does not need credentials or user interaction, and exploitation can be repeated to sustain an outage until the server is patched or mitigations such as rate limiting, connection limits, and resource controls are enforced.

How to fix it

Upgrade Apache Tomcat to a version that contains the vendor fix. The affected ranges are 11.0.0-M1 through 11.0.21, 10.1.0-M1 through 10.1.54, and 9.0.0.M1 through 9.0.117; use the Apache Tomcat security advisory and package distributor guidance to identify the exact fixed release for the deployed branch. If immediate upgrade is not possible, reduce exposure by placing Tomcat behind a reverse proxy or load balancer with request-rate limits, connection limits, request body/header size limits, idle timeout controls, and bot/DDoS protections. Tune Tomcat connector settings such as maximum threads, accept queue, connection timeout, keep-alive behavior, maximum connections, and request size limits according to application needs. Ensure JVM memory limits, container resource quotas, systemd limits, and file descriptor limits are explicitly configured so exhaustion is contained. Remove unsupported Tomcat versions from production because older versions may also be affected and may not receive fixes.

How to confirm the fix worked

Confirm the deployed Tomcat version is no longer within the affected ranges by checking startup logs, package manager metadata, container image tags, Tomcat release files, or the Manager status page where enabled. Verify that all runtime nodes, container images, golden images, and downstream application bundles have been rebuilt or redeployed with the fixed Tomcat release. Perform controlled load and abuse-case testing in a non-production environment to confirm that request, connection, thread, memory, and timeout limits prevent unbounded resource consumption. Review reverse proxy, load balancer, WAF, and Tomcat connector configurations to confirm limits are active and observable. After deployment, monitor for reduced 5xx/503 rates, stable JVM heap usage, stable thread counts, and normal request latency under representative load.

Typical attack path

1. Discover exposed Apache Tomcat instances through scanning, service banners, default pages, application behavior, or internet-wide indexing.
2. Determine or infer that the instance is within an affected Tomcat version range.
3. Send crafted or high-volume request patterns that cause Tomcat to allocate resources without adequate throttling.
4. Continue the traffic until Tomcat worker threads, memory, sockets, CPU, or request queues are exhausted.
5. Observe service degradation, increased latency, HTTP 5xx/503 responses, connection resets, or complete unavailability.
6. Repeat or distribute the traffic to keep the application unavailable until remediation or traffic controls are applied.

How to detect it

To determine whether exploitation may already have occurred, review Tomcat access logs, reverse proxy logs, load balancer logs, WAF events, JVM logs, application logs, system logs, and infrastructure metrics for resource-exhaustion symptoms. Look for concentrated bursts of requests from one or more sources followed by rising latency, increased active connections, thread pool saturation, heap pressure, garbage collection spikes, HTTP 500/502/503/504 responses, connection resets, and Tomcat restarts. Correlate timestamps across proxy logs and Tomcat logs to identify request patterns immediately preceding outages or JVM errors. Review operating system telemetry for high CPU, memory exhaustion, file descriptor exhaustion, excessive socket states, or process restarts. Because the provided intelligence does not include a specific exploit payload, detection should focus on behavioral indicators: repeated anomalous request rates, long-lived idle connections, unusual request sizes, high keep-alive usage, and resource exhaustion errors in Tomcat and JVM logs.

• java.lang.OutOfMemoryError
• java.lang.OutOfMemoryError: Java heap space
• java.lang.OutOfMemoryError: unable to create native thread
• java.lang.OutOfMemoryError: GC overhead limit exceeded
• Too many open files
• java.net.SocketException: Too many open files
• org.apache.tomcat.util.threads.ThreadPoolExecutor
• org.apache.coyote.AbstractProtocol pause
• org.apache.coyote.AbstractProtocol stop
• org.apache.catalina.core.StandardService stopInternal
• org.apache.catalina.startup.Catalina stopServer
• SEVERE [main] org.apache.catalina.startup.Catalina.start
• HTTP/1.1" 503
• HTTP/1.1" 504
• HTTP/1.1" 500
• Connection reset by peer
• Broken pipe
• SocketTimeoutException
• RejectedExecutionException
• maxThreads
• currentThreadsBusy

What your security team should do

• Inventory all Apache Tomcat deployments, including embedded Tomcat in Java applications, containers, appliances, and developer-managed services.
• Prioritize remediation for internet-facing Tomcat instances and systems supporting revenue-generating, customer-facing, or operationally critical applications.
• Upgrade affected Tomcat 11.x, 10.1.x, and 9.0.x deployments to the vendor-fixed release for the appropriate branch as soon as practical.
• Where patching is delayed, enforce rate limiting, maximum connection controls, request size limits, idle timeouts, and upstream DDoS protections at the reverse proxy or load balancer.
• Tune Tomcat and JVM resource limits so resource exhaustion is bounded and does not destabilize the host or neighboring services.
• Enable alerting on abnormal spikes in Tomcat threads, JVM heap, CPU, open file descriptors, HTTP 5xx/503 responses, connection resets, and request latency.
• Search historical logs for signs of resource-exhaustion attempts since publication, especially on exposed services.
• Track Apache Tomcat advisories and distribution package updates because the provided data does not include exact fixed version numbers.
• Remove or isolate unsupported Tomcat versions, as older unsupported releases may also be affected and may not receive patches.