contactcontact

How your site can be hacked through HTTP/1.1 and how to prevent it

Security vulnerabilities can originate from many different sources. It can be an oversight or mistake from a developer, a flaw inherited from the architecture design, or an outdated third-party package to name a few. These are well-known vulnerability classes that can be mitigated through code review, automated package updates and design review. A type of vulnerability class that is harder to prevent is vulnerabilities originating from design flaws in the protocol itself or its implementation. These issues sometimes only show up when specific combinations of software interact. Research in 2025 has shown that this type of protocol and implementation flaw in HTTP/1.1 can be weaponized to compromise major CDNs and cloud providers. For one paper, the results were millions of affected domains and a bug bounty payout of more than $200,000 in a two week period. [1] This article describes how supporting HTTP/1.1 can lead to vulnerabilities, what you can do to check if you are vulnerable and what measures can be taken to prevent it from happening in your web application.

A problem of standards

The Hypertext Transfer Protocol (or HTTP) is the workhorse of the web and dates back to the early 90s. Most people will recognize it from the http:// and https:// prefix of URLs. It is the language that your browser uses to communicate with the website to download and render web pages. Since its inception, the web has undergone many changes. At the start of the web, the browser would often directly talk to a web server but today there are usually several layers of proxies in between, such as load balancers and caching servers. To keep up with the growth of the web, HTTP has changed to accommodate required functionality and improved performance. It changed from the older text based versions HTTP/0.9, 1.0, and 1.1, to binary framing in HTTP/2 and HTTP/3.

Figure 1: Example of an HTTP/1.1 request and response pair. [2]

Issues with HTTP/1.1 have been known for a long time. [3] In contrast to the binary frames of HTTP/2 and 3, a major aspect that enables attacks against HTTP/1.1 is that it is a text based protocol. HTTP/1.1 on the surface appears to be a simple protocol with a clearly structured request and a response. However, due to the many implementations of HTTP/1.1, different design choices often lead to slightly different interpretations of the standards. This is made worse by the fact that HTTP/1.1 is a text-based protocol and even within the HTTP/1.1 standard there were several different revisions. [4][5][6][7] Sometimes features described in an earlier standard are deprecated in a later standard, such as header line folding. [8] Since there have been several revisions of the standard even in the same HTTP/1.1 version, it is understandable that not all servers implemented the later changes, and they may thus interpret HTTP messages differently. For HTTP/2 this is less of an issue as the length of the message comes from the length field in the frame instead of a header.

How HTTP/1.1 request smuggling arises

Considering HTTP/1.1 implementations may differ quite significantly due to differences in interpretation of the standard and support for deprecated features, you may expect that a server would just ignore requests it cannot understand. Unfortunately, this is not always true. To show the consequences, we will focus on the weaponization of a specific implementation difference in HTTP/1.1: the interpretation of the HTTP message length.

In HTTP/1.1, the length of a message can be specified in two ways: using the Content-Length header and with the Transfer-Encoding header with the value "chunked". [9] The former is generally used when the length of the message is known beforehand, and the latter is often used during streams of data with unknown length. To prevent conflicting lengths, the standard states that the Transfer-Encoding header overrides the Content-Length header when both are present. [10] However, not every HTTP implementation may correctly follow the standard to the letter. Some implementations may still prioritize the Content-Length header even though a Transfer-Encoding header has been set or accept malformed header names. In this case, two servers may look at the same HTTP message and interpret the length of the message differently, as they prioritize different headers.

To exploit this behavior, HTTP desync often requires two or more servers are chained, such as a web proxy that forwards HTTP messages from different sources to the web server behind it. If these two HTTP implementations interpret the length of the HTTP messages differently, they could become out of sync. This attacks requires connection reuse between the front-end proxy and the back-end server, as this means messages of different users will be send over the same connection and can get mixed together. This is the underlying issue of HTTP desync attacks, also known under the common name of HTTP request smuggling. By crafting deliberately ambiguous messages, it is possible to abuse the difference in interpretation of the message length between the servers and thus inject or "smuggle" messages to the web server. As a result, an attacker could obtain the response of HTTP messages intended for other users or serve a genuine user the response of the attacker. It can thus lead to a hostile takeover of your website and theft of sensitive data.

Figure 2: Simplified example of a classic CL.TE HTTP request smuggling payload that bypasses access control on the frontend server to gain access to the /admin page. The frontend server respects the Content-Length header while the back-end server respects the Transfer-Encoding header.

