CVE-2021-30639: Apache Tomcat DoS Vulnerability

CVE-2021-30639 Overview

A vulnerability in Apache Tomcat allows an attacker to remotely trigger a denial of service condition. An error introduced as part of a change to improve error handling during non-blocking I/O meant that the error flag associated with the Request object was not reset between requests. This meant that once a non-blocking I/O error occurred, all future requests handled by that request object would fail. Users were able to trigger non-blocking I/O errors, e.g., by dropping a connection, thereby creating the possibility of triggering a DoS. Applications that do not use non-blocking I/O are not exposed to this vulnerability.

Critical Impact

Attackers can remotely cause persistent denial of service by triggering non-blocking I/O errors that affect all subsequent requests processed by the same Request object, potentially rendering web applications unavailable.

Affected Products

• Apache Tomcat 10.0.3 to 10.0.4
• Apache Tomcat 9.0.44
• Apache Tomcat 8.5.64
• McAfee ePolicy Orchestrator 5.10.0 (including updates 1-10)
• Oracle Big Data Spatial and Graph

Discovery Timeline

• 2021-07-12 - CVE-2021-30639 published to NVD
• 2024-11-21 - Last updated in NVD database

Technical Details for CVE-2021-30639

Vulnerability Analysis

This denial of service vulnerability stems from improper exception handling within Apache Tomcat's non-blocking I/O implementation. The flaw exists in how the server manages error states during asynchronous request processing. When a non-blocking I/O operation encounters an error—such as a client unexpectedly dropping a connection—the error flag on the Request object is set but never cleared for subsequent requests.

The vulnerability is classified under CWE-755 (Improper Handling of Exceptional Conditions), reflecting the core issue of failing to properly manage error states. Because the Request object is reused across multiple requests for performance optimization, the persistent error flag causes all future requests handled by that object to fail immediately, regardless of their validity.

Root Cause

The root cause lies in a regression introduced during improvements to error handling for non-blocking I/O operations. The code change failed to implement proper state cleanup between request cycles. Specifically, the error flag associated with the Request object was designed to track I/O errors during asynchronous processing, but the logic to reset this flag upon request completion was either missing or improperly implemented. This oversight violates the principle that each request should start with a clean state, leading to error state leakage between independent requests.

Attack Vector

The attack vector is network-based and requires no authentication or user interaction, making it relatively easy to exploit. An attacker can trigger this vulnerability through the following approach:

1. Establish a connection to the vulnerable Tomcat server hosting an application that uses non-blocking I/O (such as async servlets or WebSocket endpoints)
2. Initiate a request that triggers non-blocking I/O processing
3. Abruptly terminate the connection during the non-blocking operation (e.g., by sending a TCP RST or simply closing the socket)
4. This causes an I/O error that sets the error flag on the Request object
5. All subsequent requests routed to that Request object will fail, effectively causing a denial of service

The attack can be amplified by repeatedly triggering errors across multiple Request objects in the server's pool, progressively degrading service availability until the application becomes completely unresponsive.

Detection Methods for CVE-2021-30639

Indicators of Compromise

• Unusual patterns of connection drops followed by increased HTTP 500 errors
• Elevated request failure rates in application logs without corresponding backend errors
• Multiple simultaneous request failures across different clients being served by the same Tomcat instance
• Log entries indicating non-blocking I/O exceptions such as IOException during async processing

Detection Strategies

• Monitor Tomcat access logs for sudden increases in 5xx error responses without corresponding application-level failures
• Implement alerting on connection reset patterns combined with elevated error rates
• Track request processing metrics to identify Request objects exhibiting persistent failure patterns
• Review catalina.out and application logs for non-blocking I/O related exceptions during timeframes with elevated error counts

Monitoring Recommendations

• Configure application performance monitoring (APM) to track async servlet and WebSocket endpoint health metrics
• Set up alerts for abnormal connection termination rates on Tomcat listener ports
• Monitor thread pool and connector statistics for signs of degraded request handling capacity
• Implement synthetic monitoring to proactively detect service availability degradation

How to Mitigate CVE-2021-30639

Immediate Actions Required

• Upgrade Apache Tomcat to a patched version: 10.0.5 or later, 9.0.45 or later, or 8.5.65 or later
• If immediate patching is not possible, temporarily disable non-blocking I/O features in affected applications
• Review applications for use of async servlets, WebSocket endpoints, or other non-blocking I/O functionality
• Monitor server logs for signs of exploitation attempts while planning upgrades

Patch Information

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

• Apache Tomcat 10.x: Upgrade to version 10.0.5 or later
• Apache Tomcat 9.x: Upgrade to version 9.0.45 or later
• Apache Tomcat 8.5.x: Upgrade to version 8.5.65 or later

For McAfee ePolicy Orchestrator deployments, refer to the McAfee Security Advisory SB10366 for specific update guidance. Oracle customers using Big Data Spatial and Graph should consult the Oracle CPU January 2022 Security Alerts for remediation instructions.

Workarounds

• Disable non-blocking I/O in applications by converting async servlets to synchronous implementations where feasible
• Implement connection rate limiting at the load balancer or firewall level to slow potential exploitation attempts
• Deploy web application firewalls (WAF) with rules to detect and block abnormal connection termination patterns
• Isolate affected Tomcat instances behind reverse proxies with enhanced connection handling

# Verify current Tomcat version
catalina.sh version

# After upgrading, verify the new version
# Expected output should show 10.0.5+, 9.0.45+, or 8.5.65+ depending on your branch