Fastly's Response to New HTTP/1.1 Desync Attack Vector
Fastly's Response to New HTTP/1.1 Desync Attack Vector
06 August 2025, 22:25 UTC
06 August 2025, 22:25 UTC
On the 18th of July, 2025, Fastly was made aware of a new HTTP/1.1 desync attack vector. Our security response engineers immediately initiated a thorough internal investigation, which determined that the Fastly platform is
not vulnerable
to this attack vector.
On the 21st of July, to validate our findings, we collaborated with the third-party researcher who discovered the attack vector. In this process, we confirmed that no Fastly-hosted endpoints were flagged as vulnerable during their research. The researcher noted that "Fastly seems to be relatively robust against desync attacks."
For additional due diligence, our Engineering teams also reviewed a preview of the full whitepaper on 28th of July, which further confirmed our conclusions.
You can read more about their research here: [ The Desync Endgame Begins by James Kettle from PortSwigger Research ]
06 August 2025, 22:26 UTC
06 August 2025, 22:26 UTC
In preparation for customer inquiries about the third-party researcher's article, we have provided these Q&A responses.
We know you trust us with mission-critical services, and we take any action that could cause issues for you very seriously. If you have any questions, please reach out to your Technical Account Management team or contact our Support team through our Fastly Support Portal .
Q: How does Fastly prevent HTTP request smuggling?
A: Fastly prevents HTTP request smuggling by strictly and compliantly parsing requests. This is done in several ways:
Strict Protocol Parsing: Fastly parses all HTTP requests with a high degree of strictness, adhering to standards. This removes the ambiguity that attackers use to exploit request smuggling vulnerabilities.
Request Normalization: Fastly either rejects or normalizes ambiguous requests at the Edge. For example, a request containing both a Content-Length and a Transfer-Encoding header will be handled to prevent it from reaching your origin in an exploitable state.
Rejection of Invalid Requests: Fastly denies GET and HEAD requests that contain a body. When this occurs, Fastly sends a 400 Bad Request response, preventing the request from reaching the origin. If configured to permit it, pass requests will transmit GET and HEAD request bodies to the origin. If you have a specific need to enable bodies for these requests, you must contact our support team.
You can open a support case here: [ Fastly Support ]
Q: What protocol is used between Fastly and customer backends?
A: Fastly is able to interact with backends that are HTTP/1.1 compliant. For a more detailed guide on backend integration, please see our developer documentation [Developer guide: Backends | Fastly Documentation]
Q: As a customer, how can I prevent HTTP request smuggling?
Fastly has published a detailed learning page on HTTP request smuggling, which includes tips and best practices for prevention. You can read it here: [ What is HTTP Request Smuggling? | Fastly ].
For users of our Core and Cloud Next-Gen WAF (NGWAF) , you can also leverage the " Bad Hop Headers " signal to block request smuggling attempts. It's important to remember that Fastly already normalizes these types of ambiguous requests, providing a robust first layer of defense.
Q: As a customer, how can I find out what HTTP protocol Fastly uses for its edge requests?
A: The HTTP protocol Fastly uses for its edge requests depends on whether your service is configured for TLS.
For TLS traffic: When you set up a TLS configuration, you have the option to specify whether to use HTTP/1.1, HTTP/2, or HTTP/3 for end-user traffic.
For non-TLS traffic: All non-TLS traffic between end-users and Fastly will only use HTTP/1.1.
To offer feedback on our status page, click "Give Feedback"