Yes. A single HTTP request can make a website lose track of which responses should go to which users, resulting in massive disclosure of confidential information. This typically results in users being randomly logged into other live user's accounts.

HTTP Request Smuggling also enables attackers to poison your website's cache with malicious JavaScript. This typically gives them persistent control over every page on your website, and lets them steal passwords and credit card details. For example, we were previously able to compromise PayPal's login page.

No. Time has proven we can't patch HTTP/1.1 to safety - more vulnerabilities are on the way. Please refer to the whitepaper for our full perspective on this.

No. Wrapping HTTP/1.1 in TLS has no effect on this vulnerability.

We know some major vendors don't support upstream HTTP/2 yet, including nginx, Akamai, CloudFront, and Fastly.

First, scan your website with HTTP Request Smuggler 3.0 to identify imminent threats. Consider setting up regular scans going forwards - we will update this tool with future techniques as they become known.

Then, explore the product documentation and enable any relevant HTTP/1.1 normalisation features. Note that you can significantly reduce the threat posed by HTTP Request Smuggling by disabling upstream connection reuse, but this may affect performance.

Finally, engage with your server vendor to request support for upstream HTTP/2, and ask if they have any recommended mitigations such as request validation or normalisation. Note that you can significantly reduce the threat posed by HTTP Request Smuggling by disabling upstream connection reuse, but this may affect performance.

End-to-end HTTP/2 makes desync vulnerabilities much rarer. This is because HTTP/2 has very little room for ambiguity about the length of each message. Therefore, it's significantly less likely that a bug in a HTTP/2 server poses a major security risk. So far, most vulnerabilities found in HTTP/2 implementations are DoS flaws - an attack class that is less relevant to upstream connections.

You do not need to disable support for HTTP/1.1 between the client and your edge server. This is low risk as connections to your edge server are rarely shared between different users.

Reverse proxies typically route requests from different users over a single shared pool of connections to back-end servers. This mingles attacker's requests with those from legitimate users. Also, front-end servers often have web caches which amplify the danger by enabling persistent compromise.

Fairly. It might have a client-side desync vulnerability, but these are relatively rare.

Yes, provided the reverse-proxy is reusing upstream connections.

Not reliably. In fact, we have observed some WAFs that introduce desync vulnerabilities to otherwise secure systems.

No. This research is highlighting a threat that, while serious, has existed for years. The coordinated tool and whitepaper publication is intended to ensure you can secure your web assets quickly, then work towards the long-term solution.