HTTP Desync

How HTTP desync works

HTTP desync happens when two components do not parse the same byte stream in the same way. One intermediary may treat a boundary as the end of a request while the next component still considers that data part of the current request, creating a split view of traffic.

This is not a single bug class in one product. It is a protocol handling failure that emerges where clients, reverse proxies, load balancers, gateways, and origin servers all interpret request framing, headers, or transfer rules differently.

Why HTTP desync is dangerous

The danger comes from ambiguity. If an attacker can make one component forward or queue data differently from another, they can hide a second request inside the first, interfere with other users' traffic, or manipulate downstream application state.

That can lead to request smuggling, cache poisoning, authentication bypass, and session confusion. The same parsing mismatch can also create an attacker-controlled path past controls that were enforced only at the edge and not re-validated at the origin.

Common places desync appears

HTTP desync usually appears in multi-hop web paths where parsing is not perfectly aligned. Classic problem areas include conflicts between Content-Length and Transfer-Encoding, inconsistent handling of duplicate headers, and edge cases in connection reuse or request pipelining.

The issue is often invisible during normal testing because each component appears to work correctly on its own. The failure only becomes obvious when traffic crosses component boundaries and a request is interpreted differently at each hop.

How defenders reduce exposure

Defence starts with making the request path unambiguous. Organisations should minimise chains of intermediaries, align parsing behaviour across proxies and origins, and avoid relying on one layer to enforce a control that another layer can silently reinterpret.

When an intermediary must sit in front of the application, the safest design is to use strict, consistent request parsing and reject ambiguous inputs rather than trying to guess the user's intent. Testing should include the full request path, not just the application server in isolation.

For protocol and control guidance, the Model Context Protocol: Authorization specification is a useful example of how HTTP transport security depends on clear boundaries, while the OWASP API Security Top 10 helps frame how broken request handling can become an access-control problem at the API layer.

Risk and Threat Considerations

HTTP desync is especially dangerous in shared web infrastructure because one attacker request can affect other users' requests that are queued, cached, or multiplexed behind it. The result is not just a malformed request, but a cross-request attack surface that can expose sessions, alter cached responses, or undermine trust in the edge-to-origin boundary.

Failure mechanism: A front-end component and a back-end component disagree on request length or request boundaries, allowing attacker-supplied bytes to be processed as part of a different request than the defender expected.

Impact: Attackers can smuggle requests past front-end checks, poison shared caches, desynchronise connection state, or hijack a victim's session flow if the poisoned or hidden request is executed in another user's context.

Practitioner Guidance

What to watch for: Treat desync as a path-wide control problem, not just an application bug. The most useful investigations compare how every intermediary and the origin parse the same traffic, especially where reverse proxies, CDN layers, and application gateways are involved.

Governance implication: Security ownership should span the full HTTP request chain, including proxy policy, origin parsing rules, and cache behaviour. If those controls are managed by different teams, the risk is that no single team sees the complete failure mode.

Related resources from NHI Mgmt Group

• What breaks when HTTP/1.1 desync is not eliminated in proxy chains?
• Why do HTTP/1.1 downgrade paths increase desync risk?
• Why does upstream HTTP/1.1 increase desync risk in modern architectures?
• What are the signs that an HTTP desync issue is present?