CVE-2020-13935: Apache Tomcat WebSocket DoS Vulnerability

CVE-2020-13935 Overview

CVE-2020-13935 is a Denial of Service vulnerability affecting Apache Tomcat's WebSocket implementation. The payload length in WebSocket frames is not correctly validated, allowing attackers to send specially crafted requests with invalid payload lengths that trigger an infinite loop in the server. Multiple requests exploiting this vulnerability can lead to complete service unavailability.

This vulnerability impacts a wide range of Apache Tomcat versions across multiple major release branches, including versions 10.0.0-M1 through 10.0.0-M6, 9.0.0.M1 through 9.0.36, 8.5.0 through 8.5.56, and 7.0.27 through 7.0.104. The extensive version coverage and network-accessible attack vector make this a significant concern for organizations running WebSocket-enabled Tomcat deployments.

Critical Impact

Unauthenticated remote attackers can cause complete denial of service by sending malformed WebSocket frames, triggering infinite loops that exhaust server resources.

Affected Products

• Apache Tomcat 10.0.0-M1 to 10.0.0-M6
• Apache Tomcat 9.0.0.M1 to 9.0.36
• Apache Tomcat 8.5.0 to 8.5.56
• Apache Tomcat 7.0.27 to 7.0.104
• Debian Linux 9.0 and 10.0
• Canonical Ubuntu Linux 16.04 ESM and 20.04 LTS
• openSUSE Leap 15.1 and 15.2
• McAfee ePolicy Orchestrator 5.9.x and 5.10.x
• Oracle MySQL Enterprise Monitor, Blockchain Platform, and various Oracle products

Discovery Timeline

• July 14, 2020 - CVE-2020-13935 published to NVD
• November 21, 2024 - Last updated in NVD database

Technical Details for CVE-2020-13935

Vulnerability Analysis

This vulnerability stems from improper validation of WebSocket frame payload lengths within Apache Tomcat's WebSocket implementation (CWE-835: Loop with Unreachable Exit Condition). When processing incoming WebSocket frames, the server fails to adequately validate the payload length field before entering processing loops. An attacker can exploit this by sending WebSocket frames containing malformed or invalid payload length values that cause the server to enter an infinite loop condition.

The WebSocket protocol (RFC 6455) specifies that frames include a payload length field that indicates the size of the data following the header. Tomcat's implementation did not properly validate these length values against expected boundaries, allowing attackers to craft frames that bypass normal termination conditions in the frame processing logic.

Root Cause

The root cause is insufficient input validation in the WebSocket frame parsing code. When Tomcat receives a WebSocket frame, it reads the payload length field but does not properly validate it before proceeding with frame processing. Invalid payload length values can cause loop control logic to fail, resulting in the server entering an infinite loop while attempting to process the malformed frame. This represents a classic input validation vulnerability where external untrusted data is used to control program flow without proper sanitization.

Attack Vector

The attack is executed remotely over the network without requiring authentication. An attacker establishes a WebSocket connection to a vulnerable Tomcat server and then sends specially crafted WebSocket frames with invalid payload length values. The vulnerability can be exploited as follows:

1. The attacker initiates a WebSocket handshake with the target Tomcat server
2. Once the connection is established, the attacker sends malformed WebSocket frames with manipulated payload length fields
3. The server attempts to process these frames and enters an infinite loop due to the invalid length values
4. Multiple such requests can exhaust server threads and resources, leading to complete denial of service

The attack does not require any user interaction or privileged access, making it highly exploitable in exposed environments.

Detection Methods for CVE-2020-13935

Indicators of Compromise

• Unexpected CPU spikes on Tomcat server processes without corresponding legitimate traffic
• Tomcat worker threads becoming unresponsive or stuck in processing states
• WebSocket connection logs showing unusual connection patterns or malformed requests
• Server health checks failing while the Tomcat process continues running

Detection Strategies

• Monitor Tomcat thread pool utilization for abnormal exhaustion patterns
• Implement application-level logging for WebSocket frame processing errors and exceptions
• Deploy network intrusion detection rules to identify malformed WebSocket frame patterns
• Configure SentinelOne agents to monitor for process anomalies indicative of infinite loop conditions

Monitoring Recommendations

• Enable detailed WebSocket debug logging in Tomcat to capture frame processing anomalies
• Set up alerts for Tomcat thread pool exhaustion (connector thread count reaching maximum)
• Monitor server resource utilization trends to establish baselines and detect DoS conditions
• Implement health check endpoints that test WebSocket functionality specifically

How to Mitigate CVE-2020-13935

Immediate Actions Required

• Upgrade Apache Tomcat to patched versions: 10.0.0-M7+, 9.0.37+, 8.5.57+, or 7.0.105+
• Review all applications and products that embed Apache Tomcat for vulnerable versions
• Implement rate limiting on WebSocket connections at the network or load balancer level
• Consider temporarily disabling WebSocket functionality if not required for business operations

Patch Information

Apache has released patched versions addressing this vulnerability. Organizations should upgrade to the following minimum versions:

• Apache Tomcat 10.x: Upgrade to 10.0.0-M7 or later
• Apache Tomcat 9.x: Upgrade to 9.0.37 or later
• Apache Tomcat 8.5.x: Upgrade to 8.5.57 or later
• Apache Tomcat 7.x: Upgrade to 7.0.105 or later

For downstream products embedding Tomcat, consult vendor advisories including the Oracle Critical Patch Updates, McAfee Security Bulletin SB10332, Debian Security Advisory DSA-4727, and Ubuntu Security Notices.

Workarounds

• Deploy a Web Application Firewall (WAF) with rules to inspect and validate WebSocket frame structures
• Implement connection rate limiting at the load balancer to restrict WebSocket connection frequency
• Configure network segmentation to limit exposure of Tomcat WebSocket endpoints
• Disable the WebSocket protocol in Tomcat if WebSocket functionality is not required by your applications

# Example: Disable WebSocket support in Tomcat by removing the WebSocket JARs
# Navigate to Tomcat lib directory and remove WebSocket implementation
cd $CATALINA_HOME/lib
mv websocket-api.jar websocket-api.jar.disabled
mv tomcat-websocket.jar tomcat-websocket.jar.disabled

# Restart Tomcat to apply changes
$CATALINA_HOME/bin/shutdown.sh
$CATALINA_HOME/bin/startup.sh