How AI Helped Find New HTTP Attacks, and What It Actually Did

An automated system read the HTTP specifications, invented attacks nobody had tried, and hacked live websites with them. The interesting part is not the bug it found. It is which decisions the AI was trusted with, and which ones were taken away from it.

A security research project called HTTP Terminator is interesting for two reasons. It found new HTTP vulnerabilities. And the way AI was used inside it is worth copying, even if you never touch security.

The researcher is James Kettle, Director of Research at PortSwigger, known online as @albinowax. He has been working on HTTP request smuggling for years. This research was published on 5 August 2026 and presented at Black Hat USA 2026 and DEF CON 34.

The question he set out to answer was simple to say and hard to do:

Can AI go past finding known bugs, and actually help invent new attack techniques?

To follow the answer, you first need the security problem.

First, what is HTTP desynchronization?

A website is rarely one machine. There's usually something in front:

You → front-end server (CDN, load balancer, proxy) → back-end server → the application

The front-end takes traffic from the internet and passes it to the back-end.

Normally both agree on where one request ends and the next begins. Request 1 is request 1 to both of them. No problem.

But HTTP/1.1 lets many requests travel down the same reused connection. So if the two servers read the same bytes differently, they stop agreeing about the boundaries.

That disagreement is the whole bug. It's called HTTP request smuggling, or HTTP desynchronization.

Notice what didn't happen. Nobody found a password. Nobody ran code they shouldn't have. Two pieces of software simply drew the line in a different place.

So how does the proxy know which answer belongs to whom?

This is the bit that makes everything else click, and the answer is smaller than you would expect.

You would assume the answer carries something like requestId: 123. It doesn't. HTTP/1.1 has no such field. The proxy pushes questions down the connection and reads answers back off it, and the only thing tying a question to its answer is the order they went in.

That one fact also explains a much older complaint. Answers can't overtake each other on a connection. So a page that's ready in ten milliseconds sits and waits behind one that takes five seconds. People call that head-of-line blocking. It's the same fact wearing a different hat.

Now look again at what the attacker did. The back-end isn't confused, and it isn't sending anything in the wrong order. It answers its four questions in perfect order. The trouble is the proxy only wrote down three of them.

From that moment the two of them are counting different lists.

Why is that dangerous?

The back-end has produced two answers. The front-end is only waiting for one.

So it hands the first answer back to the attacker and ticks that request off. The second answer is left sitting on the connection, and every answer from here lands one seat along.

This is called Response Queue Poisoning. Kettle's research notes that the leaked answers can carry things like session cookies and API keys.

The important part is worth saying again. Nothing was cracked. The queue slipped by one place, and stayed slipped.

Is this only an HTTP/1.1 problem?

Largely, yes, and that is worth knowing.

HTTP/2 gives every exchange a stream id. The answer for stream 5 can come back before the answer for stream 1 and still reach the right person, because nothing is being counted in the first place.

But hardly anyone runs HTTP/2 the whole way down. The common shape is HTTP/2 from the browser to the front-end, then plain HTTP/1.1 from the front-end to the back-end.

So the front-end has to rewrite every request as it passes through. If that rewriting leaves any doubt about where a request ends, the old problem walks straight back in.

So the weak spot is rarely a protocol version on its own. It's the seam where one version gets translated into another.

Now the AI part

Kettle did not open a chat window and type "find HTTP vulnerabilities". He tried things close to that, and they did badly. The models mostly gave back attacks that already exist, or ideas that were not worth testing. Running a weak prompt ten thousand times doesn't give you ten thousand good ideas.

So he built a system instead, with four stages:

Ideation → Evaluation → Weaponization → Cascade

Step 1: feed the AI very small pieces

RFCs are the rulebooks for internet protocols. They say how Content-Length works, how headers are parsed, what counts as the end of a message.

Instead of handing a whole RFC to the AI, Kettle used what he calls micro-inspiration. He cut the specifications into fragments of one to three sentences and gave the AI one fragment at a time.

There's a good reason for that. Give a model a lot of related context and it settles into what it already knows. It repeats the famous attacks. Give it one small odd rule and no room to be reminded of anything, and it has to actually think about that rule.

Most of those 30,000 ideas were rubbish. That's fine. You don't need a high hit rate when testing is cheap.

