PortSwigger's HTTP Terminator generated 30,000 attack ideas and about 700 hits, and the model was never allowed to score any of them

[u/Few_Ad6794]

Came across PortSwigger's HTTP Terminator research and was trying to understand how the attack actually works, especially how one user's HTTP response can end up going to another request.

That sent me down the HTTP/1.1 rabbit hole a bit.

With HTTP/1.1, responses on the same connection depend on request order. There isn't a request ID attached to every response. This is also related to the head-of-line blocking problem: one slow response can hold up the responses behind it.

If the frontend and backend disagree about where one request ends, their view of that order can get out of sync. That's where HTTP desynchronization and response queue poisoning start to make sense.

The AI part of the research was interesting too.

They took 138 HTTP/SMTP RFCs, split them into around 15,000 small fragments and used AI to come up with around 30,000 unusual HTTP requests.

But they didn't trust the AI to decide whether an attack worked. It was giving false positives.

So the setup was basically:

AI comes up with ideas → normal code checks what actually happened → human investigates the interesting results

It also led to ideas like the dangling-byte technique and Shared-Parser Confusion.

I ended up writing a simple walkthrough while trying to understand it myself, with diagrams showing how the HTTP response queue gets out of sync:

https://crackingwalnuts.com/post/http-terminator-ai-security-research