More than a theoretical risk

Although this may appear abstract and theoretical, this attack class has been repeatedly demonstrated on real-world systems by security researchers and the consequences can be significant. In recent years, there has been more attention to desync attacks. The desync attack vector was first described in a whitepaper from 2005 and it already recognized the potential consequences. [3] Since the first paper was released, the topic has remained largely quiet and the attack class was not widely adopted with only a few HTTP request smuggling CVEs published in the years after. [11] According to James Kettle, looking back in his 2019 research paper, it was deemed difficult and risky due to expected collateral damage. [12] In that paper and accompanying presentation at DEF CON 27, he showed how this class of vulnerabilities can be exploited, providing a testing methodology and a toolset (the HTTP Request Smuggler). This resulted in a revival of the vulnerability class. Before 2019, 31 CVEs were published with the term "http request smuggling" and after the paper from James Kettle, there are 212 more (search performed on September 29, 2026). [11] This prompted many more research papers from various authors in the following years, including another paper by James Kettle in 2025 that further described the inherent issues with HTTP/1.1 with a call to action to completely discontinue the protocol. [1] In this latest research, several big CDNs were compromised with millions of websites that use this service were indirectly affected as well and very little they could do to prevent exploitation.

Whether these CVEs are widely exploited by malicious actors remains unclear. The Known Exploited Vulnerabilities (KEV) database lists two CVE entries when searching for request smuggling and related terms: CVE-2022-22536 and CVE-2023-46747. [13] For the latter, a security advisory by F5 states that the request smuggling vulnerability found by Praetorian is being actively exploited. [14][15] However, this is smuggling from HTTP/1.1 into the AJP protocol instead of HTTP/1.1 to HTTP/1.1 smuggling. From looking at public sources, it seems that this vulnerability class is not being actively exploited by threat actors. It may also be an underreported vulnerability class, as correct logging could be affected by the smuggled requests.

Doing a quick test

If you host the full stack yourself or have permission to test on a partially controlled stack, there are tools that can be used to detect smuggling issues. This can serve as another method for assurance besides a review of the application landscape. When performing these tests, I would highly recommend not running them on production, as they can disrupt the server state and severely affect users. Therefore, always run these tools on a representative testing or staging environment where you have permission to test. Whenever a significant change in architecture is made, such as swapping out a proxy, it may be worth performing another smuggling test.

The gold standard testing tool for HTTP desync is the HTTP Request Smuggler extension for Burp Suite. [16] Burp Suite is an HTTP proxy and security tool to test web applications. This extension in particular has automated scans that can detect the most common types of request smuggling vulnerabilities and it also works with the free version of Burp Suite. There are other public tools as well that do not use Burp Suite, such as Smuggler and HTTP2Smugl, which specifically looks for HTTP/2 to HTTP/1.1 downgrades. [17][18]

A quick test of HTTP/2 support on your web server is using a curl with the --http2 option:

curl -so /dev/null --http2 -w '%{http_version}\n' https://example.com

Impact assessment and migration to HTTP/2

The difficult part of assessing whether your own application is vulnerable to HTTP desync is the fact that it may not be clear or possible to know what protocol is used in every step between the browser and the web server.

If the stack is fully self-owned, including load balancers and caching servers, you can find through documentation whether these components support HTTP/2. For instance, if Apache is used as a proxy server, it has support for HTTP/2 and HAProxy does so as well. [19][20] Nginx also supports HTTP/2 for upstream since December 2025. [21] By using common technology stacks and well-maintained software, the risk of request smuggling is reduced as these configurations are frequently tested through testing frameworks such as HTTP Garden. [22]

It is important to verify for your specific stack that the whole chain between the browser and your application uses HTTP/2. This is because HTTP/2 requests can be rewritten from HTTP/2 to HTTP/1.1 and this introduces a separate set of downgrade attacks. [23] When implementing HTTP/2 from your reverse proxy to the web application, it is best to use HTTP/2 over TLS for this connection. If cleartext HTTP/2 is used with h2c, make sure that the proxy does not forward this header to prevent h2c request smuggling. [24][25]

If your web server does not support HTTP/2, you are limited to validation of HTTP messages to remove ambiguous components, such as the presence of both a Content-Length and Transfer-Encoding header. Unfortunately, this provides limited additional value and could be bypassed when new techniques are published. Another possible mitigation would be to disable upstream connection reuse. This means that requests from different users will go through different connections, which reduces the attack surface. Note that this may affect performance.

