CRLF-Powered Desync: Verify HTTP Request Header Injection Safely

PortSwigger’s November 4, 2026 research update describes a Burp AT skill and scan check that can take an HTTP request header injection finding through several desynchronization checks. The announcement builds on the team’s August research into CRLF-powered desync attacks. It does not establish that every header injection is request smuggling, or that every application behind an HTTP/1.1 hop has cross-user impact.

The practical task is to find the highest evidence level an authorized environment actually supports. A header delimiter reaching an upstream request is one result. A second request being parsed is another. A front end and back end losing agreement over response ownership is a much stronger and more dangerous result. Keep those conclusions separate.

Use an evidence ladder instead of one severity label

PortSwigger’s published skill describes bail points: a failed gadget search can still leave a validated desync, while insufficient boundary evidence may produce a tentative result. Preserve that distinction in the exported finding. “Critical” should describe demonstrated impact and deployment conditions, not the presence of the letters CR and LF in a test value.

First identify the request path that matters

Draw the complete path from the client to the application: CDN, load balancer, reverse proxy, service mesh, gateway and origin. Record the protocol used on every hop. The public endpoint may negotiate HTTP/2 or HTTP/3 while a proxy still constructs HTTP/1.1 requests upstream. Conversely, an HTTP/1.1 client connection does not prove that a vulnerable transformation happens behind it.

For each hop, answer four questions:

• Which attacker-controlled value is copied into an upstream header, path or request line?
• Where are percent-decoding, normalization and line-ending validation performed?
• Does the next hop reuse connections, and how does it delimit request bodies?
• Which logs can tie a front-end request ID to the origin request and response?

RFC 9112 section 2.2 requires HTTP messages to be parsed as octets and defines handling for line endings and invalid whitespace. Its message-length rules also require ambiguous framing combinations to be rejected or normalized before forwarding. Use those rules as a review baseline, then verify the actual proxy and application behavior; a standards citation alone does not prove the deployed chain is safe.

Build a contained verification environment

Do not begin with a shared production connection pool. Recreate the relevant proxy-to-origin path in an isolated environment, with a dedicated hostname, synthetic data and no real users. Disable unrelated caches and integrations unless they are part of the suspected boundary. Retain sanitized front-end and origin logs with timestamps, connection identifiers and request IDs.

Start with non-destructive controls. Send a normal request and confirm that both layers record the same request. Send an invalid but harmless input that should be rejected, and confirm where rejection occurs. Only then allow a bounded boundary check using a dedicated origin that records parsed requests without performing application actions. The expected safe result is rejection before an extra request reaches the origin.

Stop if traffic reaches an unapproved service, a shared cache changes state, another session is affected, the origin becomes unstable or the test cannot be attributed to the dedicated connection. A timeout, an unusual status code or stacked bytes in a client view can guide investigation, but none is sufficient by itself. Correlate what the front end sent with what the origin parsed.

Keep positive and negative controls together

If a second request is recorded, do not immediately escalate to cross-user testing. Capture the exact software versions, configuration, insertion point, upstream protocol and connection behavior. Reproduce once on a fresh isolated connection. Then pause for a separate impact decision. Response queue poisoning, cache poisoning and victim-browser techniques can affect unrelated users and require explicit additional authorization and stronger containment.

Fix the construction boundary and verify the running path

Remove unsafe string construction of upstream messages. Reject CR and LF before controlled values enter request lines or headers, and use structured server and proxy APIs that serialize fields. Review path rewriting and custom forwarding headers because the public input location may differ from its upstream location. Apply relevant vendor updates and configuration guidance to every component that transforms the request.

Using a protocol without ambiguous HTTP/1.1 framing on the vulnerable upstream hop can reduce some desync classes, but it is a deployment decision rather than a substitute for input validation. A WAF rule can also be a temporary control for traffic it can see. Neither measure repairs unsafe header construction inside an application or proxy.

After deployment, record the running proxy and application versions, active configuration checksum, restart or rollout identifier, and the two controls above. Keep the original affected observation, the patched rejection and a working normal request in one evidence set. If only a source change or proposed configuration exists, remediation remains unverified.

Evaluate an automated tool with the same evidence standard

When evaluating an automated or agentic test, give it the isolated target and one known insertion point. Require it to show the sanitized request transformation, origin-side observation, connection scope, stop reason and confidence level. Review tentative findings separately from validated request splitting or desync. An impressive generated narrative should not outrank the origin evidence.

For a bounded workflow comparison, create one authorized Penligent task after installation and registration. Use the same isolated target, allowed route and stop conditions, and verify the current client’s traffic and evidence handling before granting access. This is not a claim that Penligent implements PortSwigger’s research skill or reproduces the reported technique. The Penligent product video provides general workflow context only.

Method: AI-assisted primary-source review and an original defensive verification framework, checked November 6, 2026. No desync payload was run, no remote target was tested, and no product result is reported.