Step 2: never let the AI decide whether it worked

This is the part I would keep even if you have no interest in HTTP.

The AI made the ideas. It didn't get to mark them.

The test was almost boringly simple. Send a normal request and note the normal answer. Then send one of the AI's odd requests, and send the normal request again. If the normal request suddenly gets a different answer, something on that connection changed how the server read it. That's worth a look.

The checker was built as a Burp Suite extension with a SQLite database behind it. It ran against about 30,000 websites where testing was allowed, through bug bounty or disclosure programmes. One AWS machine, 2,000 threads, one request per second per domain.

That left roughly 700 sites worth investigating.

Step 3: one strange rule, one real discovery

One of the fragments involved multipart/byteranges. That normally belongs to answers, not questions. It is the format a server uses when it sends back several chunks of a file.

A specialist studying request smuggling would probably skip past it, because it lives on the wrong side of the conversation.

The AI didn't know to skip it. Its first attempt didn't work, but a simpler version did, across several different server products. It exposed more than 200 sites in the test set, including an American bank.

The AI didn't hand over a finished exploit. It asked a question a specialist would not have bothered to ask.

Step 4: AI, code and people are not interchangeable

Turning odd behaviour into proven impact was the next stage. Kettle wired Turbo Intruder into the system and used AI agents to build the proofs.

Then the AI started claiming attacks had worked when they had not. Rewriting the prompts didn't fix it.

So he changed the shape of the system instead of the wording. Anything with a definite right answer moved into ordinary code that the model couldn't touch or argue with. He reports that the validation ended up with zero false positives.

If you build anything with AI in it, that's the line to remember. Give the model the uncertain work. Give the code the verdict.

Step 5: the dangling byte

Response Queue Poisoning had a practical problem. The attacker had to land the hidden request in the narrow gap before a real user showed up. Sometimes it worked, sometimes it didn't.

The AI produced 16 ideas for fixing that. Fifteen failed. One survived, and it's genuinely clever.

Leave the hidden request one byte short. The server can't finish it, so it waits. When a real user's request arrives, its very first byte completes the attacker's request.

The attacker no longer has to guess the timing. The trap just sits there until somebody walks into it.

Kettle lists this among the techniques the system invented and proved on its own.

Step 6: feed the findings back in

The last stage was the Cascade, and it is the reason this reads like research rather than scanning.

Real research doesn't end at the answer. One odd result raises a new question. Why did that happen? Would another server do the same? What design decision caused it, and what else would that decision break?

So discoveries were fed back in as the starting material for the next round of ideas.

That loop is what eventually surfaced a previously unknown bug in Apache Traffic Server, now patched as CVE-2026-63078.

Worth being straight about this one. It wasn't a hands-off AI discovery. Kettle was analysing the findings and changing the detection system as it went.

Step 7: the idea I keep thinking about

The best result wasn't a bug at all. It was a question, and Kettle calls it Shared-Parser Confusion.

Go back to multipart/byteranges, the rule that belongs to answers. The AI asked what happens if the server uses the same parsing code for both answers and questions.

If one piece of code handles both, then a rule written for answers might be reachable from a question. Nobody wrote that door. It exists because the code was shared.

That's not one vulnerability. It is a place to go looking for more of them.

Kettle is clear that this one wasn't autonomous either. In his words, the HTTP Terminator proposed it and he validated it, and neither would have found it alone.

Why this matters outside security

Most AI tools still look like this: question in, answer out, hope it's right.

This looked like something else:

Take real knowledge. Generate a hypothesis. Run the experiment. Measure it. Throw away what failed. Look hard at what surprised you. Use that to generate better hypotheses. Repeat.

That's just how science works, and it changes what the model needs to be. It doesn't need to be right. It needs to produce enough plausible ideas that a cheap, honest test can sort them.

The pattern travels anywhere you can automate the experiment:

AI generates the possibilities. Code decides what survives. A person decides what any of it means.

The goal was never to take the human out. It was to work out which of the three should be trusted with which job.

Researcher: James Kettle, Director of Research at PortSwigger (@albinowax)

Primary source: Can AI do novel security research? Meet the HTTP Terminator. PortSwigger Research, 5 August 2026. https://portswigger.net/research/can-ai-do-novel-security-research