Can AI do novel security research? Meet the HTTP Terminator | PortSwigger Research
Can AI do novel security research? Meet the HTTP Terminator
James Kettle
Director of Research
@albinowax
Published: Wednesday, 5 August 2026 at 19:30 UTC
Updated: Wednesday, 12 August 2026 at 10:49 UTC
Abstract<br>We all know AI can find bugs. After a decade of research, I asked a harder question: can an autonomous system invent new attack techniques, and use them to hack live websites at scale? Building this sounded like a bad idea, so I did it.<br>It worked - I'll share an arsenal of new HTTP desync triggers, gadgets, and exploits that compromised banks, security solutions, and government infrastructure. Then I'll trace each discovery chain back through the HTTP Terminator, showing how to turn your personal expertise into an autonomous weapon - and the dark arts required to make it lethal.<br>I'll also share discoveries from beyond the autonomy horizon - some only reachable with a tight human/AI research loop, and others beyond AI's reach entirely. These include a powerful undisclosed recon technique, and anomalies that hint at new attack classes offering alternative paths to critical impact. I'll analyze the discovery process, sharing detailed experiments that probe the boundaries of what AI can and can't discover.<br>You'll leave with new exploits from desync triggers to undisclosed attack classes, and a blueprint for turning your instincts into an autonomous research cascade. And yes, I'll open-source the HTTP Terminator.<br>This whitepaper is also available as a printable PDF. If you've seen the size of the scrollbar and you're about to ask for an AI summary, you may prefer to read the executive summary instead. This research was presented at Black Hat USA 2026 and DEF CON 34, and this page will be updated with the recording once it's available - follow PortSwigger Research on X, LinkedIn or RSS to get notified when it lands.<br>Contents<br>Introduction<br>Defining novel HTTP desync research<br>HTTP Terminator Design<br>Ideation<br>The technique rediscovery test<br>Scaling ideation with micro-inspiration<br>Evaluation<br>The core evaluation primitive<br>Evaluation case-study<br>Novel desync triggers<br>Weaponization<br>Autonomous RQP<br>Turning the environment into the weapon<br>Making iteration viable<br>The stacked-response problem<br>The dangling-byte technique<br>Cascade<br>Anomaly detection cascade<br>Chasing an autonomous cascade<br>Status-line Injection<br>Range Cache Poisoning<br>Shared-Parser Confusion<br>Scanning for inspiration<br>Conclusion<br>The blueprint<br>Tool releases<br>Defense<br>Takeaways<br>Introduction<br>Automation is often focused on efficiency but I believe that when it's approached just right, automation can enable outcomes that were previously impossible. This research is about chasing that promise of something more.<br>The primary objective of this project was to discover the new frontier of automation-driven security research. I've been practicing automation-driven research for a long time, and could see that generative AI had moved the frontier substantially. I also aimed to build a blueprint to help other researchers quickly adopt this new approach.<br>My secondary objective was to push the "fully autonomous research" concept to complete failure by exceeding the capabilities of current SOTA models. By doing this, I aimed to show where a human in the loop can still add significant value (as opposed to just building the loop, then stepping back).<br>Finally, I aimed to discover factors that make a research topic unsuitable for an AI-driven approach. This would be valuable to people who prefer to stick with a classic, fully-manual research approach and want to minimize the risk of collision with an AI-enhanced researcher.<br>Defining novel HTTP desync research<br>We've all seen experts claiming AI can't do original security research. One of the many risks of my project was that people might claim that the system's discoveries weren't actually original. To minimize this risk I choose the topic I was most qualified for - HTTP Desync Attacks. I repopularized this attack class back in 2019, and in total I've done four years of research on it, resulting in four Black Hat USA & DEF CON presentations:<br>HTTP Desync Attacks: Request Smuggling Reborn<br>HTTP/2: The Sequel is Always Worse<br>Browser-Powered Desync Attacks<br>HTTP/1.1 must die! The desync endgame<br>If you're not already familiar with this attack class, I recommend checking out the research above, or our Web Security Academy topic. That said, here's a brief primer. HTTP Desync Attacks are possible when websites funnel HTTP requests over a shared HTTP/1 connection to the back-end. The weak request isolation in HTTP/1.1 means an attacker who finds a desync trigger can alter other people's requests.<br>This enables various attacks, including Response Queue Poisoning (RQP) which makes websites lose track of which response is intended for which user, meaning the attacker gets sent responses intended for other live users of the site, often including live credentials...