Gobuster: Brute-Forcing Directories, DNS and Virtual Hosts in Go

What Gobuster actually enumerates

Gobuster sends a large number of guessed names at a target and reports which ones come back with a meaningful answer. The README describes it as "a fast and flexible brute-forcing tool written in Go" and lists the tasks it covers: web directory and file enumeration, DNS subdomain discovery, virtual host detection, Amazon S3 and Google Cloud Storage bucket discovery, TFTP file discovery, and custom fuzzing. Each of those is a separate mode, not a flag on one scanner.

The audience is narrow and specific. This is a penetration testing and security assessment tool. The repository topics are dns, go, pentesting, tool and web, and the README frames the whole project around security professionals and penetration testers. If you are not authorised to probe the target, the tool is irrelevant to you, because every mode works by making requests the operator is not supposed to make without permission.

The practical value is that one binary replaces several small scripts. Directory enumeration, subdomain guessing and virtual host discovery are usually three different utilities with three different output formats. Here they share a wordlist convention and a similar command shape, which matters when you are scripting a run and parsing the results.

How the mode-based architecture is laid out

The repository layout mirrors the modes. Top-level entries include gobusterdir/, gobusterdns/, gobusterfuzz/, gobustergcs/, gobusters3/, gobustertftp/, gobustervhost/, plus cli/, libgobuster/ and main.go. That structure tells you the design: shared plumbing sits in libgobuster, each mode is its own package, and cli wires the commands together. The dependency list in go.mod is short and unsurprising, with urfave/cli/v2 for command parsing, pin/tftp/v3 for the TFTP mode, fatih/color for terminal output, and automaxprocs for container CPU detection. Nothing here is exotic, which is a good sign for a tool you might need to build yourself.

The data flow is the same in every mode. A wordlist is read line by line, each line is combined with the target according to the mode (a URL path, a subdomain label, a Host header, a bucket name), the request goes out, and the response is classified. In dir mode the classification is largely the HTTP status code, which is why the README shows filtering with -s 200,301,302 and length output with -l. In dns mode the classification is whether the name resolves. In vhost mode it is whether the server returns a different response for a different Host header.

Concurrency is a first-class setting rather than something hidden. The README advertises "multi-threaded scanning with configurable concurrency" and shows -t 50 in a DNS example. That is the main performance lever, and it is also the main way to get yourself rate-limited or blocked.

Installing Gobuster and running a first scan

The README calls the Go install the recommended path. It requires Go 1.24 or higher according to the installation section, while go.mod declares go 1.25, so build with a recent toolchain and check with go version if the install fails.

go install github.com/OJ/gobuster/v3@latest

That places the binary in $GOPATH/bin. The README's troubleshooting section says to check your $GOPATH and $GOBIN variables and to verify that $GOPATH/bin is in your $PATH. Pre-compiled binaries are also published on the releases page, and there is a container image at ghcr.io/oj/gobuster:latest.

docker run --rm -it ghcr.io/oj/gobuster:latest dir -u https://example.com -w /usr/share/wordlists/dirb/common.txt

Note the wordlist path inside the container. The image is built on Alpine, runs as a non-root gobuster user with /app as the working directory, and does not ship a wordlist, so you have to mount one or accept the default path shown in the README example.

A first real run against a host you are authorised to test looks like this. The -x flag appends file extensions to each wordlist entry, and -s restricts output to the status codes you care about.

gobuster dir -u https://example.com -w wordlist.txt -x php,html,js,txt -s 200,301,302

Expect a line per hit showing the path, the status code and the response size. If the output is a wall of 404s, your filter is wrong. The same pattern holds for the other modes: dns takes -do for the domain, vhost takes -u plus --append-domain, and fuzz replaces the literal FUZZ keyword in a URL, header or POST body.

gobuster fuzz -u https://example.com?param=FUZZ -w wordlist.txt

Where Gobuster gets in your way

The wordlist is entirely your problem. The README references paths like /usr/share/wordlists/dirb/common.txt and /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt, which belong to other packages, not to Gobuster. A fresh install gives you a scanner with nothing to scan with. That is a deliberate choice, and a reasonable one, but it means the tool's usefulness is bounded by a file you have to source yourself.

Recursive scanning is not a headline feature. The README's directory mode section documents extensions, headers, cookies, length output and status filtering, and the common use cases show extension lists and status filters, but recursion is not among the documented flags. If your goal is to walk a tree of discovered directories automatically, verify the current flag set with gobuster help dir before assuming it behaves like a crawler.

False positives are inherent to the method. A wildcard DNS record or a catch-all virtual host will answer every guess, and the README mentions wildcard support for DNS subdomain discovery without explaining how it is detected or suppressed. Treat any run that returns an implausible number of hits as a configuration problem first.

Finally, the tool is loud. Fifty threads against a production host is a denial-of-service attempt in all but name, and the README offers no rate limiting guidance beyond the thread count. The absence of built-in throttling is a real constraint on where this is safe to point.

Gobuster against ffuf and DirBuster

The two comparisons people actually search for are Gobuster versus ffuf and Gobuster versus DirBuster, and they are different questions.

DirBuster is the older Java tool with a graphical interface. Gobuster is a command-line Go binary. The difference is not just language: DirBuster's model is a GUI session where you pick a target, a list and a thread count, while Gobuster is built to be scripted and piped. If you want to click through a scan, Gobuster is the wrong shape for you.

ffuf is the closer comparison, and the split is philosophical. Gobuster gives you named modes with a fixed set of options per mode. ffuf is built around a single FUZZ keyword that you place anywhere in a request, which makes it more flexible for unusual injection points and less predictable for standard enumeration. Gobuster does have a fuzz mode with the same FUZZ keyword convention, so the gap is narrower than it looks. The practical difference is that Gobuster's dir, dns and vhost modes encode the common cases with dedicated flags, while ffuf makes you assemble them. If your work is mostly standard directory and subdomain enumeration, Gobuster's opinionated modes save typing. If your work is mostly one-off request shapes, the extra structure gets in the way.

Licence, releases and what maintenance costs you

Gobuster is Apache-2.0. That is a permissive licence, and for a command-line tool you run rather than link against, the practical obligation is attribution if you redistribute it. The README also points to Open Collective for backers and sponsors and states that donated funds are passed to charity, which is unusual but has no bearing on your rights under the licence. This is not legal advice; read the LICENSE file if you plan to ship the binary inside a product.

The release cadence in the repository shows v3.8.0 in July 2025, v3.8.1 in August 2025 and v3.8.2 in September 2025, and the last push to the repository was on 2026-09-09. The module path is versioned as /v3, so major upgrades arrive as a new import path rather than in place. Upgrading a Go install is a single command, and there is no database, no server component and no configuration file to migrate, which keeps the upgrade cost close to zero.

The real maintenance burden is elsewhere. Wordlists age, extension lists age, and the request patterns that reveal useful paths change as applications change. A Gobuster install that is a year old still works; the wordlist next to it is what goes stale.

Editorial conclusion

Adopt Gobuster if you already work from a terminal, have a wordlist you trust, and want one binary that covers directory, DNS, vhost, S3, GCS, TFTP and fuzz enumeration. Do not adopt it if you need a graphical interface, a built-in wordlist, or a recursive crawl that follows every discovered path without extra flags. Before running it against anything, verify that you have written authorisation for the target, check your Go version against the go.mod requirement of Go 1.25, and confirm that your wordlist and extension list are the ones you actually intend to send.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. OJ/gobuster on GitHub
4. README
5. Releases