CVE-2021-33037: Apache Tomcat Request Smuggling Flaw

CVE-2021-33037 Overview

CVE-2021-33037 is an HTTP Request Smuggling vulnerability affecting Apache Tomcat versions 10.0.0-M1 to 10.0.6, 9.0.0.M1 to 9.0.46, and 8.5.0 to 8.5.66. The vulnerability stems from incorrect parsing of the HTTP Transfer-Encoding request header under certain circumstances, which can lead to request smuggling attacks when Tomcat is deployed behind a reverse proxy.

The flaw manifests in three specific ways: Tomcat incorrectly ignored the transfer encoding header if the client declared it would only accept an HTTP/1.0 response; Tomcat honored the identity encoding when it should not have; and Tomcat did not ensure that chunked encoding was the final encoding when present. These parsing inconsistencies between Tomcat and front-end proxies create the conditions necessary for request smuggling attacks.

Critical Impact

Attackers can exploit HTTP parsing discrepancies between reverse proxies and Apache Tomcat to smuggle malicious requests, potentially bypassing security controls, poisoning web caches, and hijacking user sessions.

Affected Products

• Apache Tomcat 10.0.0-M1 to 10.0.6
• Apache Tomcat 9.0.0.M1 to 9.0.46
• Apache Tomcat 8.5.0 to 8.5.66
• Apache TomEE 8.0.6
• Oracle Agile PLM 9.3.6
• Oracle Communications Cloud Native Core Policy 1.14.0
• Oracle MySQL Enterprise Monitor
• Oracle Managed File Transfer 12.2.1.3.0 and 12.2.1.4.0
• McAfee ePolicy Orchestrator (multiple versions)
• Debian Linux 9.0 and 10.0

Discovery Timeline

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

Technical Details for CVE-2021-33037

Vulnerability Analysis

This HTTP Request Smuggling vulnerability (CWE-444) arises from parsing inconsistencies in how Apache Tomcat processes the Transfer-Encoding HTTP header. When Tomcat is deployed behind a reverse proxy (such as Apache HTTP Server, nginx, or a load balancer), differences in how each component interprets ambiguous HTTP requests can be exploited by attackers.

The vulnerability enables attackers to craft specially constructed HTTP requests that are interpreted differently by the front-end proxy and the back-end Tomcat server. This desynchronization allows malicious request content to be "smuggled" past security controls that operate at the proxy layer.

Root Cause

The root cause lies in three specific parsing behaviors in Tomcat's HTTP request handling:

1. HTTP/1.0 Response Bypass: When a client indicated it would only accept HTTP/1.0 responses via the request headers, Tomcat incorrectly ignored the Transfer-Encoding header entirely. This created a parsing mismatch with proxies that still honored the header.

2. Identity Encoding Acceptance: Tomcat improperly honored the identity transfer encoding value. According to RFC specifications, identity should not be used with Transfer-Encoding, and accepting it creates ambiguity in request processing.

3. Chunked Encoding Position: Tomcat failed to enforce that when chunked encoding was present, it must be the final (outermost) encoding. This allowed attackers to construct requests with multiple transfer encodings that were processed inconsistently.

Attack Vector

The attack vector is network-based and requires no authentication or user interaction. An attacker can exploit this vulnerability by sending crafted HTTP requests to a web application running on an affected Tomcat instance behind a reverse proxy.

A typical attack scenario involves constructing an HTTP request with conflicting or ambiguous Transfer-Encoding and Content-Length headers. The front-end proxy interprets the request boundary in one way, while Tomcat interprets it differently. This allows the attacker to inject a second, hidden request that Tomcat processes as if it came from a legitimate user.

The consequences of successful exploitation include:

• Security Control Bypass: Web application firewalls and access controls at the proxy layer can be circumvented
• Cache Poisoning: Malicious content can be cached and served to other users
• Session Hijacking: Attacker requests can be associated with victim user sessions
• Credential Theft: Sensitive data from other users' requests may be captured

Request smuggling attacks targeting the Transfer-Encoding header manipulation typically involve sending requests with malformed chunked encoding or multiple conflicting encoding declarations that exploit the parsing differences between the proxy and application server.

Detection Methods for CVE-2021-33037

Indicators of Compromise

• Unusual HTTP requests with multiple or conflicting Transfer-Encoding headers in access logs
• HTTP requests containing both Transfer-Encoding: chunked and Content-Length headers simultaneously
• Requests specifying Transfer-Encoding: identity which should not be used in normal traffic
• Evidence of response splitting or unexpected response content in proxy logs
• Anomalous HTTP/1.0 version specifications combined with transfer encoding headers

Detection Strategies

• Configure web application firewalls (WAFs) to detect and block requests with ambiguous or duplicate Transfer-Encoding headers
• Implement log analysis rules to identify requests with both Content-Length and Transfer-Encoding headers
• Deploy network intrusion detection signatures targeting HTTP request smuggling patterns
• Enable detailed HTTP request logging on both reverse proxies and Tomcat to identify parsing discrepancies
• Monitor for unexpected 400 Bad Request responses that may indicate smuggling attempts

Monitoring Recommendations

• Aggregate and correlate logs between front-end proxies and Tomcat backend servers to identify request boundary mismatches
• Set up alerting for requests containing the identity transfer encoding value
• Monitor for session anomalies where user actions appear to originate from different IP addresses
• Implement cache monitoring to detect potential cache poisoning incidents
• Review access patterns for signs of security control bypass such as unauthorized access to restricted endpoints

How to Mitigate CVE-2021-33037

Immediate Actions Required

• Upgrade Apache Tomcat to version 10.0.7 or later, 9.0.48 or later, or 8.5.68 or later immediately
• Review reverse proxy configurations to normalize incoming Transfer-Encoding headers before forwarding to Tomcat
• Configure front-end proxies to reject requests with ambiguous or duplicate transfer encoding declarations
• Audit web application firewall rules to ensure HTTP request smuggling attack patterns are blocked
• Verify that all components in the request chain (proxies, load balancers, application servers) are updated and consistently configured

Patch Information

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

• Apache Tomcat 10.x: Upgrade to version 10.0.7 or later
• Apache Tomcat 9.x: Upgrade to version 9.0.48 or later
• Apache Tomcat 8.5.x: Upgrade to version 8.5.68 or later

For detailed information, refer to the Apache Tomcat Announce Thread. Organizations using Oracle products that bundle Tomcat should consult the relevant Oracle Critical Patch Updates including Oracle CPU July 2021, Oracle CPU October 2021, Oracle CPU January 2022, and Oracle CPU April 2022.

Linux distributions have also released patches - see Debian DSA-4952 and Debian LTS Security Announcement for Debian-specific guidance.

Workarounds

• Configure reverse proxies to normalize and sanitize Transfer-Encoding headers, rejecting requests with multiple values or the identity encoding
• Implement strict HTTP request validation at the proxy layer to drop ambiguous requests before they reach Tomcat
• Consider disabling HTTP/1.0 support if not required by legitimate clients to reduce attack surface
• Deploy a web application firewall with rules specifically targeting HTTP request smuggling techniques
• If using a load balancer or CDN, enable options that enforce consistent HTTP parsing across all components

# Example nginx configuration to mitigate request smuggling
# Add to server block configuration

# Reject requests with multiple Transfer-Encoding headers
# or Transfer-Encoding with Content-Length
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_set_header Transfer-Encoding $http_transfer_encoding;

# Normalize chunked encoding handling
proxy_request_buffering on;

# For Apache HTTP Server, add to configuration:
# RequestHeader unset Transfer-Encoding early
# RequestHeader unset Content-Length early