HTTP Request Smuggling: When Your Frontend and Backend Disagree

In 2025, a single class of HTTP bugs compromised the core infrastructure of Cloudflare, Akamai, Netlify, and Microsoft's ASP.NET Core — collectively affecting tens of millions of websites. One researcher earned over $350,000 in bug bounties exploiting it across major bug bounty programs, including a $200,000 burst inside a two-week window. PayPal alone paid out $38,900 to fix the same bug class on its login page (and the researcher bypassed the first fix to claim the second bounty). And in November 2025 the .NET ecosystem absorbed CVE-2025-55315 — described by lead Microsoft engineers as "the worst .NET vulnerability ever" — which sits in basically every version of ASP.NET Core shipped to production.

The bug class is HTTP request smuggling. It is twenty years old. It was supposed to be solved. It is not. And in modern web architecture — where every request crosses a CDN, a load balancer, a reverse proxy, and an application server — the surface for it has only grown.

This article is written for two readers at the same time. If you are a founder or CTO whose company sits behind any kind of edge infrastructure (and most do), the first sections explain what is actually at stake and how to talk about it. If you are an engineer or security lead, the technical sections cover the modern (2024–2026) attack catalog, the patch landscape, and the defenses that hold up against the latest research.

The 60-second version for non-technical leaders

When a user's request hits your application, it usually passes through several pieces of software in a chain — first a CDN (Cloudflare, Akamai, CloudFront, Fastly), then a load balancer, then maybe a reverse proxy, then your application server. Each of those pieces independently parses the HTTP request to decide what to do with it.

The bug: if any two of those parsers disagree — even slightly — about where one request ends and the next begins, an attacker can hide a second request inside the first. The frontend sees one request; the backend sees two. The smuggled request then executes in a privileged context the attacker should not have had: on someone else's connection, with someone else's cookies, bypassing your web application firewall (WAF), reaching your internal endpoints, or poisoning your cache so that the next thousand visitors to a popular URL receive the attacker's content.

The reason this matters at the executive level:

The blast radius is your entire user base. Unlike most bugs — which compromise one user — request smuggling commonly affects every visitor sharing the affected cache or connection pool. A successful poisoning of your homepage poisons it for every visitor until the cache is purged.
It bypasses the security tools you bought to prevent it. Web Application Firewalls (Cloudflare WAF, AWS WAF, Imperva, Akamai Kona) are explicitly defeated by smuggling because the hidden request never reaches them. Authentication checks at the proxy layer are similarly bypassed.
Your CDN does not save you — it may be the vulnerable component. In 2025 the bug-laden side of these attacks was repeatedly the CDN itself. Cloudflare's Pingora proxy (CVE-2025-4366), Akamai's edge (CVE-2025-32094, CVE-2025-66373, CVE-2025-54142), and Netlify's edge platform all shipped critical smuggling CVEs in a single year.
The economics are atypical. A single smuggling primitive can be sold for $20,000+ in a bug bounty, which gives you a market-priced sense of what the underlying access is worth to attackers who are not researchers. In PayPal's case, James Kettle's team earned $18,900 for the initial finding and $20,000 more for bypassing the first patch — meaning the bug class is hard to fix correctly even when a high-resource team is paying attention.
The fix is usually not in your code. Request smuggling is a misalignment between two HTTP parsers, not a bug in your application logic. That means most teams cannot fix it locally — they have to coordinate with their CDN, their load balancer, and their framework all at once. That is a multi-week project. The cost of not having that conversation before a researcher does is high.

Translation: if your application sits behind any combination of CDN + reverse proxy + application server (and almost every modern web product does), and your last security assessment did not specifically include desync testing against the 2024–2026 attack catalog, your infrastructure is the weak link — not your code.

Why this bug exists — in one paragraph

HTTP requests have a body whose length is determined by one of two headers: Content-Length (a byte count) or Transfer-Encoding: chunked (a streaming format with size-prefixed chunks). The HTTP spec says clients must not send both; if they do, servers must pick one and ignore the other. The problem: different servers pick differently. A frontend proxy might prefer Transfer-Encoding. A backend server might prefer Content-Length. An attacker who sends both can construct a request where the frontend sees one request and forwards it, but the backend sees two — with the second hidden inside the first. That hidden request then executes in whatever context the next legitimate user's connection had.

