CRLF-powered desync attacks turn header injection into user-impacting abuse

At a glance

What this is: NHI Mgmt Group's analysis, drawing on PortSwigger's research: CRLF-powered desync attacks can turn simple header injection into cross-user response hijacking, access control bypass, and worm-like abuse.

Why it matters: This matters because HTTP parsing flaws can cross tenant and user boundaries, exposing sessions, tokens, and backend controls that identity and security teams assume stay isolated.

Context

HTTP header injection is not just a formatting bug. When a front end and back end disagree about where one request ends and the next begins, attackers can reshape traffic, poison queues, and hijack responses intended for other users.

The identity security angle is real because these attacks routinely target session cookies, access tokens, and trust boundaries between users, applications, and shared infrastructure. For IAM, PAM, and NHI teams, the issue is not only malformed HTTP but the downstream exposure of credentials and authorization state.

Key questions

Q: What breaks when HTTP header injection is allowed to reach request boundaries?

A: The core failure is that one user’s bytes can be reinterpreted as a second request or header block, which breaks request-to-response pairing. Once the front end and back end disagree on message boundaries, attackers can poison queues, hijack responses, and expose cookies or tokens intended for other users.

Q: Why do CRLF-powered desyncs create higher risk than ordinary header injection?

A: Ordinary header injection may stay local to one response, but desyncs let the attacker influence shared connection state. That can affect other users, backend routing, and access-control decisions, which turns a formatting bug into a cross-user trust failure with session and token exposure.

Q: What are the signs that an HTTP desync issue is present?

A: Look for inconsistent status codes, unexpected extra responses, mismatched content, queue poisoning, or behaviour that changes when keep-alive, connection reuse, or browser requests are involved. If the same payload behaves differently across layers, parser disagreement is likely.

Q: How should teams respond when desync behaviour crosses into shared infrastructure?

A: Treat it as an incident affecting isolation, not only a single application bug. Contain the affected edge tier, revoke exposed session material if tokens may have been harvested, and verify whether any shared caches, CDNs, or proxy layers also accepted the malformed request path.

Technical breakdown

How CRLF becomes request splitting and queue poisoning

CRLF injection inserts carriage return and line feed characters into an HTTP request so the parser interprets attacker-controlled text as new headers or even a new request. If a proxy normalises the input differently from the backend, the two sides disagree about message boundaries. That mismatch can produce request splitting, where one request becomes two, and response queue poisoning, where responses are misassigned to other users. The dangerous part is not the raw header injection itself, but the protocol confusion that follows when shared connection state is reused across users.

Practical implication: test any path that accepts CRLF-like input for parser disagreement, not just reflected output.

Why browser-powered desyncs expand the blast radius

Browser-powered desyncs use the victim's browser as the traffic generator. When the attack is browser-compatible, an attacker can trigger fetch calls, navigation, or form-driven requests from inside a trusted user session and then reuse that browser to continue the desync chain. That matters because network locks, keep-alive reuse, and front-end restrictions no longer prevent cross-user exploitation. If the attack can also induce XSS, the browser becomes both the delivery mechanism and the persistence layer for wider abuse, including cookie theft and repeated request smuggling through normal client behaviour.

Practical implication: treat browser compatibility as an exploitation multiplier and not just an XSS concern.

How desyncs turn into access-control bypass and worm behaviour

Once an attacker can desynchronise requests, the next step is to steer traffic into backend paths the front end would normally block. In the paper's examples, that included tunnelling around access controls, stealing responses from other applications, and capturing cookies or tokens from shared infrastructure. The worm model appears when the victim's browser can be used to generate the same attack again, spreading the desync through additional users. That shifts the issue from single-target exploitation to a self-propagating trust failure across application and identity boundaries.

Practical implication: assess whether one compromised browser session can bootstrap the same attack against other users or services.

Threat narrative

Attacker objective: The attacker wants to hijack user sessions and backend trust boundaries at scale, while using desynchronised requests to harvest tokens, bypass controls, and propagate the attack.

1. Entry begins with CRLF-powered header injection in a request path, custom upstream header, cookie value, or other non-path insertion point.
2. Credential and response access follows when request splitting or response queue poisoning causes the server to mix up responses and expose cookies, access tokens, or backend data.
3. Escalation occurs when browser-powered desyncs, request tunnelling, or access-control bypass let the attacker pivot into protected application flows.
4. Impact is cross-user compromise, session theft, denial of service, and in some cases self-replicating desync behaviour that spreads through victim browsers.

Breaches seen in the wild

