HTTP Terminator Uses AI to Discover New HTTP Desynchronization Techniques

30,000 Vectors Tested on Authorized Targets

PortSwigger has introduced HTTP Terminator, an AI-assisted research system developed by James Kettle to generate and validate HTTP desynchronization techniques.

The project split 138 HTTP and SMTP RFCs into approximately 15,000 fragments, which were used to generate 30,000 candidate vectors. The same vectors were tested against 30,000 websites, all covered by authorization obtained through bug bounty or vulnerability disclosure programs.

Around 700 targets showed signs of potential vulnerabilities before undergoing more in-depth validation. The targets included banks, government infrastructure, security products, and an airport.

A technique based on the Content-Type: multipart/byteranges header worked against several server implementations and affected more than 200 sites, including an unidentified US bank.

New Attacks Against Request Parsing

HTTP Terminator produced several patterns, including a double Content-Length pattern and the dangling-byte technique. The latter is designed to make Response Queue Poisoning, or RQP, more reliable.

In RQP attacks, the frontend can lose the correct association between users’ requests and the responses generated by the backend. This can cause one user to receive a response intended for another, potentially exposing session cookies or API keys.

The dangling-byte technique leaves a smuggled request one byte short. The backend’s second response therefore remains pending until a victim’s request supplies the missing data. This reduces the race condition typically associated with RQP attacks.

The system autonomously evaluated 16 ideas for improving RQP, but only dangling-byte passed the validation phase.

The research also introduced the concept of Shared-Parser Confusion: a server that reuses the same parsing logic may incorrectly apply rules intended for processing responses to incoming requests. HTTP Terminator proposed the concept, while Kettle handled its verification and generalization.

The Apache Traffic Server Case and CVE-2026-63078

During a researcher-led investigation, a malformed request led to the identification of a zero-day in Apache Traffic Server, tracked as CVE-2026-63078.

On August 7, a public check found no corresponding record on either CVE.org or the NVD. In addition, Apache’s July advisory covering 34 vulnerabilities did not include this identifier.

According to the researchers, the issue has been fixed, but it is not yet publicly known which Apache Traffic Server release corresponds to the patched version. CVSS details, the attack vector, and the exact list of affected versions are also unavailable.

The distinction is important: some techniques were generated and demonstrated autonomously by the system, whereas the Apache vulnerability and Shared-Parser Confusion required human intervention.

How to Reduce the Risk

Where possible, administrators should avoid using HTTP/1.1 to upstream servers. If this cannot be eliminated, they should:

• apply an allowlist of HTTP methods at both levels of the chain;
• restrict the methods permitted to carry a request body;
• review Apache advisories and available security releases for Traffic Server;
• perform targeted testing for HTTP desynchronization, RQP, shared-parser confusion, and CRLF-based techniques.

Testing tools such as crlf-desyncs and crlf-powered-desync-scanner are also available. They were published by researchers specializing in CRLF-based desynchronization attacks.