CVE-2021-33037

What it actually does

CVE-2021-33037 is an HTTP request smuggling flaw in Apache Tomcat caused by incorrect parsing and validation of the Transfer-Encoding request header when Tomcat is deployed behind a reverse proxy or other front-end HTTP intermediary. In affected versions, Tomcat may ignore Transfer-Encoding under certain HTTP/1.0-related conditions, accept the obsolete identity transfer coding, or fail to require chunked to be the final transfer coding. If the proxy and Tomcat disagree about where one HTTP request ends and the next begins, an attacker can desynchronize the connection and cause Tomcat to interpret attacker-controlled bytes as a separate request. The primary impact is integrity compromise of HTTP request routing and processing, including request queue poisoning, response confusion, bypass of proxy-layer controls, or unintended actions in another user's request context depending on application behavior.

Why it matters to the business

Organizations running affected Tomcat-based applications behind reverse proxies may be exposed to request routing manipulation that can undermine authentication, access control, caching, or audit assumptions at the application edge. While the CVSS score is moderate, the EPSS score is high, indicating meaningful likelihood of exploitation activity in the wild or strong exploitability signals. The affected ecosystem is broad because Tomcat is embedded or bundled in many commercial and open-source products, including Apache TomEE, Debian packages, multiple Oracle products, and McAfee ePolicy Orchestrator, so remediation often requires checking both directly managed Tomcat servers and vendor-packaged appliances or applications.

How an attack unfolds

An attacker sends specially crafted HTTP requests through a reverse proxy to an affected Tomcat backend. The malicious request uses ambiguous or invalid Transfer-Encoding combinations, such as identity, chunked in a non-final position, or Transfer-Encoding behavior that differs when HTTP/1.0 handling is involved. The front-end proxy and Tomcat parse the message body boundaries differently. As a result, part of the attacker's payload remains queued on the backend connection and is interpreted by Tomcat as the beginning of a subsequent request. The attacker can then smuggle a hidden request past proxy-layer inspection or access-control rules, interfere with the next request on the same connection, poison responses, or reach internal application paths that the reverse proxy was expected to protect. Successful exploitation depends heavily on proxy behavior, connection reuse, application routing, and whether sensitive actions are exposed through the Tomcat-hosted application.

How to fix it

Upgrade affected Apache Tomcat installations to a fixed release outside the vulnerable ranges. For Apache Tomcat, use Tomcat 10.0.7 or later, 9.0.48 or later, or 8.5.68 or later, as applicable, or a vendor-supported version containing the backported fix. For products that bundle Tomcat, apply the relevant vendor security update rather than replacing embedded libraries manually unless the vendor explicitly supports that approach. Also update downstream distributions and appliances that include Tomcat, including Apache TomEE, Debian packages, Oracle products, and McAfee ePolicy Orchestrator where applicable. As compensating controls, configure reverse proxies to reject malformed or ambiguous Transfer-Encoding headers, reject requests containing both Content-Length and Transfer-Encoding unless explicitly normalized safely, disable backend connection reuse where feasible for high-risk routes, enforce HTTP/1.1 parsing consistency, and ensure edge devices normalize or block obsolete transfer codings such as identity. Mitigations should be treated as temporary because safe request parsing must be enforced in Tomcat itself.

How to confirm the fix worked

Confirm the deployed Tomcat version is no longer in the affected ranges: 10.0.0-M1 through 10.0.6, 9.0.0.M1 through 9.0.46, or 8.5.0 through 8.5.66. Check both standalone Tomcat installations and embedded Tomcat versions inside vendor applications. Validate package manager versions, container image layers, application server banners where reliable, and runtime library metadata such as catalina.jar implementation version. In staging, test the reverse-proxy-to-Tomcat path with benign request-smuggling probes to confirm malformed Transfer-Encoding combinations are rejected consistently by the front end and backend. Review proxy configuration to ensure ambiguous Transfer-Encoding and Content-Length combinations are denied or normalized. After patching, confirm there are no remaining exposed services or container images running the vulnerable Tomcat branches.

