CVE-2021-33037: HTTP request smuggling in Apache Tomcat

Apache Tomcat, one of the most widely deployed Java servlet containers on the internet, was found in 2021 to mishandle HTTP trailer headers in a way that opened the door to HTTP request smuggling. Tracked as CVE-2021-33037, the flaw allowed a specially crafted request to be interpreted differently by Tomcat than by an upstream proxy or load balancer sitting in front of it — the textbook precondition for request smuggling. In the right deployment topology, that desync can let an attacker slip a second, hidden request past security controls, poison another user's session, bypass authentication checks enforced at the proxy layer, or achieve cache poisoning against shared infrastructure.

Request smuggling bugs are disproportionately dangerous relative to how "quiet" they look in a diff, because the vulnerability isn't really in Tomcat alone — it's in the disagreement between Tomcat and whatever sits in front of it (an Nginx, Apache httpd/mod_proxy, HAProxy, CDN, or custom reverse proxy). CVE-2021-33037 is a good case study in why software supply chain visibility has to extend past "is this component patched" and into "how is this component actually wired into my architecture."

What the vulnerability actually was

The root cause was in how Tomcat parsed HTTP trailer headers — the optional headers that can follow the body of a chunked-encoded request, defined in RFC 7230. Tomcat's parsing of trailer fields did not fully conform to the specification, and when Tomcat processed trailers alongside a front-end proxy that also handled trailers non-compliantly, the two components could end up disagreeing about where one request ends and the next one begins. That desynchronization is the mechanism behind classic HTTP request smuggling (sometimes classified as TE.TE, CL.TE, or trailer-based smuggling variants). Because the exploitability of the bug depended on the specific proxy paired with Tomcat, impact varied by deployment — some configurations were not exploitable at all, while others allowed meaningful request smuggling.

This is a useful reminder that request smuggling CVEs are frequently conditional vulnerabilities: the CVE describes a necessary flaw in one component, but real-world exploitability depends on the full chain of software sitting between the client and the application server.

Affected versions and components

CVE-2021-33037 affects the following Apache Tomcat release lines:

• Apache Tomcat 10.0.0-M1 through 10.0.6
• Apache Tomcat 9.0.0.M1 through 9.0.46
• Apache Tomcat 8.5.0 through 8.5.66

The issue was corrected in Tomcat 10.0.7, 9.0.47, and 8.5.67. Older, end-of-life branches (such as Tomcat 7.x) were not covered by this specific advisory; organizations still running unsupported Tomcat lines should treat that as its own separate risk rather than assuming the fix applies retroactively.

Because Tomcat is embedded inside a huge number of downstream products — application servers, CI/CD tooling, internal Java services, and commercial software that bundles an embedded Tomcat runtime — the practical "affected component" list for most organizations is larger than "servers where we run Tomcat directly." Any product with an embedded Tomcat dependency in the vulnerable range inherits the exposure, whether or not the operations team is aware Tomcat is running underneath it.

CVSS, EPSS, and KEV context

NVD's published CVSS v3.1 base score for CVE-2021-33037 rates it in the Critical range (9.8), reflecting that a successful smuggling attack could affect confidentiality, integrity, and availability with no authentication and no user interaction required — though, as noted above, real-world exploitability is gated by the specific proxy configuration in front of Tomcat, which is not something CVSS captures well for this class of bug.

At the time of writing, CVE-2021-33037 does not appear on CISA's Known Exploited Vulnerabilities (KEV) catalog, and there is no widely reported evidence of mass in-the-wild exploitation tied specifically to this CVE. That doesn't mean it's safe to deprioritize — request smuggling vulnerabilities are notoriously hard to detect from server logs, and lack of public exploitation reporting is not the same as lack of exploitation. Teams should weigh this CVE by exposure (is Tomcat internet-facing, and is it behind a proxy that also touches trailers?) rather than relying solely on KEV absence as a signal of low urgency.

Timeline

• Apache Tomcat maintainers identified and fixed the trailer-header parsing defect, releasing patched versions 8.5.67, 9.0.47, and 10.0.7.
• The issue was assigned CVE-2021-33037 and published to the National Vulnerability Database, with an accompanying advisory on the Apache Tomcat security page detailing the affected version ranges and the request-smuggling classification.
• Downstream vendors that bundle Tomcat (application servers, monitoring tools, enterprise Java platforms) issued their own advisories and patches over the following weeks and months as they rebased onto fixed Tomcat versions — a common lag pattern for embedded-dependency CVEs.

Because Apache's own advisory is the authoritative source for exact publication dates and the fine print of affected configurations, teams doing formal risk assessments should cross-reference the official Apache Tomcat security page rather than relying on secondary summaries alone.

Remediation steps

1. Inventory every Tomcat instance, including embedded ones. Don't just check servers you manage directly — check vendor products, internal tools, and CI/CD components for bundled Tomcat runtimes. Software composition analysis (SCA) tooling that resolves transitive and embedded dependencies, not just top-level pom.xml/build.gradle declarations, is essential here.
2. Upgrade to a fixed release. Move to Tomcat 8.5.67+, 9.0.47+, or 10.0.7+ depending on your major line. If you're on an unsupported branch (e.g., 7.x), this CVE is a good forcing function to plan a migration off end-of-life Tomcat entirely.
3. Audit your reverse proxy configuration. Because exploitability hinges on proxy behavior, review how your Nginx, Apache httpd, HAProxy, or CDN layer handles Transfer-Encoding, Content-Length, and trailer headers. Ensure the proxy either strips/normalizes trailers before forwarding or is itself patched against equivalent smuggling classes.
4. Disable chunked trailer support where it isn't needed. If your application doesn't rely on HTTP trailers, consider proxy-level rules that reject or strip trailer fields outright, reducing the smuggling surface regardless of backend patch status.
5. Add smuggling-aware detection. Standard WAF signatures often miss desync attacks because each individual request looks well-formed. Consider differential testing (sending the same request through your full proxy chain and comparing how each hop parses it) as part of periodic security testing.
6. Re-run SCA scans post-patch to confirm remediation, since embedded Tomcat versions can silently regress during unrelated dependency updates or container base image changes.

How Safeguard Helps

CVE-2021-33037 is a clean illustration of why supply chain security can't stop at "is the direct dependency patched." Tomcat is frequently several layers deep — vendored into a platform, bundled inside a container base image, or pulled in transitively by a framework — and the exploitability of a request smuggling bug depends on infrastructure context that a simple version check won't surface.

Safeguard is built for exactly this gap. Our software composition analysis continuously resolves both direct and transitive dependencies across your codebase and build artifacts, so an embedded Tomcat instance inside a third-party JAR or container image gets flagged with the same rigor as a top-level dependency declared in your build file. When a CVE like this one is published, Safeguard correlates it against your actual SBOM inventory — not a point-in-time scan — so you can see immediately which services, images, and vendor products are affected, prioritize based on internet-facing exposure and real reachability rather than CVSS score alone, and track remediation through to confirmed patched versions.

Because request smuggling risk is architecture-dependent, Safeguard's reporting also surfaces the deployment context you need to make a real risk call: which of your affected Tomcat instances sit behind a reverse proxy, which are internal-only, and which have already been remediated. That turns a CVE advisory that would otherwise require manual cross-referencing across teams into a prioritized, auditable remediation workflow — the kind of continuous supply chain visibility that turns "we think we patched everything" into "we can prove it."