• Miasma and Hades Supply Chain Worms: Self-propagating supply chain worms Miasma and Hades compromise npm, PyPI, and Azure credential stores.
• Carbonato botnet 2026: A botnet puts a Hermes AI agent on exposed Docker hosts to steal AI API keys, SSH keys and tokens, powering the operators' own LLM gateway.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Header injection becomes an identity problem the moment response state is shared. The important failure is not merely malformed HTTP but the collapse of request-to-user binding across reused connections, caches, and browser-driven flows. Once responses or tokens can be misrouted, the attack stops being a web bug and becomes a session integrity issue. Practitioners should treat parser disagreement as an identity boundary failure, not a niche edge case.

Parser confusion is the named concept here: a trust gap between front-end and back-end HTTP interpretation. That gap is what allows a single CRLF primitive to mutate into request splitting, tunnelling, and response queue poisoning. The article shows that the same flaw can surface in normal proxies, CDN edges, and browser-mediated flows. Teams should look at where request canonicalisation differs across layers, because that is where user isolation breaks down.

Browser compatibility materially changes the risk calculus for desync flaws. If a payload can run inside a victim browser, the attacker no longer needs perfect direct cross-user reuse to spread the exploit. That makes cookie theft, token capture, and repeated exploitation more plausible in real environments. Security teams should model browser-mediated abuse as part of web application threat modelling, not as a separate XSS-only concern.

Shared infrastructure makes these attacks harder to reason about and easier to underestimate. The paper's CDN and telecom examples show that the blast radius can extend beyond a single application into multi-tenant or multi-service estates. That is a governance problem as much as a technical one, because ownership, triage, and containment boundaries become unclear. Practitioners should map where shared connection state could let one user's request affect another user's response.

HTTP parsing integrity deserves the same discipline as authentication integrity. If a platform lets attacker-controlled bytes redefine request boundaries, then downstream authZ and session controls can be evaluated against the wrong user context. That is why desync testing belongs in security assurance for internet-facing infrastructure. The practitioner conclusion is simple: if your gateway or CDN can be confused about message boundaries, your identity boundaries are already at risk.

What this signals

Desync risk is fundamentally about boundary control, not just input filtering. When request parsing differs between tiers, a single malformed request can become a user-impacting trust break. For practitioners, that means assurance has to cover the edge stack, browser compatibility, and any layer that reuses connection state.

Identity and session governance must assume HTTP parser confusion is an active attack path. If a platform can misroute responses, then session cookies and access tokens are no longer confined by the user boundary the architecture assumes. The practical response is to test for message-boundary integrity wherever shared infrastructure mediates authentication state.

For practitioners

• Audit every CRLF-capable insertion point Test path parameters, custom upstream headers, cookies, and other reflected values for newline handling and upstream request mutation.
• Check for parser disagreement across tiers Compare front-end, proxy, CDN, and origin behaviour for request boundary handling, especially where normalisation or decoding differs.
• Prioritise browser-compatible desync testing Validate whether fetch, navigation, or form submissions can trigger the same request confusion from a victim session.
• Harden access-control assumptions at the edge Review whether front-end allowlists, routing rules, and header stripping still hold when requests are split or tunnelled upstream.
• Contain shared-state abuse paths Map where reused connections, caches, or shared infrastructure could let one user's request affect another user's response or session state.

Key takeaways

• HTTP header injection becomes materially worse when parser disagreement lets attackers split requests, poison queues, and misroute responses across users.
• The paper shows that browser-compatible desyncs can broaden the blast radius into token theft, access-control bypass, and self-propagating abuse.
• The control gap is request-boundary integrity across all tiers, especially where proxies, CDNs, and origins reuse shared connection state.

Key terms

• Payload Splitting: Payload splitting is a prompt injection method that spreads a malicious instruction across multiple harmless-looking fragments. The model reconstructs the hidden intent from context, while filters that inspect each fragment separately may not recognise the attack until the session is already in motion.
• Queue Poisoning: Queue poisoning is the abuse of a shared request pipeline so that attacker-controlled bytes are processed as part of another user’s or another request’s traffic. It is dangerous because the attacker does not need direct code execution to influence what the back-end sees next.
• Browser-Powered Desync: Browser-powered desync is a form of exploitation where a victim browser can be used to generate the malformed request pattern that sustains the attack. This broadens exploitability because the attacker can rely on standard browser behaviour, not just specialised clients or shared server connections.
• CRLF Injection: CRLF injection occurs when carriage return and line feed characters are accepted in a context that should contain only a single value, such as an HTTP header. The sequence can terminate one field and begin another, allowing protocol splitting or request smuggling if validation is missing.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in a way that helps teams connect identity controls to broader attack paths. It is suitable for practitioners who need to align identity governance with the realities of shared infrastructure and session risk.