Typical attack path

1. Identify an internet-facing or internally reachable service using Apache Tomcat behind a reverse proxy, load balancer, CDN, API gateway, or web application firewall.
2. Fingerprint the front-end and backend HTTP behavior by sending malformed requests and observing timing, response differences, connection reuse, or desynchronization symptoms.
3. Craft requests containing ambiguous Transfer-Encoding headers, including identity encodings, non-final chunked encodings, or conflicting message-length indicators.
4. Send the crafted request through the proxy so the proxy and Tomcat disagree about the request boundary.
5. Place an attacker-controlled HTTP request in the backend connection queue so Tomcat processes it as a separate request.
6. Use the smuggled request to bypass proxy-level restrictions, access internal routes, manipulate another user's request flow, poison cacheable responses, or trigger unintended application actions.
7. Repeat and tune the payload to the specific proxy/Tomcat/application combination to achieve reliable impact.

How to detect it

Investigating prior exploitation requires logs that preserve raw HTTP request headers, because normal access logs usually record only method, path, status, and user agent. Review reverse proxy, load balancer, CDN, WAF, API gateway, and Tomcat access/application logs for malformed Transfer-Encoding usage, especially requests containing Transfer-Encoding: identity, multiple Transfer-Encoding values, chunked followed by another coding, or both Content-Length and Transfer-Encoding. Look for clusters of 400/408/502/503 responses, backend connection resets, mismatched request and response pairs, unusual keep-alive behavior, unexpected access to internal-only routes, or requests appearing in Tomcat logs that are absent from proxy logs. Compare proxy-side and Tomcat-side logs by timestamp, source IP, connection identifier, request path, and status to identify desynchronization. In applications with authentication or session workflows, review suspicious actions that occurred immediately after malformed HTTP requests from the same source or on reused backend connections. If packet captures, WAF event payloads, or full request logging are available, search directly for ambiguous Transfer-Encoding headers and request bodies that contain a second HTTP request line such as GET / or POST / embedded after chunk terminators.

• Transfer-Encoding: identity
• Transfer-Encoding: chunked, identity
• Transfer-Encoding: identity, chunked
• Transfer-Encoding: chunked, gzip
• Transfer-Encoding: gzip, chunked
• Transfer-Encoding: chunked, chunked
• Content-Length:
• Transfer-Encoding:
• 0\r\n\r\nGET /
• 0\r\n\r\nPOST /
• HTTP/1.0\r\nTransfer-Encoding: chunked
• HTTP/1.0\r\nTransfer-Encoding: identity

What your security team should do

• Inventory all Tomcat-based services, including embedded Tomcat in commercial products and container images, prioritizing systems behind reverse proxies or load balancers.
• Patch or upgrade Apache Tomcat to 10.0.7+, 9.0.48+, or 8.5.68+, or apply vendor-provided fixed builds for bundled products.
• Prioritize internet-facing applications and authentication, API, administrative, payment, healthcare, telecom, and file-transfer systems because request smuggling can bypass edge controls in sensitive workflows.
• Harden reverse proxies, WAFs, CDNs, and API gateways to reject malformed Transfer-Encoding headers, obsolete identity transfer codings, non-final chunked encodings, and conflicting Content-Length plus Transfer-Encoding requests.
• Enable or temporarily increase logging of raw HTTP headers at the edge where privacy and performance constraints allow, because standard access logs often do not capture the evidence needed for request-smuggling investigations.
• Search historical proxy, WAF, and application logs for malformed Transfer-Encoding patterns and unexplained 400 responses, backend 5xx spikes, response desynchronization, or unusual access to paths normally blocked at the proxy.
• Add regression tests for HTTP request smuggling behavior to application edge validation pipelines so future proxy or application-server changes do not reintroduce parser discrepancies.