Burp AT: Automating CRLF-Powered Desync via HTTP Header Injection in Four Phases

1. Basic Information

• Article Title: Making HTTP header injection critical with one prompt
• Publisher: PortSwigger Research
• Publication Date: 2026-11-04
• Collection Date: 2026-11-05T08:02:41+09:00
• Source: PortSwigger Research
• Associated Malware: None
• Associated Threat Groups: None
• CVE: None
• Target Products/Services: Burp AT, Burp Scanner
• Severity: High
• Basis of Severity: It automates practical techniques that can escalate existing header injection into desync, redirect, and cache poisoning chains. However, this is a research and tooling article that avoids response queue poisoning in favor of a less destructive redirect test, rather than describing an active exploitation case in a specific product. The redirect test can still affect real users.

2. Executive Summary

PortSwigger's Burp AT automates four stages from an existing HTTP request header injection finding: identifying the upstream injection position, testing request splitting, finding an open-redirect gadget, and verifying a redirect. It reports evidence at each stage of CRLF-powered desync validation. The chosen redirect test reduces risk compared with response queue poisoning but can still affect real users.

3. Research Question

• How can HTTP request header injection be safely and reproducibly escalated into CRLF-powered desync evidence?
• Can an agentic scanner determine success confidence levels step-by-step while avoiding dangerous exploits?

4. Proposed Approach

• Implement a four-phase Burp AT skill to estimate the upstream injection position, validate request splitting, find a redirect gadget, and reproduce a redirect to Burp Collaborator. The final test still requires precautions against impact on other users.

5. Inputs and Outputs

• Input: An HTTP request header injection issue already detected by Burp Scanner.
• Parameters: The target HTTP request, insertion point, and target domain.
• Output: A tentative header injection issue, validated desync, or a validated redirect exploit, with supporting evidence.
• Branches: If Phase 3 finds no redirect gadget, report validated desync without exploit evidence. Separately, if Phase 2 determines that full desync is impossible, fall back to the CRLF-Powered Tunnelling skill to look for an access-control bypass. If that also fails, retain a pre-populated Intruder session for manual follow-up.

6. Workflow

1. Phase 1: Estimate where injected CRLF appears in the upstream request by comparing response status codes.
2. Phase 2: Fuzz splitting prefixes and collect two or three distinct statuses as evidence that prefixes modify the upstream request. This is a heuristic requiring confirmation in the target environment.
3. Phase 3: Search for open redirects depending on Host, X-Forwarded-Host, or an absolute URL.
4. Phase 4: Combine the request structure and redirect gadget, point the redirect at Burp Collaborator, and check reproducibility across independent connections.

The Phase 2 fallback when full desync is impossible is separate from Phase 3 failing to find a redirect gadget; see Section 5.

7. Evaluation Design

• Evidence levels: Tentative, validated desync, and validated redirect exploit.
• Safety: The workflow avoids response queue poisoning and chooses a less destructive redirect test. Real users can still receive the redirect; this is not a guarantee of harmless production testing.
• Bail points: Insufficient distinct statuses in Phase 2 produce a tentative issue. No redirect gadget in Phase 3 produces validated desync without exploit evidence. The tunnelling fallback when Phase 2 establishes that full desync is impossible is a separate branch.

8. Results

• Status-code differences are used as heuristic evidence of upstream request splitting; they require human validation in the target environment.
• If a redirect gadget exists, the workflow can reproduce a desync primitive that returns an attacker-controlled redirect to a third-party user.
• Without a gadget, it reports validated desync; with insufficient status-code evidence, it retains a tentative issue rather than overstating the result.

9. Practical Implications

• The workflow helps testers assess whether a header injection finding can develop into request smuggling across a proxy chain.
• A confirmed primitive may support full-site takeover when combined with cache poisoning. That requires additional cache-poisoning conditions and does not follow for every target.

10. Success Conditions

• The injected CRLF must reach the upstream request structure.
• Reproducible status code differences must be obtained across multiple prefixes.
• Progressing to an exploit requires a controllable redirect gadget via the Host header or similar mechanisms.

11. Limitations

• To prevent dangerous queue poisoning in real environments, maximum impact is not directly demonstrated.
• Benchmark counts, accuracy, and proxy product coverage are not provided.
• Human review of agent results, scope, and evidence is required.

12. Facts / Inference / Hypothesis

Facts

• Burp AT's CRLF-Powered Desync skill takes HTTP request header injection detected by Burp as input.
• Phase 1 estimates which header position in the upstream request the injection appears in based on status differences.
• Phase 2 uses multiple prefix payloads to verify request splitting; if two to three distinct status codes are obtained, it proceeds as evidence of upstream request modification.
• Phase 3 uses a mini-crawl to search for open redirect gadgets dependent on Host, X-Forwarded-Host, or absolute URLs.
• Phase 4 directs the redirection destination to Collaborator, reporting an evidence-backed issue if expected responses are reproduced across multiple connections.
• It avoids response queue poisoning but can still redirect real users. No gadget in Phase 3 produces validated desync without exploit evidence; insufficient Phase 2 status evidence produces a tentative issue. The separate Phase 2 full-desync-impossible branch invokes the tunnelling fallback described in Section 5.
• Confirmed desync primitives can lead to full-site takeover when combined with cache poisoning.

Inference

• Phased bail points and evidence preservation serve as a design pattern to minimize false positives and production impact in agentic security testing.

Hypothesis

• Additional evaluation is needed to determine how stably the same heuristic performs across different proxy/CDN chains or non-standard status behaviors.

13. MITRE ATT&CK Mapping

As this research focuses on vulnerability verification methodology, no specific campaign ATT&CK mapping is performed.

14. Required Additional Evidence

• Status code differences reproduced with different prefixes.
• Response differences indicating upstream header positions.
• Multiple connection reproduction for redirect gadgets and Collaborator responses.
• Correlation between backend/proxy logs and test timestamps.
• Benchmark target counts, false positive/false negative rates, and production-scale safety evaluations are not stated in the article.

15. Implications for Defenders

AppSec and red teams should limit automated verification phases to authorized scopes and test environments. Defenders should not close header injection findings as low severity without checking proxy chains and cache behavior.

• Use only within authorized test environments and scopes, and monitor for production impact.
• Header injection remediation should verify CRLF rejection, header canonicalization, proxy/backend parsing consistency, and cache keys.

16. Summary by Target Audience

• SOC Teams: Monitor status code differences, redirects, cache behavior, and backend mismatches following header injections.
• Administrators: Verify header normalization and CRLF rejection across reverse proxies, CDNs, and applications.
• Users: No direct actions required. Follow remediation instructions provided by service administrators.