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
Accept-Encoding: gzip, deflate
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
Transfer-Encoding : chunked
POST /api/v1/some-endpoint HTTP/1.1
Note a few things:
- this is HTTP 1.1
- the space in the
Transfer-Encodingheader before the colon
- the presence of the
- 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!