This article is designed to help you understand Client-Side Desync from an attacker’s perspective.
Client-side desyncs are a class of browser-powered HTTP smuggling attacks. HTTP smuggling can be succinctly described as a technique that enables a malicious actor to sneak an HTTP request into the body of another request. The act of sneaking a second request in the body of a primary request is the most significant similarity between Client-Side Desync and classic HTTP smuggling attacks. One of the primary differences between the two is that client-side desyncs are browser-powered. Security features in modern browsers restrict malicious actors from manipulating data belonging to the Content-Length and Transfer-Encoding headers. Traditional smuggling attacks require modification of these headers to be performed and, therefore, cannot be conducted by a victim’s browser. Both client-side and server-side Desyncs do not rely on the same mechanism and can execute in the browser. The browser-powered desync attack class was first discovered by the Portswigger Director of Research, James Kettel.
The attack class was popularized after his presentation at Defcon 30 titled “Browser-Powered Desync Attacks: A New Frontier in HTTP Request Smuggling.” An incredible article by the same title can be found on the Portswigger website. Client-side desync refers to a browser-powered desync where desynchronization occurs between the client and the front-end server. This differs from Server-side desyncs where the confusion occurs between the front and back-end servers.
Client-side desyncs occur when web servers are configured (or misconfigured) to issue an immediate response to a POST or PUT request without first checking the content of the body. The server answers the first request immediately but prepares an additional response for the secondary, smuggled request that was hidden in the body of the original. An easy way to picture this is the classic two kids in a trench coat cliché. An unsuspecting bouncer looks at the height of the apparent “individual.” He assumes all is well and lets the “man” inside. What he doesn’t see is that there is a second person hidden beneath the coat. Once they are inside, they can approach the bar, and each can make an order and receive a drink. Similarly, client-side desync attacks work with the victim’s browser being the bouncer and the vulnerable server being an apparently apathetic bartender. An example desync would look something like this:
Let’s break down the above image. In green, we see the primary request being sent. In red, we see the smuggled request, which is technically in the content body of the primary request. Lastly, in purple, is the next request. The browser would send this as an entirely separate request, while the server would interpret it exactly as shown above. With the lack of a carriage return(\r\n) at the end of the smuggled request, the server would simply append the next request to the end of the smuggled request. By placing an arbitrary header in the smuggled request, we can cause the server to ignore the first line of the next request. We can even use this technique to make use of cookies that would normally be inaccessible to us as attackers.
So, what are we really doing here? We are tricking the victim’s browser into sending what it perceives as a single request but is read by the server as two requests. Why is this a security issue and not just a bug? What can be impacted? The answer to the first question is straightforward. Imagine a situation where a victim visits an attacker-controlled website. Normally the malicious actor can cause the victim’s browser to issue HTTP requests but is limited in the scope of what can be modified. The client-side desync allows the attacker to control certain content that is typically off-limits due to browser security. We can modify fields that were previously untouchable, such as the host header, origin, cookies, and other fields. Many potential security findings that are typically considered “unexploitable” suddenly become feasible. Host header redirects and XSS via cookies become very real and dangerous vulnerabilities when delivered via a desync. Several client-side desync CVEs utilize an attack chain that uses a host header or other open redirect vulnerabilities to perform web cache poisoning.
Examples of this form of web cache poisoning via redirects include
which exploit Cisco ASA Web VPNs and Werkzeug v2.1.0, respectively.
The methodology used to identify Client-side desync vulnerabilities is simple. Identify endpoints on the target web server that issue responses without considering the content length. This is most often static files or redirects. Common static files include robots.txt, JavaScript files, and CSS files. Redirects can often be found by removing the ending / from known endpoints. For example, if a site has the endpoint “target-site.com/login/,” try sending a request to “target-site.com/login.” There is a good chance you may receive a 301 redirect message.
Using a web application proxy tool like Burp Suite, try sending an overlong content length to the target endpoint. If the response is immediate, the likelihood of CLIENT-SIDE DESYNC is high.
If the response hangs, never comes, or returns 400 bad request, then this file/redirect is not a viable target, as shown in Figure 2 below.
In the event the target server issues an immediate response to your overlong content-length, the next step is to send a request with a smuggled request in the body, followed by another request on the same connection. A few steps are necessary to perform this test. First, alter the primary request by changing the connection header to keep-alive as seen in Figure 3 below.
This will instruct the server to continue listening for additional requests on the same connection. Next, you must write a smuggled request into the body of the first. This can be a barebones request with only the method, path, HTTP version (ensure the version is not HTTP2), and an arbitrary header. Ensure you choose a path that you would recognize the response of. After writing the smuggled request, create a new request to another path you are familiar with. Add the two separate requests to a group and select “Send Sequence over Single Connection.”
Click send and observe the responses. You should see the response to the primary request, then after clicking on the second request, you should see it received the response you would expect for the smuggled request.
The last step to confirm vulnerability to client-side desync is to validate that the request can be sent by a browser. This can be performed using the fetch() method. Open a browser and navigate to a site on another domain than the target server. Open the developer tools and paste the following JavaScript inspired by James Kettil’s Browser Powered Desync Attacks:
fetch('https://target-site.com/', {
method: 'POST',
body: "GET /static-file.js HTTP/1.1\r\nX: Y",
mode: 'no-cors',
credentials: 'include'
}).then(() => {
location = 'https://target-site.com/'
})
At this point you would have a client-side desync finding, but no penetration tester would feel accomplished without demonstrating impact. A client-side desync, while still warranting remediation, is not much of a finding without a way to weaponize it. If you have already discovered a typically difficult-to-exploit vulnerability, such as host header redirect or XSS via cookies, then this would be a prime opportunity to link them with the client-side desync. Furthermore, client-side desync essentially completes these types of attacks thereby raising their exploitability from nearly zero to very likely. Web cache poisoning is one of the best attacks to chain with client-side desync, though it requires some form of open redirect vulnerability. Another article demonstrating attacks using client-side desync as a sled will be uploaded to the Redbot Security feed at a future date.
After all this talk about finding and exploiting client-side desync vulnerabilities, it is only fair to provide basic remediation advice. Most known client-side desync vulnerabilities have been resolved by product creators. Simply patching web servers will resolve most cases of client-side desync. If a patch is unavailable due to using an end-of-life server or the patch simply hasn’t been released yet, an easy solution may still be available. Client-side desync attacks do not work against the HTTP2 protocol. HTTP2 does not use content length and is therefore immune to this attack. Configuring servers to use HTTP2 will prevent client-side desync attacks entirely. This is a quick and effective method to remove the possibility of being attacked via client-side desync.
Client-side desync is part of the new browser-powered desync attack class. This vulnerability is an excellent way to elevate the severity of previously “unexploitable” vulnerabilities. This attack technique desynchronizes the communication between a victim’s browser and a target server allowing circumvention of many modern browser security features. Becoming familiar with identifying client-side desync attack vectors will expand a penetration tester’s skillset and allow them to provide a more complete security assessment for their clients. Consider adding the client-side desync attack to your personal penetration testing toolkit.
Conner brings 6+ years of military cyber operations experience and served as a Cyber Operations Specialist with the work roles of Special Activities Team (SAT) Technician, Expeditionary Cyber Operator (ECO), Information Operations Operator, and Pilot Operator. Conner has been a core member of Redbot Security's team, continuing to execute Sr. Level Penetration Testing. Conner is also Redbot Security's Wireless SME.
Contact Redbot Security
Senior Level Hands-on-Keyboard
Manual Testing
Get a Project Quote
Malicious actors leveraging OSINT to uncover confidential and sensitive information that is publicly available online. Learn how to prevent risks.
Client-side desyncs are a class of browser-powered HTTP smuggling attacks. What you need to know and how to prevent a malicious actor from taking advantage of this vulnerability.
Active Directory Certificate Services (AD CS) presents various security risks for organizations. This article will help you understand a Relay Attack.
What is an API? APIs, including local and remote, come in various forms and are fundamental to modern software development. They serve as the bridge between different software components, enabling them to work together seamlessly.
While plenty of articles cover the Modbus protocol with varying degrees of detail and usage, this article aims to examine the Modbus protocol with an offensive security lens.
Our nation is under attack and overwhelmed. Modern Security teams face numerous challenges in managing network and application security effectively.
Cymbiotic Hive: The Simple, Rapid-Deployment Solution to Access Management
Redbot Security’s senior-level cloud security team brings years of expertise in AWS, GCP, and Azure security. Our approach is rooted in manual-controlled testing and deep-dive security analysis, ensuring that we uncover hidden vulnerabilities that automated tools often miss.
Internal network penetration testing is essential for identifying security gaps within an organization’s infrastructure. Attackers exploit misconfigured permissions, weak credentials, and unpatched vulnerabilities to escalate privileges and move laterally within networks. A thorough penetration test helps uncover these risks before they are exploited, ensuring stronger security controls, improved access management, and compliance with industry standards. Redbot Security’s expert-led penetration testing provides in-depth assessments to fortify your internal network against evolving threats.
Understanding NIST 800 and Its Impact on Penetration Testing Requirements.
From pipelines and water systems to power grids and transit networks, U.S. critical infrastructure is under siege. With CISA budget slashed, is a national cyber disaster inevitable?
Cybercriminals are ditching malware and exploiting trusted tools already inside your systems. Learn how Living off the Land (LotL) attacks work, and how to stop them.
From API-server exploits to supply-chain threats, this checklist shows how the best penetration testing companies harden Kubernetes. Boost resilience now.
The FBI released its FY 2024 IC3 Annual Report on April 24, 2025, detailing 859,532 complaints and a record $16.6 billion in losses. In this post, we highlight how phishing, BEC, and cryptocurrency fraud continue to surge, why ransomware remains a top threat to critical infrastructure, and which demographics are most at risk. Plus, discover Redbot Security’s proven strategies,from manual penetration testing to red teaming, that can help you turn IC3 data into actionable defenses.
Malicious actors prey on weak configurations like locusts. Microsoft, despite knowing that their operating systems, have inherent weaknesses have done little to enhance their initial security outside of remediation for publicly known vulnerabilities.
The following article is a discussion about helping you to best utilize your military skills to successfully transition into the commercial space.
The following article is a discussion that explores JavaScript Web Tokens
The following article is a discussion that explores Wave Behaviors to Locate Wireless Access Points and Devices
Today, cybercriminals have plenty of entry points to exploit. Therefore, it has become crucial for organizations to improve their attack surface visibility to have more effective protection. This is where attack surface management (ASM) comes into play. This article will explore all about attack surface management (ASM), including its importance, working principle, and benefits.
Should an Employee Report Security Incidents Involving Family Members? Is your business or job at risk if a bad actor gets access to your family. Will they gain access to you?
The likelihood of a cyber attack on a mobile platform is significantly high, but how difficult is it for a malicious actor to generate malware? You might be surprised.
Insecure Direct Object Reference (IDOR) vulnerabilities pose a significant risk to the security of web applications, allowing attackers unauthorized access to sensitive data and functionalities. By understanding the implications of IDOR and adopting secure coding practices, web developers can protect their applications and users from potential exploitation.
Mass Assignment Vulnerability occurs when a web application allows users to submit a more extensive set of data than is intended or safe. The potential consequences of this vulnerability can be severe
Attackers can manipulate the serialized data to execute malicious code, compromise the application, or gain unauthorized access.
Kerberos Authentication Service Response (AS-REP) Roasting, a technique similar to Kerberoasting, has gained prominence as a method for attackers to compromise Active Directory (AD) authentication systems.
Becoming proficient in Operational Technology (OT), Industrial Control Systems (ICS), and Supervisory Control and Data Acquisition (SCADA) network testing can appear daunting as there are fewer learning resources.
Machine Learning (ML) is a subset of AI, and, more than likely, closely aligns with what we consider to be AI in the media.
Recent reports of significant cybersecurity layoffs in the United States have raised concerns about the nation’s preparedness to defend against cyber threats
While penetration testing is valuable in identifying technical vulnerabilities, red teaming provides a more holistic assessment by simulating realistic threat scenarios. By embracing red teaming, organizations can bolster their defenses, uncover weaknesses, and stay one step ahead of sophisticated adversaries.
Through repeated random sampling, allows us to simulate a wide array of social engineering attacks with a depth and breadth previously unimaginable.
Is your security team sharing sensitive data unknowingly?
Our nation is under attack and overwhelmed. Modern Security teams face numerous challenges in managing network and application security effectively.
Increasingly, investors see proactive cybersecurity spending as a hallmark of strong corporate governance. It can be factored into how they value a company’s resilience and risk profile
With data breaches surging by 68% last year alone, cybersecurity has evolved from a low-key technical matter into a defining issue demanding top-level attention.
