AI Research Tool Finds New Web Server Attack Tricks and an Apache Zero-Day
PortSwigger's James Kettle put an AI-assisted system called HTTP Terminator against 30,000 sites and turned up fresh HTTP desync attacks plus a previously unknown flaw in Apache Traffic Server.
Key points
- PortSwigger revealed HTTP Terminator, an AI-assisted research system built by James Kettle, which found new HTTP desynchronization attack techniques.
- The tool generated and tested 30,000 candidate attack ideas against real websites.
- A separate human-guided follow-up uncovered a zero-day flaw, meaning a bug the vendor did not know about, in Apache Traffic Server.
- The work was disclosed by PortSwigger, the company behind the Burp Suite security testing tools.
- Defenders should expect a wave of copycat research now that the technique is public.
PortSwigger has shown off a research system that used artificial intelligence to invent brand new ways to attack web servers, and it worked well enough to also stumble into a zero-day in widely used open-source software.
The tool is called HTTP Terminator. It was built by James Kettle, PortSwigger's director of research, and first written up by The Hacker News.
What did the tool actually do?
HTTP Terminator hunted for HTTP desynchronization attacks, a class of bug where an attacker sneaks a second, hidden request inside a normal-looking one. The web servers sitting in front of a site disagree on where one request ends and the next begins. That disagreement lets the attacker poison other users' traffic, steal sessions, or bypass security controls.
Kettle has been the loudest voice on this class of attack for years. His previous "HTTP request smuggling" talks reshaped how big sites configure their front-end proxies.
The new twist is scale. Instead of a human researcher hand-crafting a few dozen malformed requests, HTTP Terminator generated 30,000 candidate attacks and threw them at 30,000 real websites to see which ones the servers processed in surprising ways. PortSwigger says the AI part is not doing the thinking on its own. It proposes ideas, runs them, and the system checks whether the results look like a genuine desync.
Why does this matter to ordinary internet users?
In plain terms: the plumbing that carries your web traffic has more cracks in it than anyone realised, and a machine can now find them faster than a human can.
You will not see this attack in your inbox. It happens between servers, not on your laptop. But if your bank, your airline or your hospital portal is behind a misconfigured content delivery network, meaning the big caching layer that speeds up websites, a desync bug can let an attacker hijack another user's logged-in session without ever touching a password.
There is nothing for a normal user to patch. The fix has to happen at the companies running the servers.
The Apache Traffic Server zero-day
During the same research, Kettle followed one of the tool's leads by hand and found a previously unknown flaw in Apache Traffic Server, an open-source proxy used by large sites and telcos to shuttle traffic at scale. PortSwigger describes it as a "discovery cascade": the AI flagged something odd, a human looked closer, and a real bug fell out.
Details on the specific CVE identifier and patched version were not published in the initial write-up. Anyone running Apache Traffic Server should watch the official project security advisories and update as soon as a fix lands.
What defenders should take from this
One thing the post-mortem will say, repeatedly, over the next year: request smuggling is not a solved problem. Every time a researcher builds a bigger fuzzer, more of it turns up. In practice, most affected companies do not know their front-end and back-end servers disagree until someone shows them.
The failure mode here is architectural. You have a content delivery network, a load balancer and an origin server, and each one has slightly different opinions about a weird HTTP header. Attackers live in that gap.
A few concrete moves are worth doing this quarter:
- Run PortSwigger's own HTTP Request Smuggler and the newer desync checks against your own edge.
- Force HTTP/2 end to end where you can, and reject ambiguous Content-Length and Transfer-Encoding combinations at the edge.
- Alert on backend responses that do not match the request your edge thinks it sent.
- Track the Apache Traffic Server advisory list and patch on release, not on next quarter's change window.
Operational takeaway: if you run anything behind a CDN, assume a machine is already fuzzing your edge, and act like the audit is on Monday.
