[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fVaSSUdxjPgiv31UNj_yIxsNPAX-g9Ks3kW9VN88EBHE":3},{"article":4,"iocs":56},{"id":5,"title":6,"slug":7,"summary":8,"ai_summary":9,"brief":10,"full_text":11,"url":12,"image_url":13,"published_at":14,"ingested_at":15,"relevance_score":16,"entities":17,"category_id":33,"category":34,"article_tags":38},"13281f5f-ce77-450c-90a8-fbc94a73be2a","http-terminator – AI-Assisted HTTP Request-Smuggling Discovery","http-terminator-ai-assisted-http-request-smuggling-discovery-f7c3c4","http-terminator is PortSwigger's AI pipeline for discovering HTTP request-smuggling bugs. Which stages run, its dependencies, and its testing limits.","PortSwigger has developed http-terminator, an AI-powered research pipeline designed to identify HTTP request-smuggling vulnerabilities by analyzing HTTP specifications. The pipeline consists of four stages: seeker, flamer, validator, and investigator, leveraging large language models like Claude to extract potential attack vectors, generate test cases, validate findings, and confirm impacts. While the initial stages are self-contained, the latter two require integration with Burp Suite and other tools.","PortSwigger releases http-terminator, an AI pipeline for discovering HTTP request-smuggling bugs.","http-terminator is a research pipeline from PortSwigger that points a large language model at HTTP specifications and asks it to find request-smuggling attacks. It was published alongside the research it produced, as a reference companion rather than a product. \u003Cimg decoding=\"async\" width=\"640\" height=\"360\" src=\"https:\u002F\u002Fwww.darknet.org.uk\u002Fwp-content\u002Fuploads\u002F2026\u002F09\u002Fhttp-terminator-ai-assisted-request-smuggling-discovery-640x360.webp\" alt=\"http-terminator — AI-ASSISTED HTTP REQUEST SMUGGLING DISCOVERY; two offset request boundaries in parallel channels; darknet.org.uk.\" class=\"wp-image-526358\" srcset=\"https:\u002F\u002Fwww.darknet.org.uk\u002Fwp-content\u002Fuploads\u002F2026\u002F09\u002Fhttp-terminator-ai-assisted-request-smuggling-discovery-640x360.webp 640w, https:\u002F\u002Fwww.darknet.org.uk\u002Fwp-content\u002Fuploads\u002F2026\u002F09\u002Fhttp-terminator-ai-assisted-request-smuggling-discovery-1024x576.webp 1024w, https:\u002F\u002Fwww.darknet.org.uk\u002Fwp-content\u002Fuploads\u002F2026\u002F09\u002Fhttp-terminator-ai-assisted-request-smuggling-discovery-1536x864.webp 1536w, https:\u002F\u002Fwww.darknet.org.uk\u002Fwp-content\u002Fuploads\u002F2026\u002F09\u002Fhttp-terminator-ai-assisted-request-smuggling-discovery.webp 1600w\" sizes=\"(max-width: 640px) 100vw, 640px\" \u002F> I read the current repository rather than the write-ups about it. What’s there is a four-stage pipeline: two stages are self-contained, and two need Burp, the last of them also a simulator the repository doesn’t ship.Advertisement At a check on 27 September, the public main branch contained one commit, 874682c, dated 22 July 2026. The ground this sits on A 2017 post here on Microsoft’s Azure web application firewall mentions request smuggling among the attacks a WAF blocks, but doesn’t explain it, so it’s worth a sentence. Request smuggling – also called desync – exploits a disagreement between two servers about where one HTTP request ends and the next begins. Put a front-end proxy in front of a back-end server and send a request the two parse differently, and the back-end can treat part of your input as the start of another request. In one variant, response poisoning, the next user’s request on that reused back-end connection completes your smuggled prefix, and that user receives the response to your request instead of their own. PortSwigger researcher James Kettle has published techniques and research on it. From specifications to test cases PortSwigger’s own HTTP Request Smuggler tests targets from Burp Suite and includes a research mode for exploring new desync techniques. http-terminator takes a document-driven approach: Claude extracts candidate vectors from specifications, which feed generation, validation and investigation stages. The four stages The pipeline runs in four stages: seeker (Python) reads documents and RFCs and, through Claude, extracts candidate desync vectors. flamer (Java) turns those vectors into malformed HTTP test-cases. validator, a Burp extension, fires the generated requests at a target and reports confirmed desync findings and unconfirmed anomalies. investigator (Python, driven by Claude Code) replicates the hits, confirms them, chases follow-on impact and writes them up. Reproducing it is where the documentation gets tangled. seeker and flamer are self-contained – Python or Java, plus an Anthropic API key. The other two are not.Advertisement The validator’s documentation needs careful reading. The root README lists commercial Burp Suite for running it, while the validator’s own README says its test suite runs under Burp Community or Professional, with the Professional-only tests skipped on Community. Those cover different things, running the stage and testing it. Where the repository does contradict itself is the build: the validator’s README says the build depends on bulkScan-all.jar and that the jar is not vendored in the repository – yet it is committed at validator\u002FbulkScan-all.jar, and the build file points at it. investigator, in turn, needs an external MCP simulator and Burp Organizer alongside Claude Code and a live target. Following the data through the stages Start in seeker\u002F, with Python 3.11 or later, an Anthropic API key and network access. The README installs the package from that directory: pip install -e \".[dev]\" 1 pip install -e \".[dev]\" That installs seeker’s command-line tool. Its next command reads a URL list you create, a text file of the document URLs to process, fetches those documents and stores the extracted sections in seeker.db. The repository ships a sample list at seeker\u002Ffixtures\u002Furls.txt you can point at instead to try it: seeker process --input urls.txt --db seeker.db --manifest run.manifest.json --verbose 1 seeker process --input urls.txt --db seeker.db --manifest run.manifest.json --verbose The manifest records that run, while the SQLite database holds the sections you can inspect with seeker’s query command: seeker query --db seeker.db --type http_desync_vector 1 seeker query --db seeker.db --type http_desync_vector That selects the extracted desync-vector sections; once flamer has generated requests, seeker can trace a request ID back to its source: python3 -m seeker.cli trace 1002368 --db seeker.db --flamer-db ..\u002Fflamer\u002Fproduction.db 1 python3 -m seeker.cli trace 1002368 --db seeker.db --flamer-db ..\u002Fflamer\u002Fproduction.db Replace 1002368, the README’s example, with a request ID from your own flamer database; the trace links a generated request to the seeker section it came from. Next, from flamer\u002F, with Java 21, Gradle and an Anthropic API key, the default run reads unprocessed sections from ..\u002Fseeker\u002Fseeker.db and writes generated requests to its own production.db: export ANTHROPIC_API_KEY=your_key .\u002Fgradlew run 12 export ANTHROPIC_API_KEY=your_key.\u002Fgradlew run The key is required for Claude; flamer’s README also offers a run that does not save generated requests: .\u002Fgradlew run --args=\"--dry-run\" 1 .\u002Fgradlew run --args=\"--dry-run\" Use the documented dump option to view requests already held in flamer’s database: .\u002Fgradlew run --args=\"--dump\" 1 .\u002Fgradlew run --args=\"--dump\" Flamer’s Gradle task copies its generated database into the validator directory: .\u002Fgradlew copyDbToValidator 1 .\u002Fgradlew copyDbToValidator From validator\u002F, the README builds the Burp extension jar with: .\u002Fgradlew jar 1 .\u002Fgradlew jar The documented output is build\u002Flibs\u002Fvalidator.jar; load it in Burp via Extensions > Installed > Add and select that file. That manual extension-loading step is separate from the validator’s livetesting suite, which can use Burp Community or Professional: Community skips the Professional-only tests, while Professional runs them. The root README’s commercial-Burp requirement describes running the validation stage, not this test suite. There is no investigator command to copy from its README. It calls for Claude Code with an Anthropic API key, an external simulator exposing turbo-simulator MCP tools, Burp Suite and a Burp Organizer-style findings source, plus a target you are authorised to test; those external pieces are not supplied with the repository. seeker fetches the documents you list and calls Claude; flamer calls Claude and keeps its database local unless you opt into its upload flag. The generated requests are not sent to a target by those two stages. Validation is the point where Burp and target authorisation become necessary. What it’s worth if you can’t run all of it What the repository exposes is the design. The tree holds the prompts seeker uses to pull candidate vectors from a specification and the code flamer uses to turn those vectors into test cases. PentestGPT now runs a testing pipeline itself, driven by Claude Code or Codex; http-terminator instead points a model at one class of bug, starting from specifications. Read that way, the repository is a worked, inspectable design for pointing a language model at a specification to generate desync test cases. Reading it is not the same as confirming it works. That would need running the pipeline against authorised targets, which this article did not do, so nothing here measures how","https:\u002F\u002Fwww.darknet.org.uk\u002F2026\u002F09\u002Fhttp-terminator-ai-request-smuggling-discovery\u002F","https:\u002F\u002Fwww.darknet.org.uk\u002Fwp-content\u002Fuploads\u002F2026\u002F09\u002Fhttp-terminator-ai-assisted-request-smuggling-discovery.webp","2026-09-28T07:09:26+00:00","2026-09-28T08:00:23.69536+00:00",7,[18,21,24,26,29,31],{"name":19,"type":20},"http-terminator","product",{"name":22,"type":23},"PortSwigger","vendor",{"name":25,"type":20},"Burp Suite",{"name":27,"type":28},"AI","technology",{"name":30,"type":28},"LLM",{"name":32,"type":20},"Claude","02371804-cf6d-4449-98de-f1a2d4d9b266",{"id":33,"icon":35,"name":36,"slug":37},null,"Tools","tools",[39,41,46,51],{"category":40},{"id":33,"icon":35,"name":36,"slug":37},{"category":42},{"id":43,"icon":35,"name":44,"slug":45},"80544778-fabb-4dcd-aa35-17492e5dcf4f","Vulnerabilities","vulnerabilities",{"category":47},{"id":48,"icon":35,"name":49,"slug":50},"839da5c1-3c34-47e2-9499-f7201640e3ac","AI Security","ai-security",{"category":52},{"id":53,"icon":35,"name":54,"slug":55},"e7b231c8-5f79-4465-8d38-1ef13aea5a14","Threat Intelligence","threat-intelligence",[]]