A human and an AI teamed up to find hundreds of hackable websites. The results rewrote the rulebook.

Key points

• HTTP Terminator, an AI research system built by PortSwigger security researcher James Kettle, tested 30,000 unique attack methods and identified 700 vulnerable websites, including financial institutions and government infrastructure.
• The system successfully extracted a live API key (a secret password that systems use to talk to each other) from at least one bank during testing, carried out under authorised bug-bounty programmes.
• Kettle and the AI together discovered a previously unknown category of vulnerability called "shared-parser confusion," which expands the range of systems attackers could target.
• Kettle has released the system and his research blueprint publicly so other security teams can replicate the approach.
• The central finding is not that AI can replace researchers, but that a skilled human guiding an AI produces results neither could reach alone.

---

Security researcher James Kettle has published a white paper describing how he built an AI system, gave it a clear mission, and then stayed in the driver's seat the whole time. The result challenges a popular assumption: that the most powerful AI security tools are the ones that work without human input.

Kettle leads research at PortSwigger, the company behind the widely used Burp Suite web-security testing tool. His AI system is called HTTP Terminator.

What problem was HTTP Terminator hunting?

It targeted a class of flaw called HTTP request smuggling, where an attacker sends a specially crafted message to a website that tricks the site's servers into misreading where one visitor's request ends and another's begins.

To understand why that matters, picture a post room with two desks. The front desk receives all incoming letters and passes them to a back desk for processing. If the two desks disagree about where one letter stops and the next starts, a crafty sender can hide a second secret letter inside the first. That hidden letter gets processed as if it were legitimate, potentially letting the sender see another customer's private information, steal login credentials, or bypass security checks entirely.

Websites running this kind of split architecture (a front-end server passing traffic to back-end servers) are common. The vulnerabilities can be severe. Kettle describes them as "often critical in nature."

How did the AI actually work?

Kettle built HTTP Terminator around four stages he calls ideation, evaluation, weaponization, and cascade.

First, the system generated hypotheses: 30,000 distinct ways an attacker might exploit request smuggling. Second, it tested those ideas at scale against real websites that had given permission for security research through bug-bounty programmes (schemes where companies invite researchers to find flaws in exchange for a reward). An anomaly-detection layer, meaning software that flags responses that look unusual, highlighted promising results.

Third came weaponization: checking whether a flaw could cause real harm. Here the system crossed from theory into fact. It found 700 vulnerable targets and, in at least one case, extracted a live API key from a bank's systems. Flaws in enterprise products including Apache Traffic Server, Citrix NetScaler, and BeyondTrust were also implicated.

Fourth, each finding fed back into the system as a starting point for the next round of questions. Kettle calls this the "cascade" effect: one discovery becomes the seed for the next.

Stage	What happened	Scale
Ideation	Attack hypotheses generated	30,000 vectors
Evaluation	Live testing on authorised sites	Continuous
Weaponization	Vulnerable targets confirmed	700 sites
Discovery	New vulnerability class found	"Shared-parser confusion"

What is "shared-parser confusion" and why does it matter?

It is a genuinely new category of web vulnerability, one that lets attackers manipulate how a website reads both incoming requests and outgoing responses. This widens the range of systems that could be attacked using smuggling techniques. Kettle called it "absolutely huge."

Critically, he did not find it alone, and neither did the AI. The system proposed the idea; Kettle validated it. He is direct about the implication: "Neither of us would have discovered it alone."

That conclusion reverses a common narrative about AI in security research. As first reported by CSO Online, Kettle argues the better framing is not "autonomous versus human" but rather a deliberate mix of AI, human judgement, and deterministic code (software that follows fixed rules and produces the same output every time, without guessing).

"A human in the loop can still add significant value," he wrote, "as opposed to just building the loop, then stepping back."

Kettle has released HTTP Terminator and his full research blueprint publicly. Security teams wanting to follow the method should, he says, set a clear objective, build an evaluation strategy before writing a single line of AI code, and treat every data-quality problem as urgent. "Any issues there will derail the entire project," he warned.

Should ordinary people be worried?

The 700 sites HTTP Terminator flagged were contacted through responsible disclosure channels, not exploited maliciously. Still, request smuggling flaws of this kind can expose the private data of any customer who uses an affected website, including account details and session tokens (the digital passes that keep you logged in).

If you bank or interact with government services online, the practical steps are the same ones that apply broadly: watch for unexpected password-reset emails you did not request, check bank statements regularly for unfamiliar activity, and take seriously any notification from a service saying your account may have been affected.

Common questions

Does this mean AI will replace human security researchers?

Kettle's own conclusion is no. The most significant finding, the shared-parser confusion technique, required both the AI and the human to reach. Each compensated for what the other missed.

Were any of the 700 hacked sites broken into without permission?

No. All testing used websites that had formally authorised security research through bug-bounty or Vulnerability Disclosure Programmes, where companies invite researchers to probe their systems safely.