Notifications
Clear all
Topic starter
11/08/2026 3:13 pm
TL;DR: Simple HTTP header injection can be escalated into request splitting, response queue poisoning, browser-powered desyncs, and even self-replicating worms that steal cookies and tokens or bypass access controls, according to PortSwigger. Header injection is not a low-impact bug when parser confusion lets attackers cross user boundaries and hijack responses.
NHIMG editorial — based on content published by PortSwigger: CRLF-Powered Desync Attacks: Beheading HTTP Streams
Questions worth separating out
Q: How should security teams prevent CRLF injection from turning into request smuggling?
A: Teams should remove parser behaviour that lets encoded CRLF sequences reach request boundaries, especially in proxies and upstream header handling.
Q: Why do desync flaws expose session cookies and access tokens so quickly?
A: Because once responses are queued for the wrong client, the attacker is no longer limited to malformed syntax.
Q: What do organisations get wrong about browser-powered desync attacks?
A: They often assume exploitation requires special tooling or a shared back-end connection.
Practitioner guidance
- Eliminate CRLF-prone proxy variables Remove $uri and $document_uri from proxy_pass and return configurations where normalisation can turn encoded CRLF into request structure, and review any regex-based variables that fail to exclude whitespace.
- Test for queue misalignment across tiers Run desync-focused testing on CDN, reverse proxy, and application combinations to confirm that one client cannot receive another client’s response or queued session material.
- Treat browser-replay paths as exploit chains Check whether fetch, navigation, or any browser-controlled request can be chained into request splitting or tunnelling, then block the browser-powered path before it can spread abuse.
What's in the full report
PortSwigger's full research covers the operational detail this post intentionally leaves for the source:
- Full exploit examples for request splitting, request tunnelling, and reverse desync cases across different parser behaviours
- Detailed payload construction and detection techniques for Nginx, OpenResty, and CDN edge scenarios
- Browser-powered exploit patterns, including fetch-based triggering and self-replicating desync worm mechanics
- Defensive tooling references, labs, and open-source scanner details for hands-on validation
👉 Read PortSwigger's research on CRLF-powered desync attacks and HTTP header injection →
CRLF-powered desync attacks: where do HTTP controls break down?
Explore further
11/08/2026 3:27 pm
Header injection becomes an identity problem the moment it exposes session-bound material. The research shows that parser desync can move from application integrity to credential theft when cookies, access tokens, or authenticated responses are captured. That changes the control question from input validation to session trust and boundary enforcement. For practitioners, the lesson is that session material is only as safe as the weakest parser in the request path.
A question worth separating out:
Q: Who is accountable when request splitting bypasses access controls?
A: Accountability sits with the teams that own the full request path, not just the application team. Access controls, proxy configuration, CDN behaviour, and session handling all contribute to the outcome. Frameworks such as NIST SP 800-53 and MITRE ATT&CK help teams map that shared responsibility to control ownership and detection coverage.
👉 Read our full editorial: CRLF-powered desync attacks turn header injection into user-impacting abuse
