http-terminator for AI-assisted HTTP request-smuggling research pipelines

http-terminator is a PortSwigger research companion that chains AI-driven stages to extract, generate, validate and confirm HTTP desync vulnerabilities in authorized testing environments.

Tool	PortSwigger/http-terminator — an AI-assisted research pipeline for HTTP request-smuggling and response-desynchronisation research
Category	Web application security research / LLM-assisted vulnerability pipeline
Primary Use	Automating the research loop of extracting desync techniques from RFCs, generating malformed HTTP test-cases, validating them via Burp Suite, and confirming findings on systems you own
Safe Use	Explicitly intended for systems the operator owns or is explicitly authorized to test, per the repository's own ethics section; suited to lab environments, authorized penetration tests and defensive research into reverse-proxy behavior
Telemetry Note	Each stage persists state locally in SQLite databases (seeker.db, production.db, model_outputs.db, investigations.db) that are regenerated on run; validation traffic passes through Burp Suite, so defenders observing a test will see malformed request sequences in proxy and origin logs

http-terminator is not a single scanning tool but a coordinated research pipeline, published by PortSwigger as a reference companion to their HTTP desynchronization research. At roughly 120 stars on GitHub and licensed under AGPL-3.0, it is a hybrid Python and Java/Gradle codebase that attempts to industrialize a workflow normally done by hand: reading RFCs and documentation for parsing quirks, hand-crafting malformed requests, testing them against a proxy chain, and then confirming whether a genuine desynchronization exists. The repository is candid about its own maturity — some stages are self-contained and runnable, while others depend on external commercial tooling and are flagged as such. That honesty alone distinguishes it from the average smuggling scanner.

The architecture is expressed as a four-stage chain: seeker → flamer → validator → investigator. seeker is the Python front end, and its job is knowledge extraction: it feeds documentation and RFCs to Claude and harvests candidate desynchronization techniques from them. This is a genuinely interesting inversion of the usual approach — instead of hardcoding a list of known CL.TE or TE.CL style vectors, the pipeline tries to derive new ones from primary sources, meaning the technique list is not frozen at release time. The stage requires Python 3.11+ and an ANTHROPIC_API_KEY, and it is marked self-contained in the runnability matrix.

flamer takes the output of seeker and turns abstract techniques into concrete malformed HTTP test-cases. It is written in Java on Gradle, requires Java 21, and also consumes an ANTHROPIC_API_KEY. Conceptually this is the generative grammar stage: the LLM is used to translate a described parsing discrepancy into an actual byte-level request shape that could trigger divergent interpretations between a front-end proxy and a back-end server. The separation between technique extraction and test-case generation is deliberate — it lets researchers audit what was extracted before anything is fired at a target, which matters for both safety and scientific reproducibility.

validator is where the pipeline touches real infrastructure, and it is deliberately built as a Burp Suite extension rather than a standalone client. Written in Java 21 with Gradle, it depends on commercial Burp Suite and the bulkScan machinery documented in its own README, and it replays the generated requests against a designated target to look for observable signs of desynchronization. Routing validation through Burp is a pragmatic choice: the operator gets the full proxy visibility, matching, and extension ecosystem around every probe, and every request the pipeline sends is inspectable in a tool most web testers already trust.

The final stage, investigator, is the most experimental and the least self-contained. It is a Python component designed to run under Claude Code and requires an external MCP simulator plus Burp Organizer, along with a target to test. Its role is post-detection work: replicate a candidate finding, confirm it is not a false positive, cascade it into follow-on impact analysis, and produce a report. The README's runnability table flags it with a warning — it needs external pieces — and researchers evaluating this repo should read that as an accurate assessment rather than false modesty. The investigator stage is where agentic LLM operation meets live testing, which is exactly why the authorization boundary matters most here.

Data handling is cleanly documented. Each stage maintains its own SQLite database — seeker.db for extracted techniques, production.db and model_outputs.db for flamer's generations, and investigations.db for investigator — and none of these ship with the repository. They are gitignored and regenerated by running each stage, which means the repo contains no real target data and every deployment builds its own corpus from scratch. For a research artifact intended for public release, that design choice neatly sidesteps shipping anything that resembles operational targeting data.

The ethics section is short but unambiguous: these tools find and exploit real vulnerabilities, and they should only be run against systems you own or are explicitly authorized to test. This is the right framing for the material. HTTP request smuggling is a class of bug whose impact — cache poisoning, auth bypass, queue poisoning on shared infrastructure — scales badly when pointed at systems without permission, and the pipeline's automation makes volume-based mistakes easy. Anyone pulling this repo should treat the authorization statement as a hard precondition, not boilerplate, and should note that the validator stage in particular will send deliberately malformed traffic to whatever target it is pointed at.

From a defensive perspective, http-terminator is worth studying even if you never run it. It is effectively a documented adversary model for desynchronization research: the seeker stage tells you which parsing ambiguities in RFC language an automated adversary can mine, and flamer tells you what shapes of malformed requests will result. Blue teams can use that intelligence to harden proxy configurations, normalize header and body-length handling between tiers, and build detection rules for the anomalous request patterns the validator stage produces. The SQLite artifacts each stage leaves on the researcher's machine also double as an audit trail of what was tested and when.

Getting started is conventional: clone the repository and read the per-stage READMEs, which the top-level documentation says contain setup and commands for each component. Prerequisites are Python 3.11+ for the Python stages, Java 21 plus Gradle for the Java ones, a valid ANTHROPIC_API_KEY for seeker and flamer, and commercial Burp Suite plus bulkScan for validator. The most sensible evaluation path is to run the first two stages offline against local documentation — they need no target at all — and only wire in validator once you have a lab proxy chain to point it at.

As a piece of research infrastructure, http-terminator is a signal of where vulnerability research tooling is heading: LLMs applied at the knowledge-extraction and test-generation layers, with traditional deterministic tooling — Burp, Gradle, SQLite — holding the operational layers where reproducibility matters. The staged design keeps the agentic components sandboxed behind clear interfaces, and the runnability matrix is a template other research repos should copy. For authorized testers and desync researchers, it is a reference implementation worth reading in full; for defenders, it is a preview of the automated, documentation-mining adversary that proxy hardening programs should already be planning against.

Official project repository for PortSwigger/http-terminator.

Download Tool

Educational analysis for authorized security professionals. Use only in controlled, authorized environments.