CVE-2024-23672

What it actually does

CVE-2024-23672 is a denial-of-service weakness in Apache Tomcat WebSocket handling caused by incomplete cleanup of WebSocket-related resources. A remote client can keep WebSocket connections open in a way that increases server-side resource consumption over time, potentially exhausting connection slots, file descriptors, threads, heap memory, or other servlet container resources. The issue affects Apache Tomcat 11.0.0-M1 through 11.0.0-M16, 10.1.0-M1 through 10.1.18, 9.0.0-M1 through 9.0.85, and 8.5.0 through 8.5.98.

Why it matters to the business

Successful exploitation can make applications hosted on vulnerable Tomcat instances slow or unavailable, disrupting customer-facing portals, APIs, administrative consoles, and internal services that depend on those applications. Because exploitation is a resource-exhaustion condition rather than code execution, the main risk is service outage, degraded performance, increased infrastructure cost from autoscaling or restart loops, and operational load on response teams. The vulnerability is not listed in CISA KEV, has no known ransomware association, and has a relatively low EPSS score, but it has been public for a long time, so internet-exposed Tomcat services should still be remediated as part of routine availability hardening.

How an attack unfolds

An attacker identifies an application served by a vulnerable Apache Tomcat version with reachable WebSocket endpoints. The attacker opens many WebSocket upgrade requests, completes or partially maintains the WebSocket sessions, and keeps those connections alive long enough to prevent normal cleanup behavior. As connections accumulate, Tomcat retains resources associated with those sessions. The attacker may repeat the process from one host, many hosts, or through distributed infrastructure to bypass connection limits and accelerate exhaustion. Once resource thresholds are reached, legitimate users may experience timeouts, failed WebSocket handshakes, HTTP 5xx responses, thread pool saturation, high memory pressure, or application restarts. No public named threat actor activity or KEV exploitation is associated with the issue in the provided intelligence.

How to fix it

Upgrade Apache Tomcat to a fixed release: 11.0.0-M17 or later, 10.1.19 or later, 9.0.86 or later, or 8.5.99 or later. Source-based users should ensure the fix corresponding to Apache Tomcat commit 542c35ae834fb29616b184a0e4276a5b7f8542de is present. If Tomcat is consumed through an operating system or application package, apply the vendor-provided security update and confirm the embedded Tomcat libraries are fixed; the provided package data also lists Ubuntu 16.04 LTS wordpress fixed in 4.3.1+dfsg-1, but Tomcat deployments should be validated against Tomcat-specific package advisories and library versions. If immediate upgrade is not possible, reduce exposure by restricting access to WebSocket endpoints, enforcing authentication before WebSocket upgrade where feasible, applying reverse-proxy connection and rate limits, setting idle WebSocket timeouts, limiting maximum concurrent connections per source, monitoring file descriptor and thread pool usage, and ensuring graceful restart procedures are available.

How to confirm the fix worked

Confirm the running Tomcat version is no longer within the vulnerable ranges: 11.0.0-M1 through 11.0.0-M16, 10.1.0-M1 through 10.1.18, 9.0.0-M1 through 9.0.85, or 8.5.0 through 8.5.98. Check the deployed server banner, package manager inventory, container image SBOM, application bundle libraries, and Tomcat startup logs for the actual runtime version rather than relying only on repository metadata. Validate that WebSocket endpoints still function after upgrade, then perform a controlled connection-load test to confirm idle or abandoned WebSocket sessions are cleaned up and that thread, memory, and file descriptor counts return to baseline after clients disconnect. Review reverse proxy and application server limits to ensure connection caps and idle timeouts are active. For source builds, verify the fix commit 542c35ae834fb29616b184a0e4276a5b7f8542de or an equivalent later commit is included.

Typical attack path

1. Discover internet-facing or internally reachable applications running affected Apache Tomcat versions.
2. Identify WebSocket-capable routes by looking for endpoints that accept HTTP Upgrade requests.
3. Open a high volume of WebSocket connections to the target service.
4. Keep connections open or recycle them in a pattern that triggers incomplete cleanup and growing resource consumption.
5. Continue until Tomcat exhausts available threads, sockets, file descriptors, memory, or application connection capacity.
6. Cause application slowdown, failed requests, connection refusal, or service interruption for legitimate users.

How to detect it

To assess possible prior exploitation, review web server, reverse proxy, load balancer, WAF, and Tomcat access logs for abnormal volumes of WebSocket upgrade activity, especially HTTP 101 Switching Protocols responses, repeated Upgrade: websocket requests, long-lived connections, and concentration from a small number of source IPs or autonomous systems. Correlate these events with application symptoms such as spikes in response time, HTTP 5xx errors, connection resets, Tomcat thread pool exhaustion, high JVM heap or garbage collection pressure, high open file descriptor counts, and restarts triggered by health checks or orchestrators. On Linux hosts, historical telemetry from process monitoring, EDR, container metrics, or observability platforms may show elevated open sockets for the java process, high established TCP session counts, or thread exhaustion during the suspected window. Investigate WebSocket endpoint paths that received unusually high or sustained traffic and compare against normal business patterns. The indicators below are hunt pivots rather than definitive proof of compromise because legitimate WebSocket applications can produce similar log entries.

• Upgrade: websocket
• Connection: Upgrade
• 101 Switching Protocols
• " 101
• Sec-WebSocket-Key:
• Sec-WebSocket-Version: 13
• org.apache.tomcat.websocket
• WsFrameServer
• WsHttpUpgradeHandler
• java.net.SocketTimeoutException
• java.io.EOFException
• Too many open files
• OutOfMemoryError
• unable to create new native thread
• maxThreads
• currentThreadsBusy

What your security team should do

• Prioritize upgrading internet-facing Tomcat servers and services with unauthenticated WebSocket endpoints to fixed versions first.
• Inventory all Tomcat runtimes, including embedded Tomcat in applications, containers, appliances, and third-party software.
• Add monitoring for abnormal WebSocket connection counts, long-lived idle connections, thread pool saturation, high file descriptor usage, and elevated HTTP 5xx or timeout rates.
• Implement reverse-proxy or load-balancer controls for WebSocket endpoints, including per-IP connection limits, idle timeouts, request-rate controls, and surge protection.
• Review access logs for historical spikes in HTTP 101 Switching Protocols responses, repeated WebSocket upgrade attempts, and unusual long-duration connections from the same source networks.
• Create an operational runbook for resource-exhaustion events that includes safe restart procedures, temporary blocking rules, and capacity checks.
• Because there is no KEV listing, ransomware association, or mature public exploit noted in the provided data, treat this as an availability-hardening priority rather than an emergency code-execution incident unless local telemetry shows active abuse.