AI Research Tool Finds New Web Server Attack Tricks and an Apache Zero-Day
PortSwigger's James Kettle ran an AI-assisted system called HTTP Terminator against 30,000 sites, turned up fresh HTTP desync techniques, and then found a previously unknown flaw in Apache Traffic Server by following one of its leads by hand.
Key points
- PortSwigger's James Kettle built HTTP Terminator, an AI-assisted research system that generated and proved new HTTP desynchronization techniques.
- The tool explored 30,000 candidate attack vectors tested against 30,000 real websites.
- A separate human-guided follow-up uncovered a zero-day flaw in Apache Traffic Server, an open-source proxy used by large sites and telcos.
- PortSwigger makes Burp Suite, the widely used web security testing platform.
- Defenders should expect more AI-assisted fuzzing research now that this approach is public.
PortSwigger has shown off a research system that used artificial intelligence to invent new ways to attack web servers, and it worked well enough to surface a zero-day in widely used open-source software.
The tool is called HTTP Terminator. James Kettle, PortSwigger's director of research, built it. The Hacker News covered the initial write-up.
What did the tool actually do?
HTTP Terminator hunted for HTTP desynchronization attacks, a class of bug where an attacker hides a second request inside a normal-looking one. Front-end and back-end servers disagree on where one request ends and the next begins. That gap lets an attacker poison other users' sessions or bypass security controls.
Kettle's earlier HTTP request smuggling research reshaped how big sites configure their front-end proxies. The new twist is scale. HTTP Terminator explored 30,000 candidate attack vectors across 30,000 real websites, rather than a human hand-crafting a few dozen malformed requests. PortSwigger is clear that the AI isn't doing the thinking independently: it proposes candidates, the system runs them, and checks whether results look like a genuine desync.
Why does this matter to ordinary internet users?
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.
This attack doesn't show up in your inbox. It happens between servers. But if your bank or your hospital portal sits behind a misconfigured content delivery network, meaning the caching layer that speeds up websites, a desync bug can let an attacker hijack a logged-in session without ever touching a password.
There's 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 move traffic at scale. PortSwigger calls the method a "discovery cascade": the AI flagged something odd, a human looked closer, and a real bug fell out.
This isn't the first time AI-assisted tooling has delivered a working zero-day on its own. We covered a similar pattern on 15 July 2026, when Intruder wired large language models into code-analysis tools and produced a working exploit for an unknown WordPress plugin flaw. The gap between "AI-assisted" and "AI-autonomous" is closing faster than most defenders have planned for.
Details on the specific CVE and patched version weren't in the initial write-up. Anyone running Apache Traffic Server should watch the official project security advisories and patch as soon as a fix lands.
What defenders should take from this
Request smuggling isn't a solved problem. Every time a researcher builds a bigger fuzzer, more of it surfaces. Most affected companies don't know their front-end and back-end servers disagree until someone proves it to them.
The failure mode is architectural. A CDN, a load balancer and an origin server each have slightly different opinions about a weird HTTP header, and attackers live in that gap.
Four concrete moves worth doing this quarter:
- Run PortSwigger's HTTP Request Smuggler and the newer desync checks against your own edge.
- Force HTTP/2 end to end where you can, rejecting ambiguous Content-Length and Transfer-Encoding combinations at the edge.
- Alert on backend responses that don't match the request your edge thinks it sent.
- Track the Apache Traffic Server advisory list and patch on release, not next quarter's change window.
The honest read here: if you run anything behind a CDN, a machine is probably already fuzzing your edge. Treat the audit as overdue.
