CVE-2023-46589 is an HTTP request smuggling vulnerability in Apache Tomcat, caused by incorrect parsing of HTTP trailer headers that exceed the header size limit, which can make Tomcat treat one request as several when it sits behind a reverse proxy. The flaw matters most in the common architecture where a proxy or load balancer forwards traffic to Tomcat, because the proxy and Tomcat can disagree about where one request ends and the next begins. If you run Java web applications on Tomcat, this is worth patching promptly, and the fix is a straightforward version upgrade.
Request smuggling is one of the more subtle web vulnerabilities, so it helps to understand the specific parsing mistake at the heart of this CVE.
What HTTP trailer headers are
Most HTTP headers arrive before the message body. Trailer headers are the exception: in a chunked transfer-encoded message, the sender can place additional headers after the body, in a trailer section following the final chunk. They are legitimate and defined by the HTTP specification, used for things like integrity checksums computed while streaming.
Because they are rare, trailer parsing is a lightly exercised code path in many servers, which is exactly the kind of place bugs hide. CVE-2023-46589 is one of those bugs.
The parsing mistake
According to the NVD entry and the Apache advisory, the problem is that a trailer header exceeding the maximum permitted header size caused Tomcat to parse the request incorrectly. Instead of rejecting the oversized trailer cleanly, Tomcat's parser mishandled it in a way that could cause the server to interpret a single HTTP request as multiple requests.
That desynchronization is the entire vulnerability. When Tomcat sees "two requests" where the front-end proxy saw "one request," an attacker can hide a second request inside the body region of the first. The proxy forwards what it believes is one benign request; Tomcat splits it and processes the smuggled request as if it were separate, legitimate traffic.
Why request smuggling is dangerous
The impact depends on the deployment, but request smuggling behind a reverse proxy enables several attacks:
Bypassing front-end security controls. If the proxy enforces authentication, WAF rules, or path restrictions, a smuggled request that the proxy never fully inspected can reach an endpoint the proxy would otherwise have blocked.
Request queue poisoning. In a keep-alive connection reused across users, a smuggled partial request can attach to the next user's request, causing one user to receive a response meant for another or triggering unintended actions in another user's session.
Cache poisoning. A smuggled request can trick a caching layer into storing a malicious response against a legitimate URL, which is then served to every subsequent visitor.
The severity of any individual instance depends heavily on what sits in front of Tomcat and how connections are pooled, which is why request smuggling findings deserve environment-specific analysis rather than a blanket severity label.
Affected versions and the fix
Based on the published advisory, CVE-2023-46589 affects these Apache Tomcat version ranges:
- 8.5.0 through 8.5.95
- 9.0.0-M1 through 9.0.82
- 10.1.0-M1 through 10.1.15
- 11.0.0-M1 through 11.0.0-M10
The fixed releases are:
- 8.5.96 or later
- 9.0.83 or later
- 10.1.16 or later
- 11.0.0-M11 or later
The remediation is to upgrade Tomcat to a fixed release on your line. There is no configuration workaround that fully closes the parsing defect, so patching is the answer. Check your running version directly rather than trusting deployment notes:
# from the Tomcat install directory
./bin/version.sh
Finding vulnerable Tomcat in your estate
Tomcat reaches you through several paths, and not all of them are obvious. It may be installed directly, bundled inside a Spring Boot executable JAR as embedded Tomcat, or pulled into a container base image. That variety is why a single apt list check is insufficient.
For Maven projects, the embedded Tomcat version is visible in the dependency tree:
mvn dependency:tree | grep tomcat
For container images and deployed servers, a scanner that inspects both OS packages and application dependencies will catch a vulnerable Tomcat wherever it hides. An SCA tool such as Safeguard can flag an affected tomcat-embed-core pulled in transitively by a Spring Boot version, which is the most common way this CVE reaches modern applications without anyone installing Tomcat on purpose. The SCA product page explains transitive detection, and our academy has material on triaging framework-level CVEs.
Defense in depth around request smuggling
Patching Tomcat closes this specific hole, but request smuggling as a class benefits from hardening the whole chain. Prefer a reverse proxy that normalizes or rejects ambiguous requests. Disable trailer support where you do not need it. Where possible, avoid reusing back-end connections across different client requests, which limits queue-poisoning impact. And keep both the proxy and the application server patched, since a smuggling bug on either side of the pair enables the same attack.
FAQ
What causes CVE-2023-46589?
It is caused by Apache Tomcat incorrectly parsing an HTTP trailer header that exceeds the maximum header size limit. The mishandling can lead Tomcat to interpret a single HTTP request as multiple requests, enabling request smuggling when Tomcat is behind a reverse proxy.
Which Tomcat versions are affected by CVE-2023-46589?
Tomcat 8.5.0 through 8.5.95, 9.0.0-M1 through 9.0.82, 10.1.0-M1 through 10.1.15, and 11.0.0-M1 through 11.0.0-M10. Upgrade to 8.5.96, 9.0.83, 10.1.16, or 11.0.0-M11 (or later on your respective line) to fix it.
Is CVE-2023-46589 exploitable without a reverse proxy?
The most impactful attacks require a reverse proxy or load balancer in front of Tomcat, because request smuggling exploits a disagreement between two servers about request boundaries. A standalone Tomcat is less exposed, but you should still upgrade, since deployment topologies change and the parsing defect remains.
How do I know if my application uses a vulnerable Tomcat?
Check the running version with version.sh, and for embedded Tomcat (common in Spring Boot) inspect the dependency tree for tomcat-embed-core. Container images should be scanned with a tool that reads application dependencies, not just OS packages, since Tomcat is frequently pulled in transitively.