Often, you do not control the full stack yourself but have intermediary parties, such as Cloudflare for DoS prevention or a CDN such as Azure Front Door. This makes it harder to verify the full path, as the internal workings of a CDN are unknown. The only way to know is often by consulting the documentation. In this case for Azure Front Door, it states that HTTP/2 is used from the browser to Azure Front Door, but that HTTP/1.1 is used for the last mile to the web server. This therefore maintains the risk of HTTP request smuggling, even though they have mitigations in place. [26] For Cloudflare, it has the HTTP/2 to Origin option to enable upstream HTTP/2. [27] It thus depends on the CDN provider which options are available.

When analyzing your architecture, the use of HTTP/1.1 should thus be seen as a security risk. In a threat model, HTTP/1.1 should be treated in a similar manner as other insecure links are regarded, such as plaintext connections. These should be considered design weaknesses and points to be improved. For plaintext connections, a mitigation could be to implement a security layer such as TLS. For HTTP/1.1, a strong mitigation would be migrating to HTTP/2 or 3 or adding additional validation as a weaker mitigation. AWS has published a library that is built for providing this type of validation, which can be used as is or serve as a guideline. [28]

Post-migration steps

Assuming the transition of your stack is made from HTTP/1.1 to HTTP/2, does this mean there is no more risk? For a large part, yes. HTTP/2 is mostly a secure protocol and it protects against desync attacks as long as it is never downgraded to HTTP/1.1. There are other attacks that target HTTP/2 implementations specifically, but these appear to be mostly aimed at denial-of-service. [29][30] In future research, there can always be novel attack classes that show flaws in previously considered secure protocols. That is an inherent part of risk management and the way forward is to follow the current best practices.

Takeaways

  1. Treat HTTP/1.1 as a security risk and include it in the threat model of your application.
  2. Verify that your stack uses HTTP/2 for every component between the browser and the web server. This can be done through manual testing (e.g., with curl), by checking the server logs for incoming connections, or reading the documentation of each component to find HTTP/2 support and the relevant configuration items.
  3. When external parties are used, ensure that HTTP/2 is used here as well. This can often be found by searching for upstream HTTP/2 support. Since HTTP/2 rewriting to HTTP/1.1 can happen internally in a cloud provider, the cloud provider should have a public statement on whether it supports full HTTP/2. In practice, it will be hard to do anything about this if they do still use HTTP/1.1 other than requesting HTTP/2 support.

