HTTP request smuggling starts with a mismatch: a front-end and a back-end disagree about where a request ends. On a reused connection, bytes left over from one request can become part of the next user’s request. This post explains how that happens, what an attacker can do with it, and how to test and defend against it. It’s the same parser-difference problem as DOM Clobbering and Mutation XSS, this time between HTTP servers.
In the previous post, DOM Clobbering and Mutation XSS came down to different parts of a browser interpreting the same input differently. Request smuggling is a similar mismatch between HTTP components: usually a proxy, load balancer, or CDN and the back-end server behind it. Here, the input is a stream of bytes sent over a reused TCP connection.
Modern setups almost never let the origin be accessed directly. Requests go through at least one intermediary, and for performance that intermediary keeps a pooled connection to the origin and sends many users’ requests through it one after another. All of that depends on both sides agreeing, byte for byte, about where each request ends.
If they disagree by even a few bytes, the remaining bytes from an attacker’s request become the first bytes of the next user’s request. The attacker never touches the victim. They simply cause the two parsers to count differently.
Both sides need to agree on the boundary. When they don’t, leftover bytes can be mistaken for the start of another request.
An HTTP/1.1 message does not have a fixed length. The body is separated in one of two ways, and the whole set of problems lives in the space between them.
The simplest method states the body length in bytes using a Content-Length header. The receiver reads that many bytes and then considers the message finished.
The streaming method sends the body in a series of chunks. Each chunk has a hexadecimal length, a carriage-return line feed, that many bytes, and another line feed. A zero-length chunk ends the body. The receiver does not know the total length beforehand; it reads until it sees the final 0 chunk.
```http id=”3a2zqb” Transfer-Encoding: chunked
b (next chunk is 0xb = 11 bytes) hello world (11 bytes of data) 0 (zero-length chunk: body ends here) (trailing CRLF closes the message)
### The rule and why it is not enough
The specification is clear: if a message contains both a `Content-Length` header and a `Transfer-Encoding: chunked` header, `Transfer-Encoding` wins. The conflicting `Content-Length` cannot be used to determine the message boundary, and the message may instead be rejected [3][4].
A single parser that follows the rules can handle this correctly. The problem starts when a request goes through two parsers. Those parsers might have been written by different teams, in different programming languages, or even years apart. One parser might follow the rule exactly. The other might contain a bug, use a shortcut, or read the rules more strictly or loosely. Now the same bytes can have two different boundaries.
The header that marks the end of a message is itself data that an attacker can send. When two servers do not agree on which delimiter to trust, the attacker can influence where the message ends on each server separately.
## Common desync patterns
Practical smuggling can be described by a few simple patterns. These patterns are named for the header that the front-end (F) and back-end (B) each trust.
### CL.TE: front-end counts bytes, back-end reads chunks
The front-end uses the `Content-Length` header and forwards the entire request. The back-end uses `Transfer-Encoding`, sees a zero chunk early, and considers the request finished. Anything the front-end sent after that zero chunk ends up in the back-end's buffer as orphaned data and is added before the next request on the same connection.
```http id="g6trxp"
POST / HTTP/1.1
Host: target.example
Content-Length: 13
Transfer-Encoding: chunked
0
SMUGGLED
The front-end forwards 13 bytes, including SMUGGLED. The back-end stops reading at the 0 chunk. SMUGGLED stays in the buffer and becomes the beginning of the next user’s request.
This is the mirror image. The front-end respects the chunked encoding and forwards the entire chunked stream. The back-end trusts the Content-Length header, reads only the number of bytes specified, and leaves the rest of the chunked data unread in the buffer. That leftover data can poison the next request.
Both the front-end and back-end support chunked encoding, so the attacker cannot simply rely on one side ignoring the Transfer-Encoding header. Instead, the attacker hides or changes the header in a way that causes one side to miss it and silently fall back to Content-Length.
These obfuscations are small and come in many forms: a space before the colon, a tab instead of a space, an unexpected value like xchunked, a duplicated header, or a leading character. Each form targets differences in how a parser handles unusual input.
```http id=”wtqx1v”
Transfer-Encoding : chunked (space before colon)
Transfer-Encoding:
One parser treats these variations as valid chunked encoding while the other does not.
### H2.CL and H2.TE: the downgrade reopens the wound
HTTP/2 was meant to solve this problem. It uses binary framing and does not depend on `Content-Length` or `Transfer-Encoding` to mark request boundaries in the same way HTTP/1.1 does.
The problem reappears when a front-end talks HTTP/2 to the client but changes the request to HTTP/1.1 before sending it to the back-end. If that front-end rewrites the request into HTTP/1.1 while accepting an attacker-controlled `Content-Length` or `Transfer-Encoding`, or if it fails to reject carriage-return or line-feed characters hidden inside HTTP/2 header values, the attacker can again control where the HTTP/1.1 message ends on the back-end.
This type of attack, which also includes request splitting through CRLF injection into HTTP/2 headers, is covered in later research on HTTP desynchronization [2].
## What an attacker can do with a smuggled prefix
A smuggled prefix is a building block, not a full exploit. Its power comes from attaching data to a request that the attacker never sent. The common results are:
- **Bypassing front-end controls.** Access controls, WAF rules, and path restrictions enforced at the front-end are applied to the request that the front-end saw. The smuggled prefix is put together at the back-end, so it can reach paths that the front-end would have blocked.
- **Capturing another user's request.** By inserting a prefix that forces the next request's data to appear somewhere the attacker can read back, such as a comment field or reflected search field, the attacker can capture the victim's headers, including session cookies and authorization tokens.
- **Web cache poisoning and response queue desync.** A desync can shift the order of requests and responses on a connection, causing one user to receive another user's response or causing a poisoned response to be cached and served to everyone.
- **Turning a reflected input into a stored, cross-user effect.** Because the prefix travels with victims' requests, a low-value reflected issue can become a way to attack other users sharing that back-end connection.
## Detecting desync safely
Confirming a desync can corrupt real users' requests, so detection should favor methods that show the disagreement without leaving a poisoned prefix in a shared buffer. The main technique is timing, formalized in the desync research that revived the class [1].
### Timing a CL.TE target
Send a request whose framing forces the back-end to wait for bytes that will never arrive. If the front-end uses `Content-Length` and forwards a fixed number of bytes, but the back-end uses `Transfer-Encoding` and is left mid-chunk expecting more, the back-end blocks until it times out.
That delay is the signal. A matched control request with normal framing should return quickly, which helps separate the framing issue from ordinary network delays.
```http id="ojrbmm"
POST / HTTP/1.1
Host: target.example
Transfer-Encoding: chunked
Content-Length: 4
1
A
X
The front-end (CL: 4) forwards the bytes and stops. The back-end (TE) is left with an incomplete chunk and waits for the rest. A long, repeatable delay compared with a clean control is the desync signal.
When timing is inconclusive, a confirmed desync can create a difference that an attacker can see directly: a follow-up request returns a status or body that only makes sense if a prefix attached to it. Because this method can affect real traffic, it belongs in an authorized test window against a controlled account, not in casual probing.
Content-Length and Transfer-Encoding, or malformed Transfer-Encoding values. In a normal client population these should be rare and are worth investigating.Testing should establish whether two parsers disagree and what that lets an attacker reach. Defenders should check that requests are parsed consistently and that leftover bytes cannot spill into another user’s request.
Transfer-Encoding instead of forwarding them.| Signal | What it indicates |
|---|---|
| Timing delta between a mid-chunk probe and a clean control | Primary safe detection signal |
Coexisting Content-Length and Transfer-Encoding |
Ambiguity by construction |
Obfuscated Transfer-Encoding (space, tab, junk value, duplicate) |
TE.TE candidate |
| HTTP/2 front-end downgrading to HTTP/1.1 at the origin | H2.CL / H2.TE surface |
| Pooled, reused back-end connections shared across users | The channel a prefix travels on |
The most reliable defenses make every component agree on the request boundary, or prevent bytes left over on one request from reaching another.
HTTP/2 frames messages in the protocol itself using binary frames. It does not rely on Content-Length or Transfer-Encoding to mark request boundaries in the same way HTTP/1.1 does. When HTTP/2 is used through every hop to the origin, the traditional CL and TE framing ambiguity is gone.
The remaining risk is the downgrade. When a hop converts the request to HTTP/1.1, the old framing rules come back, and that hop becomes responsible for producing valid, unambiguous HTTP/1.1. The goal is not just to offer HTTP/2 at the edge. It is to avoid downgrading behind it when possible.
Where HTTP/1.1 must be used, the front-end can enforce that a request has exactly one valid way to be framed. Reject messages carrying conflicting framing headers, malformed or unsupported Transfer-Encoding values, embedded carriage returns or line feeds in header values, and duplicate framing headers.
This does not try to decide which of two interpretations is correct. It prevents input with two interpretations from entering the system in the first place.
```text id=”42dvaz” Reject, do not forward, when:
has(Content-Length) && has(Transfer-Encoding) conflicting framing Transfer-Encoding is malformed or unsupported obfuscation header value contains CR or LF splitting duplicate framing headers TE.TE / CL.CL ```
Even a successful desync needs a shared connection to carry the orphaned prefix to another request. If the front-end opens a new connection to the back-end for every request, leftover data has no next request to attach to and dies with the connection.
This trades some performance for isolation and can be a strong mitigation where the performance cost is acceptable.
The problem exists because two independently built parsers can disagree. Reducing the number of different HTTP implementations in the chain, and configuring the remaining ones consistently, reduces the places where a disagreement can hide.
The connection to the previous post is the parser mismatch: browsers can disagree about markup, and HTTP components can disagree about message boundaries. In either case, consistent parsing is more reliable than trying to anticipate every unusual input.
Request smuggling is more dangerous than its simple mechanism suggests. The mechanism is only a few bytes of disagreement about where a message stops. The result can be the ability to rewrite the beginning of someone else’s request, turning a framing issue into a cross-user attack: stolen sessions, bypassed controls, poisoned caches.
The same setup that makes the web fast can create the conditions for this bug: independent intermediaries share pooled connections and may parse requests differently.
For a security team, the rules are fairly simple. List every hop and treat each pair of parsers as a place where two answers might diverge. Detect by timing before risking a poisoning probe, and do not let your tools automatically correct the ambiguity you are testing. On defense, reject ambiguous framing at the edge, prefer end-to-end HTTP/2, break shared back-end connections where the performance tradeoff makes sense, and reduce unnecessary parser differences throughout the chain.
Every hop needs to agree on where a request ends. Reject ambiguous framing, avoid risky downgrades, and review each parser in the request path.
Note on citations: These references should be verified against the primary sources before publication. Titles, authors, venues, years, and other bibliographic details should be confirmed at the source.
Content-Length and Transfer-Encoding precedence and rejection rules.DOM Clobbering and Mutation XSS look like unrelated curiosities. They’re really the same engineering failure seen twice. Security tooling validates one interpretation of a byte stream while the browser executes a different one.
Both attacks exploit a gap between what a security check sees and what the browser does. Here’s how that gap forms, how to test for it, and which defenses help close it.
Cross-site scripting has a well-understood shape: untrusted input reaches somewhere the browser will interpret it as code. A generation of defenses grew up around that model. We escape output, allowlist tags and attributes, ship a Content Security Policy, and assume that if the markup we hand to the page contains no <script> or event-handler attributes, nothing will run.
DOM Clobbering and Mutation XSS both break that assumption while still satisfying the rules it was built on. Neither requires an injected <script>. Neither requires an onerror. Both can pass through sanitizers that a security team would normally consider safe.
The problem is that the check and the execution happen against two different models of the same bytes.
In DOM Clobbering, the two models are about how a name resolves. The sanitizer sees normal elements carrying an id or name. The browser sees those same attributes as entries in the named-property namespace of document and window. Attacker-controlled markup can then shadow globals that the page’s own JavaScript depends on.
Mutation XSS has the same kind of disagreement, but in parsing. The sanitizer inspects one parse tree and decides that it is clean. That tree is serialized back into a string and inserted again. The browser’s parser runs under a different context and can produce a different tree, potentially one containing executable markup.
The key question throughout is simple: does the browser use the same structure your security check approved?
To understand the gap, it helps to look at what happens between a string of markup and a running page. Three mechanisms matter, and each creates a place where interpretations can diverge.
The HTML parser does not simply map characters to elements one-to-one. It uses a tree-construction algorithm with different modes and insertion rules. What a tag does depends partly on where it appears.
A <td> outside a table can be dropped. A <p> can be implicitly closed by a following block element. More importantly for this problem, HTML, SVG, and MathML use different parsing rules. The parser can switch between them in the middle of a document when it crosses into foreign content such as <svg> or <math>.
The same characters can therefore represent an element in one context and harmless text in another.
Reading element.innerHTML serializes the current DOM into a string. Assigning to innerHTML parses a string into a DOM.
Those operations look like opposites, but they aren’t guaranteed to be.
There are trees whose serialized representation produces a different tree when parsed again. In other words:
parse(serialize(t)) does not always equal t.
That fact is the mechanical basis of Mutation XSS.
Long before getElementById existed, browsers allowed scripts to reach elements by name. That behavior is still around.
Elements with certain id or name values can participate in named property access on objects such as window and document. That means application code which expects a normal JavaScript value may instead resolve an attacker-injected DOM element.
That behavior is the mechanical basis of DOM Clobbering.
These behaviors give the same input more than one meaning. A defense can inspect one meaning while the application acts on another.
DOM Clobbering is basically a client-side code-reuse attack. The attacker does not necessarily inject their own logic. Instead, they inject named markup that changes a value the application’s trusted JavaScript later reads.
The application supplies the useful code. The attacker changes the data that code operates on.
Named-property behavior is built into browsers. An element with an appropriate id can become available through named access, while collections of named elements can produce more complicated object-like structures.
Those behaviors give attackers a way to influence values using markup alone.
If application code guards a feature with a simple truthy or falsy check, an injected named element may be enough to change the result.
// Trusted application code already on the page:
if (window.isAdmin) {
renderAdminControls();
}
// Attacker-controlled markup that survives a script-stripping sanitizer:
// <a id="isAdmin"></a>
//
// window.isAdmin may now resolve to an element, which is truthy.
No attacker JavaScript was injected. The application’s own code made the security-relevant decision.
More interesting gadgets read something they expect to be a string, such as a URL that later becomes a script source, redirect, or network destination.
Certain DOM elements, especially anchors, have useful string-like behavior. Combined with named-property resolution, attacker-controlled markup can sometimes supply a value to trusted code.
// Trusted gadget expects a configured base URL:
const base = window.cfg.endpoint;
const s = document.createElement('script');
s.src = base + '/widget.js';
document.head.appendChild(s);
// Attacker-controlled markup may influence what cfg.endpoint resolves to.
The risk is that trusted code reads security-sensitive configuration from a namespace attacker-controlled markup can influence.
Named access can also interfere with assumptions about properties exposed by browser objects.
Code that assumes a property on document or window will always have a particular type can fail when markup changes how that name resolves. Depending on the surrounding code, that may cause anything from a crash to a useful exploitation primitive.
The attributes DOM Clobbering needs, particularly id and name, are also completely normal HTML attributes. Stripping them globally would break legitimate styling, anchors, forms, accessibility behavior, and application logic.
That’s why DOM Clobbering isn’t simply a case of allowing an obviously dangerous tag.
It also has an important precondition: the application needs a gadget. There must already be trusted code that reads from a clobberable name and then does something useful with it.
That is what makes clobbering a code-reuse attack. The interesting part isn’t just finding somewhere to inject an id. It’s finding trusted code that gives that id power.
What makes an application interesting to test
- Security-relevant configuration or feature flags read from
windowordocumentby name.- Truthy/falsy or fallback checks that an unexpected DOM element could satisfy.
- HTML injection that permits named elements even though scripts and event handlers are stripped.
Mutation XSS takes advantage of the fact that parsing and serialization are not perfect inverses.
A sanitizer receives markup, parses it, decides it is safe, and returns serialized output. Somewhere downstream that output is treated as HTML again and parsed a second time.
If the second parse produces a different tree from the one the sanitizer approved, something that was harmless during validation can become active after insertion.
That’s the mutation in Mutation XSS.
One of the richest sources of parser differences is foreign content.
Inside <svg> and <math>, browsers follow different parsing and namespace rules than they do in ordinary HTML. Certain elements also act as transition points where content interpreted one way in one namespace may be interpreted differently after another parse.
This has historically created problems for sanitizers because a sanitizer may reason about one tree while the browser later reconstructs another.
The basic idea is simple: find markup whose serialization does not parse back into the same structure.
The sanitizer examines a tree where some dangerous-looking fragment is harmless because of its current parsing context. The tree is approved and serialized. When that serialized string is parsed again in another context, the browser produces a different structure.
Conceptually:
<!-- First parse -->
<svg>
<style>content treated according to this parsing context</style>
</svg>
<!-- Sanitizer approves the resulting tree -->
<!-- Tree is serialized back to text -->
<!-- Serialized output is later parsed again -->
<!-- Second parse may not reconstruct the same tree -->
The exact payloads change as browsers and sanitizers are patched. That’s part of the point.
If you treat the vulnerability as a list of malicious strings, you’re stuck chasing payloads forever. The underlying problem is the round trip itself.
Researchers have found variations involving namespace confusion, comments and CDATA handling, differences in <noscript> parsing, and serialization behavior around special characters. The details change. The parser differential remains.
The dangerous pattern is structural:
parse → make a trust decision → serialize → parse again → render
The security decision happened during one interpretation. Execution happens after another.
If the second parse can change the markup, test whether that change can make something unsafe run.
What makes an application interesting to test
- Sanitizer output returned as a string and later sent to
innerHTML,outerHTML, orinsertAdjacentHTML.- Template logic that modifies or reconstructs sanitized markup before insertion.
- Content that crosses HTML, SVG, or MathML parsing boundaries.
Put DOM Clobbering and Mutation XSS next to each other and the shared problem becomes easier to see.
Both are differentials: two parts of the platform claim to understand the same input, but they don’t give it exactly the same meaning. The security decision happens in one model while the final behavior comes from another.
DOM Clobbering is a differential in the naming model. A sanitizer sees id and name as normal attributes. Runtime property resolution may treat them as names available to JavaScript.
Mutation XSS is a differential in parsing and serialization. The sanitizer approves one tree. The browser later constructs another.
In both cases, the browser gets the last word.
Content Security Policy, output encoding, and allowlist sanitization are still useful defenses. The problem is that none of them automatically removes a disagreement between two interpretations.
A parser differential isn’t necessarily a bad character you forgot to escape or a dangerous tag you forgot to remove. It’s a disagreement about what the input means.
The stronger position is architectural: make the component that decides whether something is trusted operate on the same representation that ultimately gets rendered.
Testing looks for a parsing or property-lookup difference that reaches something security-sensitive. Code review asks whether untrusted markup can create that difference in the first place.
Enumerate the sinks first. Search client-side code for innerHTML, outerHTML, insertAdjacentHTML, document.write, and framework equivalents such as dangerouslySetInnerHTML or v-html. Sanitized output that later reaches one of these deserves attention.
Map gadgets for clobbering. Look for reads from window.NAME, document.NAME, fallback defaults, and configuration pulled from the DOM. Then determine whether attacker-controlled markup can influence the same name.
Differential-test the sanitizer. Parse a candidate fragment, serialize it, parse it again, and compare the resulting DOMs. Structural differences are worth investigating, especially around SVG, MathML, and other known parsing boundaries.
Prove impact, not novelty. A weird parser mutation that reaches nothing is interesting research, but not necessarily an exploitable bug. Trace it to what actually happens: script loading, redirects, authorization behavior, or another security-sensitive sink.
Pay attention to string-typed sanitizer output. If sanitized HTML becomes a string and later gets parsed again by an HTML sink, review the entire path rather than assuming the sanitizer settles the question.
Avoid named global reads for security decisions. Feature flags, authorization state, endpoint configuration, and similar values should come from controlled application state, not runtime named access on window or document.
Lint for the round trip. Static analysis can catch sanitize-to-string-to-HTML-sink patterns before they become a production problem.
Watch browser reporting. CSP and Trusted Types violation reports can expose unexpected sink usage and other behavior worth investigating rather than treating every report as policy noise.
| Signal | What it indicates |
|---|---|
.innerHTML =, insertAdjacentHTML, outerHTML |
mXSS sink candidates |
window.NAME, document.NAME, fallback expressions |
Clobbering gadget candidates |
| Security-sensitive reads from DOM-backed names | Potential clobbering surface |
Sanitizer allowlists permitting id, name, forms, and anchors |
Named-property surface worth reviewing |
Round-trip differences across <svg> and <math> boundaries |
Mutation candidates |
No single control covers both bugs. The practical approach is to avoid reparsing sanitized strings, control access to HTML sinks, and keep trusted state out of names that markup can shadow.
The structural problem behind mXSS is the sanitize-serialize-reparse cycle.
Browser-native sanitization APIs can reduce that gap by moving sanitization closer to the parser and the point where content is inserted. Instead of having one library create a trusted string and another parser later reinterpret it, the browser can participate directly in the sanitization and insertion process.
Avoid transformations between the content you approved and the content the browser renders.
Trusted Types attacks the problem from the sink side.
When enforced, dangerous DOM sinks cannot simply accept arbitrary strings. Code has to pass values through an explicit policy first.
That does not magically decide whether every piece of HTML is safe, but it makes the trust boundary much easier to see and audit. Instead of security depending on every string operation scattered through an application, the decision can be concentrated into a smaller number of controlled policies.
It also turns many accidental “untrusted string reached an HTML sink” cases into browser-enforced failures instead of silent execution.
DOM Clobbering becomes much less useful when important application state does not come from names that markup can influence.
Security-sensitive configuration belongs in module scope, controlled application objects, or other locations whose meaning cannot be changed just because someone inserted an element with a matching id or name.
// Better: trusted configuration lives in application state,
// not in a name resolved from attacker-influenced markup.
import { endpoint } from './config.js';
const s = document.createElement('script');
s.src = endpoint + '/widget.js';
The simplest defense is to avoid this kind of gadget.
Clobbering needs trusted code that turns the manipulated value into something useful.
That means libraries should treat named DOM reads as part of their security surface. Configuration, script sources, URLs, and control-flow decisions should not depend on values that attacker-controlled markup can unexpectedly shadow.
This matters especially for widely deployed dependencies. One reusable gadget can create the same attack surface across many applications.
CSP still earns its place as defense in depth.
A strict nonce- or hash-based policy can prevent attacker-controlled script sources or inline code from executing even when another layer fails. But CSP does not remove the underlying parser or resolver differential.
The clobber can still happen. The mutation can still happen. CSP limits what happens afterward.
Use CSP as containment behind those fixes, not as a replacement for them.
The defenses that work best all move in the same direction: reduce the distance between the thing you inspect and the thing the browser actually uses. Avoid unnecessary reparsing, control dangerous sinks, and keep trusted state out of namespaces attacker-controlled markup can influence.
DOM Clobbering and Mutation XSS persist because they arise from browser behavior that individual payload filters cannot reliably remove.
The browser can hold multiple interpretations of the same input. Named-property resolution gives markup meaning that isn’t obvious from looking at the HTML alone. Parsing and serialization can turn one DOM structure into another. Those are old browser behaviors, and trying to enumerate every payload built on top of them is a losing game.
For a security team, the practical takeaways are pretty direct. Treat sanitizer output that later gets parsed again as an mXSS candidate. Treat security-sensitive values resolved through named DOM properties as possible clobbering gadgets. Reduce unnecessary parsing round trips, use browser-enforced controls such as Trusted Types where appropriate, keep trusted configuration out of attacker-influenced namespaces, and use CSP as containment.
Trust the document the browser runs, not only the one your tooling inspected.
]]>