The same disagreement pattern shows up in dozens of variants: HTTP/2-to-HTTP/1.1 downgrades, OPTIONS + Expect headers, obsolete line folding, chunk extension parsing, Transfer-Encoding obfuscation, header CRLF injection. Each one is a different way of getting the parsers to disagree.

What attackers actually do with it

Attack 1 — Cache poisoning at scale

What an attacker does, in plain English: sends a smuggled request that asks for a critical page (homepage, login, billing) but tricks the CDN into caching their malicious response against the original URL. Every subsequent visitor who requests that URL gets the attacker's content from the cache.

Business impact: mass defacement, mass phishing (the attacker's "login page" goes to every visitor), mass malware distribution, or — most subtly — credential harvesting by replacing JavaScript on a high-traffic page. Recovery requires CDN cache purge and is publicly visible to your users.

Attack 2 — Session and credential theft via cross-user contamination

What an attacker does, in plain English: exploits the fact that backend servers commonly pool and reuse HTTP connections across users to save time. The attacker's smuggled request becomes "stuck" on a connection that the backend then assigns to the next legitimate user. When that user's headers (including their session cookie and auth tokens) attach to the smuggled request, the response can leak them back to the attacker through the very next request the attacker makes.

Business impact: targeted theft of any logged-in user's session — including admins — by simply waiting for the right connection. This is the primitive that earned the largest PayPal bounty: it allowed the researcher to inject attacker-controlled content directly into the response sent to the next legitimate user who logged into PayPal's interface.

Attack 3 — Authentication and WAF bypass

What an attacker does, in plain English: the visible (legitimate-looking) request passes through the WAF and the authentication proxy without issue. The smuggled request — hidden inside — never goes through them. It reaches the backend, which assumes "anything that reached me has already been authenticated and inspected."

Business impact: direct access to internal-only endpoints, admin APIs, debugging interfaces, internal RPC paths. WAF rules that block specific URLs, SQL injection, or known exploit payloads are silently inapplicable to the smuggled half of the request.

Attack 4 — Internal SSRF and request routing manipulation

What an attacker does, in plain English: tells the proxy "route this to internal-admin.corp" via a smuggled Host header that the proxy honors but the WAF never saw. The proxy obliges and forwards the request to internal infrastructure that was never supposed to be reachable from the public internet.

Business impact: reaches the same class of internal resources as classic SSRF — cloud metadata endpoints, internal admin panels, service-mesh control planes. Often a one-step pivot to full cloud account compromise.

The 2024–2026 CVE landscape

The reason the bug class has not died: every layer of modern HTTP infrastructure is still shipping fresh variants. A non-exhaustive list of recent disclosures:

CVE-2025-55315 — ASP.NET Core. Disclosed November 2025. Described by Microsoft engineers as "the worst .NET vulnerability ever." Affects basically all versions of ASP.NET Core shipping a Kestrel-fronted application. The variant exploits Transfer-Encoding and chunk-extensions parsing differences.
CVE-2025-4366 — Cloudflare Pingora. Disclosed April 2025. The flaw is in Pingora's handling of HTTP/1.1 persistent connections when caching is enabled. Pingora would serve a cached response but fail to fully drain the request body from the connection buffer, leaving the next request misframed. Patched within 22 hours of initial report; Cloudflare disabled CDN traffic to the vulnerable path on April 12, deployed a fix and invalidated cached assets by April 19. Affected millions of users.
CVE-2025-32094 — Akamai. Disclosed March 2025. An HTTP/1.x OPTIONS request with Expect: 100-continue and obsolete line folding caused two in-path Akamai servers to interpret the request differently. The disclosing researcher's blog describes the impact as enabling "mass compromise of user credentials from almost every company using Akamai, including tech giants, US government organizations, and SaaS providers."
CVE-2025-54142 — Akamai. HTTP request smuggling via OPTIONS + body. Same vendor, different variant, same year.
CVE-2025-66373 — Akamai. Smuggling via invalid chunked body size. Disclosed November 2025, full fix deployed November 17, 2025.
CVE-2024-47220 — WEBrick (Ruby). Request smuggling in the Ruby standard library HTTP server. Affects internal tools and admin panels still using WEBrick.

The pattern: every major edge provider shipped at least one smuggling CVE in 2025. The class is not winding down. It is widening as HTTP/2-to-HTTP/1.1 translation layers and edge functions multiply the parsing surface.

The technical mechanic — copy-pasteable

The classic CL.TE (Content-Length / Transfer-Encoding) smuggle:

POST / HTTP/1.1
Host: vulnerable.example.com
Content-Length: 6
Transfer-Encoding: chunked

0

GPOST / HTTP/1.1
Host: vulnerable.example.com
Cookie: malicious=injected
...

The frontend honors Transfer-Encoding: chunked, sees the 0\r\n\r\n terminator, treats the request as complete, and forwards it. The backend honors Content-Length: 6, reads exactly 6 bytes (the 0\r\n\r\n + G), considers the request complete, and waits on the same connection for the next request. The next "request" on the connection — already buffered — starts with POST / HTTP/1.1 (with the G prepended), making it a request to GPOST /. The backend treats the attacker's payload as a fresh request, executing in whatever connection-pool context comes next.

Modern variants include:

TE.CL. The reverse: frontend uses Content-Length, backend uses Transfer-Encoding.
TE.TE. Both honor Transfer-Encoding, but the attacker obfuscates the header (Transfer-Encoding: chunked\r\nTransfer-Encoding: x, Transfer-Encoding : chunked, etc.) so one server sees it and the other doesn't.
HTTP/2 downgrade. The frontend speaks HTTP/2 with the client and translates to HTTP/1.1 to the backend. Pseudo-headers and length-handling differences create new disagreement points.
Chunk-extension smuggling. The chunk-size line allows trailing extensions (5;foo=bar). Disagreements over how extensions are parsed produce new variants — the basis of CVE-2025-55315.
Obsolete line folding. Some servers still honor RFC 2616's deprecated multi-line headers. Folding can hide a Transfer-Encoding from one parser while leaving it visible to another. (The basis of CVE-2025-32094 on Akamai.)
0.CL desync. The "no body" trick — exploiting servers that treat a missing body differently. James Kettle's 2025 "HTTP/1.1 Must Die" research re-popularized this variant.

What "secure HTTP framing" actually looks like

Use HTTP/2 (or HTTP/3) end-to-end where possible. HTTP/2 has explicit length semantics and removes the most common ambiguity. The PortSwigger research community has been explicit through 2025–2026: HTTP/1.1 must die. The bug class effectively cannot exist in clean HTTP/2 hops.
If you must use HTTP/1.1 between proxy hops, normalize headers identically at every layer. Most modern WAFs and proxies have a "normalize and strip ambiguous headers" mode. Turn it on.
Reject ambiguous requests at the edge. Reject any request with both Content-Length and Transfer-Encoding. Reject malformed Transfer-Encoding values. Reject obsolete line folding. Reject duplicate length headers.
Disable backend connection reuse across users. Pool fragmentation kills the cross-user contamination chain that drives the worst exploits. The performance cost is small for most applications; the security upside is large.
Subscribe to your CDN's security bulletins. When Cloudflare disabled vulnerable Pingora paths in April 2025, customers who were watching had a 7-day head start on patching. Customers who were not, did not.
Test for it explicitly, on schedule. Tools: Smuggler (defparam), Burp Suite's HTTP Request Smuggler extension (James Kettle), http-garden (test fixture for parser differences). Schedule a smuggling-specific test at least once a year and after every major infrastructure change.
Patch your application servers. ASP.NET Core (CVE-2025-55315), WEBrick (CVE-2024-47220), and various Go/Rust/Node frameworks have shipped 2024–2026 patches. Pin to current releases.

The boardroom translation table

What your team says	What it means	What it could cost you
"We're behind Cloudflare / Akamai / CloudFront / Fastly"	Your edge provider had at least one CVSS-critical smuggling CVE in 2025. Their patch cadence is now your patch cadence.	Edge bug = every visitor affected. Mass cache poisoning + WAF bypass.
"We're on ASP.NET Core"	CVE-2025-55315 ("the worst .NET vulnerability ever") affects you unless explicitly patched.	Pre-auth smuggling in the framework. Patch immediately.
"Our WAF blocks the OWASP Top 10"	Request smuggling hides the malicious half of the request from the WAF entirely.	The control you bought for this risk does not apply.
"We reuse connections to the backend for performance"	Cross-user contamination is on the menu — the worst smuggling chain.	Targeted theft of any logged-in session, including admins.
"We've never tested for it"	You have not tested for the bug class that paid out $200K+ in two weeks of bug bounty submissions in 2025.	Whatever the next researcher finds, on a timeline you do not control.

Five questions a non-technical leader should ask the engineering team

"Is our traffic HTTP/2 end-to-end, or do we downgrade to HTTP/1.1 somewhere in the chain?" If there is any HTTP/1.1 hop between the user and your application, you have smuggling surface. The right next question is whether that hop is configured to normalize headers strictly.
"Which CDN and proxy software versions are we running, and when did we last apply their 2025 security patches?" Cloudflare, Akamai, ASP.NET Core all shipped patches in 2025. If your team cannot name the patch level off the top of their head, prioritize that audit.
"Do we reuse backend HTTP connections across different users' requests?" If yes — and almost every modern setup does this for performance — you have the connection-pool surface that drives the worst smuggling exploits. Ask whether the team has explicitly weighed the trade-off.
"Have we ever run a desync-specific test (e.g., Burp HTTP Request Smuggler or the open-source Smuggler) against our production-equivalent stack?" If the answer is no, that is the single highest-leverage test you can add to your next assessment.
"What is our cache-purge procedure, and how fast can we execute it across regions?" If our cache gets poisoned, recovery speed determines whether the incident is "hours" or "days." Most teams have never timed this.

What we test, every engagement involving CDN/proxy chains

Classic CL.TE and TE.CL smuggles with the canonical PortSwigger payloads.
TE.TE obfuscation: header doubling, whitespace tricks, casing tricks, value tricks.
HTTP/2-to-HTTP/1.1 downgrade smuggling (h2.cl, h2.te).
OPTIONS + Expect + obsolete line folding (the CVE-2025-32094 pattern).
Chunk-extension parsing differences (the CVE-2025-55315 pattern).
0.CL desyncs (the 2025 PortSwigger "HTTP/1.1 Must Die" pattern).
Cache poisoning end-to-end: smuggle a response, verify it persists for other users.
Connection-pool contamination: capture cookies from a smuggled response on a shared connection.
WAF bypass: confirm that smuggled payloads reach the backend without triggering visible rules.
Internal route reachability: smuggle requests against internal-only Host headers.

If your last assessment did not specifically test the 2024–2026 attack catalog — Pingora-style cache-drain bugs, ASP.NET chunk-extension variants, obsolete-line-folding tricks — your stack has not been pressure-tested against the current attacker.

Why this bug class is durable

Request smuggling sits in the seams of infrastructure that almost no one owns end-to-end. Your application team owns the application server. Your platform team owns the load balancer. Your edge provider owns the CDN. Your security team owns the WAF. The bug lives in the disagreements between these layers, which means no single team can fix it alone — and no single team can detect it without coordinated testing across the whole chain.

For attackers, that organizational gap is the feature. For defenders, it is the reason a 20-year-old bug class keeps showing up in 2025–2026 CVE feeds.

The bottom line

HTTP request smuggling is not an exotic, theoretical attack. In 2025 it took down infrastructure at Cloudflare, Akamai, and Microsoft. It paid out hundreds of thousands of dollars in bug bounties to a single researcher and his team. It compromised the core of "almost every company using Akamai." It now affects basically every version of ASP.NET Core. And it is solved nowhere — only patched.

The defenses are well-known: HTTP/2 end-to-end where possible, strict normalization where not, no backend connection reuse for sensitive contexts, regular desync-specific testing. The cost of putting them in place this quarter is small. The cost of being the next case study a researcher writes up — with your company name in the headline and your customers' cache poisoned for hours — is not.

If your stack has a CDN, a load balancer, a reverse proxy, or any frontend HTTP component (and almost every modern web product does), this conversation belongs on your security roadmap now.