References

  1. James Kettle, "HTTP/1.1 Must Die: The Desync Endgame," PortSwigger Research, August 2025. Presented at Black Hat USA 2025 and DEF CON 33. https://portswigger.net/research/http1-must-die
  2. MDN Web Docs, "HTTP messages," Mozilla. https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Messages
  3. Chaim Linhart, Amit Klein, Ronen Heled, and Steve Orrin, "HTTP Request Smuggling," Watchfire whitepaper, 2005. https://www.cgisecurity.com/lib/HTTP-Request-Smuggling.pdf
  4. R. Fielding et al., "Hypertext Transfer Protocol -- HTTP/1.1," RFC 2068, IETF, January 1997. https://www.rfc-editor.org/rfc/rfc2068
  5. R. Fielding et al., "Hypertext Transfer Protocol -- HTTP/1.1," RFC 2616, IETF, June 1999. https://www.rfc-editor.org/rfc/rfc2616
  6. R. Fielding and J. Reschke, eds., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing," RFC 7230, IETF, June 2014. https://www.rfc-editor.org/rfc/rfc7230
  7. R. Fielding, M. Nottingham, and J. Reschke, eds., "HTTP/1.1," RFC 9112, IETF, June 2022. This is the current HTTP/1.1 specification. https://www.rfc-editor.org/rfc/rfc9112
  8. Line folding is defined in RFC 2616, Section 4.2, "Message Headers" (https://www.rfc-editor.org/rfc/rfc2616#section-4.2). It was deprecated in RFC 7230, Section 3.2.4 (https://www.rfc-editor.org/rfc/rfc7230#section-3.2.4), and is marked obsolete in RFC 9112, Section 5.2 (https://www.rfc-editor.org/rfc/rfc9112#section-5.2).
  9. RFC 9112, Section 6, "Message Body." https://www.rfc-editor.org/rfc/rfc9112#section-6
  10. RFC 9112, Section 6.3, "Message Body Length." https://www.rfc-editor.org/rfc/rfc9112#section-6.3
  11. National Institute of Standards and Technology, National Vulnerability Database, search statistics for the keyword "http request smuggling," accessed September 29, 2026. https://nvd.nist.gov/vuln/search?keyword=http%20request%20smuggling&resultType=statistics
  12. James Kettle, "HTTP Desync Attacks: Request Smuggling Reborn," PortSwigger Research, 2019. https://portswigger.net/research/http-desync-attacks-request-smuggling-reborn
  13. Cybersecurity and Infrastructure Security Agency (CISA), "Known Exploited Vulnerabilities Catalog." https://www.cisa.gov/known-exploited-vulnerabilities-catalog
  14. F5, Inc., "K000137353: BIG-IP Configuration Utility Unauthenticated Remote Code Execution Vulnerability (CVE-2023-46747)," F5 Knowledge Base, October 26, 2023. https://my.f5.com/manage/s/article/K000137353
  15. Michael Weber and Thomas Hendrickson, "Refresh: Compromising F5 BIG-IP with Request Smuggling (CVE-2023-46747)," Praetorian Blog, October 26, 2023. https://www.praetorian.com/blog/refresh-compromising-f5-big-ip-with-request-smuggling-cve-2023-46747/
  16. PortSwigger, "HTTP Request Smuggler," Burp Suite extension, GitHub. https://github.com/PortSwigger/http-request-smuggler
  17. defparam, "Smuggler," GitHub. https://github.com/defparam/smuggler
  18. Emil Lerner (neex), "http2smugl," GitHub. https://github.com/neex/http2smugl
  19. Apache Software Foundation, "Apache Module mod_proxy_http2," Apache HTTP Server documentation. https://httpd.apache.org/docs/current/mod/mod_proxy_http2.html
  20. HAProxy Technologies, "HTTP protocol support," HAProxy documentation. https://www.haproxy.com/documentation/haproxy-configuration-tutorials/protocol-support/http/#http%2F2
  21. NGINX, "NGINX Open Source 1.29.3 and 1.29.4," NGINX Community Blog, December 2025. https://blog.nginx.org/blog/nginx-open-source-1-29-3-and-1-29-4
  22. Ben Kallus, Prashant Anantharaman, Michael Locasto, and Sean W. Smith, "The HTTP Garden: Discovering Parsing Vulnerabilities in HTTP/1.1 Implementations by Differential Fuzzing of Request Streams," arXiv:2405.17737, May 28, 2024. https://arxiv.org/html/2405.17737v1
  23. Ryan Barnett, "HTTP/2 Request Smuggling," Akamai Blog, 2021. https://www.akamai.com/blog/security/http-2-request-smuggling
  24. Searchlight Cyber, "h2c Smuggling in the Wild." https://www.slcyber.io/research/h2c-smuggling-in-the-wild
  25. Yingbo Li, Zhensong Huai, Xiaolong Yan, and Jing Liu, "Request Smuggling Via HTTP/2 Cleartext in the Wild: Empirical Testing with Differential Fuzzing," in 2023 11th International Conference on Information Technology: IoT and Smart City (ITIoTSC), 2023, pp. 203–206. https://doi.org/10.1109/ITIoTSC60379.2023.00043
  26. Microsoft, "HTTP/2 support in Azure Front Door," Microsoft Learn. https://learn.microsoft.com/en-us/azure/frontdoor/front-door-http2
  27. Cloudflare, "HTTP/2 to Origin," Cloudflare Docs. https://developers.cloudflare.com/speed/optimization/protocol/http2-to-origin/
  28. Amazon Web Services, "HTTP Desync Guardian," GitHub. https://github.com/aws/http-desync-guardian
  29. National Institute of Standards and Technology, "CVE-2026-49975: Apache HTTP Server HTTP/2 Denial of Service ('HTTP/2 Bomb')," National Vulnerability Database, June 2026. https://nvd.nist.gov/vuln/detail/CVE-2026-49975
  30. Lucas Pardue and Julien Desgats, "HTTP/2 Rapid Reset: Deconstructing the Record-Breaking Attack," Cloudflare Blog, October 10, 2023. https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/

Vragen of feedback?

Bel onscontact
Mail onscontact