Notifications
Clear all
Topic starter
02/08/2026 12:23 pm
TL;DR: HTTP/1.1 still underpins around half of internet traffic, and upstream downgrades inside CDNs, proxies, and service meshes keep request smuggling viable at enterprise scale, according to PortSwigger. The real risk is architectural, not patchable, and HTTP/1.1 removal is the only durable fix.
NHIMG editorial — based on content published by PortSwigger: HTTP/1.1 must die: Dafydd Stuttard on what this means for enterprise security
By the numbers:
- James Kettle and collaborators netted over $350k in bug bounties after compromising virtually every customer of several major CDNs.
- They affected a total of around 30 million websites.
Questions worth separating out
Q: What breaks when HTTP/1.1 request smuggling is present in enterprise stacks?
A: Parser disagreement lets attacker-controlled bytes cross request boundaries, which can corrupt backend routing and expose one user’s session or response to another.
Q: Why do upstream HTTP/1.1 hops increase enterprise risk?
A: Upstream HTTP/1.1 hops matter because the browser may be secure while the internal path is not.
Q: What do security teams get wrong about request smuggling detection?
A: They often rely on standard web scans that do not reproduce the exact parser disagreement required to expose desync.
Practitioner guidance
- Inventory every upstream HTTP hop Map CDN to origin, proxy to application server, and service-to-service paths to identify where HTTP/1.1 still exists, including hidden downgrades inside vendor-managed infrastructure.
- Set a no-HTTP/1.1 policy Require HTTP/2 or higher on every upstream connection and make exceptions explicit, time-bound, and owned by the architecture team rather than left to default vendor behaviour.
- Add protocol-aware desync testing Use tooling that can manipulate the HTTP stack at the protocol level and validate findings against edge, proxy, and origin combinations before release.
What's in the full article
PortSwigger's full analysis covers the operational detail this post intentionally leaves for the source:
- Whitepaper-level walkthrough of the desync techniques demonstrated at Black Hat USA 2025 and DEF CON 33
- Tooling detail for Burp Suite Professional and Burp Suite DAST protocol-level detection workflows
- Manual validation steps for confirming request smuggling exposure across edge, proxy, and origin paths
- Practical guidance on eliminating HTTP/1.1 from upstream connections in large estates
👉 Read PortSwigger's analysis of HTTP/1.1 request smuggling and enterprise risk →
HTTP/1.1 request smuggling: is your upstream traffic really safe?
Explore further
02/08/2026 1:23 pm
HTTP/1.1 persistence is now an upstream trust problem, not just a protocol legacy issue. The article shows that the weak point often sits beyond the front-end, inside CDN, proxy, and service-to-service paths that enterprises assume are stable. That matters because modern identity and session security depends on consistent request handling across the entire chain. When one hop still interprets traffic differently, the organisation inherits a trust gap that no perimeter control can fully compensate for. Practitioners should treat upstream protocol inventory as part of identity and access assurance.
A question worth separating out:
Q: Who is accountable when a vendor silently downgrades HTTP/2 to HTTP/1.1?
A: The enterprise remains accountable for the business risk even when the downgrade happens in supplier-managed infrastructure. That means architecture, procurement, and security teams should require evidence of where HTTP/1.1 remains and whether it can be disabled. The control gap is shared, but the obligation to verify is not.
👉 Read our full editorial: HTTP/1.1 request smuggling exposes upstream trust gaps in enterprise stacks
