assetnote/h3fuzz

h3fuzz is worth a look if you already run ffuf against targets with HTTP/3 support and you want the same targeting, wordlists and filters at a much higher request rate. Treat the headline throughput as a research-derived target, not an independently verified benchmark.

The problem

A tester doing content discovery wants to run a large wordlist against a permitted target and come back with a usable list of paths. With HTTP/1.1, each request needs a new TCP connection, so a big list turns into connection setup overhead and a scan that crawls along at whatever concurrency the target and the local network tolerate. h3fuzz changes that step: it negotiates HTTP/3 first, falls back to HTTP/2 and then HTTP/1.1, and multiplexes many streams over each QUIC connection. The result you get back is the same kind of normalised result set, but the browser-hosted console can show a rolling rate and peak rate rather than just a finishing time.

What's different

The fork keeps ffuf's interface, so existing targets, wordlists, matchers, filters and request files mostly carry over. That matters less for the protocol than for the migration cost: you are not relearning a tool, just pointing the scanner at a new transport. Before a scan, h3fuzz can qualify a HEAD request or a Range: bytes=-1 request as a smaller response strategy, and only uses one when repeated baseline requests show the response metadata stays reliable. That is a sensible guardrail, because response minimisation can change the very status, size and timing signals that matchers rely on. The console adds persistent sessions in SQLite, protocol preflight reports and directory-tree views, which is a welcome alternative to watching terminal output scroll. The trade-off is that this is a Go implementation inspired by Tom Stacey's PortSwigger research, not a hardened scanner: it is early, and the HTTP/3-first behaviour is only useful on targets that actually speak HTTP/3. Against an HTTP/1.1-only host, you have added a preflight step and a less mature codebase for no throughput benefit. The 100,000 requests per second figure in the description refers to PortSwigger's research conditions (a laptop over Wi-Fi and a cloud host near the target), not a rate h3fuzz itself has been shown to hit in independent testing.

Who should try it

Good fit: a penetration tester who already uses ffuf, works against targets that support HTTP/3, and wants an interactive console with persistent results and a visible rate. Also reasonable: someone who owns the target and wants to measure how much load the service handles during a coordinated test. Poor fit: anyone doing a quick one-off scan against an HTTP/1.1-only app, where plain ffuf remains the simpler choice, or anyone who needs a scanner whose reliability has been independently established before using it in client work. The bundled profiles (ASP, ASP.NET, PHP, JSP, Directories) and the DirSearch-compatible -D flag are aimed at familiar directory-brute workflows, which makes migration from an existing ffuf setup short for that audience.

Requirements and limitations

You need Go 1.26 only if building from source; the prebuilt archives for Linux, macOS and Windows avoid that, and the compiled web assets mean a normal build does not need Node.js. The web console is TLS by default with a self-signed certificate and refuses a non-loopback listener unless -web-allow-remote is set; SSH tunnelling is the suggested route. Remote access and plain HTTP have explicit caveats in the README, so plan how you will reach the console before a scan rather than after. The persistent SQLite database stores result metadata, not raw response bodies, but large scans can still consume substantial space because most responses are retained, so filtering out the target's normal not-found response matters for ongoing upkeep. Responsible-use limits are the usual ones: only scan systems you own or have permission to test, and expect high rates to trigger defences or cost.

HotRepo's take

HotRepo first recorded the project on 2026-10-24, when it was 12 days old, and observed it once on the 2026-10-25 NEW-REPOSITORY board at 129 total stars, #22. That single snapshot says nothing about whether interest will persist, and there is no comparable daily-board history. Before relying on it, verify the protocol preflight behaviour against a target you control by reading the README's scan-creation and preflight reporting sections.

Project source and documentation