feroxbuster: a recursive content discovery tool written in Rust

One attack, described in the project's own words

feroxbuster describes itself as a tool built to perform forced browsing. Forced browsing is an attack where the goal is to enumerate and reach resources that the web application never links to but that remain reachable anyway. The project ties the technique to predictable resource location, file enumeration, directory enumeration and resource enumeration, and it credits OWASP for the term. The mechanism underneath those names is straightforward: take a wordlist, request candidate paths under a target directory, and recurse into anything that answers with a directory.

The repository description line calls it a fast, simple, recursive content discovery tool written in Rust, and the repository metadata agrees. It is a single command line binary, released under the MIT license, tagged with topics like content-discovery, enumeration, url-bruteforce, pentest and pentesting-tool. There is no daemon, no configuration service and no client protocol to learn. You point it at a URL, and it walks.

The name is the project's own small joke, explained in the README under the heading about what a ferox is. Ferox is short for ferric oxide, and ferric oxide is simply rust. The author wanted a variation on rustbuster and found that name already taken. That is the entire origin story, and it tells you something about the project's tone: this is a tool built by someone who enjoys the work and is direct about it. The repository carries a Hacktoberfest topic, an animated demo GIF, and a contributor count in the dozens, all consistent with a long lived solo-maintained project rather than a committee effort.

Install paths that install more than the binary

The README lists installation methods grouped by platform, and the differences between them matter more than the command itself. On Kali and other Debian-family systems the project prefers the distribution repositories, because installing from apt brings along a ferox-config.toml file in /etc/feroxbuster/, shell completion for bash, fish and zsh, and a man page entry alongside the binary itself.

sudo apt update && sudo apt install -y feroxbuster

The Homebrew path is the shortest one, and on macOS it is the one most people will run first.

brew install feroxbuster

Windows gets three separate routes, because the tool is distributed as a standalone zip as well as through the two major Windows package managers. The two package manager routes are single lines each, one through Winget and one through Chocolatey.

winget install epi052.feroxbuster
choco install feroxbuster

The nix install script accepts an optional destination argument, so you can drop the binary into a directory on your PATH or leave it in the current working directory. Running the script with no argument puts it in the working directory, which is convenient for a throwaway engagement and a bad idea for anything you intend to keep.

Updates have their own switch, described in the README as new in v2.9.1, and it works against the local binary rather than a package manager, so it is the right choice for the zip and script installs and the wrong one for an apt-managed system.

./feroxbuster --update

What the Cargo manifest says about the engine

The manifest is the most honest description of how the tool behaves, because it lists every library the request path depends on. The crate declares Rust edition 2021, a command-line-utilities category, and keywords that match the topics on the repository page. Its build dependencies pull in clap with the wrap_help feature, which is where the help output formatting comes from, plus clap_complete for shell completion generation and dirs for locating configuration directories.

Two runtime entries stand out for behaviour rather than plumbing. One is leaky-bucket, a rate limiting crate. The other is gaoya, a terminal rendering library that handles the live progress display during a scan. Together they explain why the tool paces its requests and repaints a progress bar while it works.

tokio = { version = "1.47", features = ["full"] }
reqwest = { version = "0.12", features = ["socks", "native-tls-alpn"] }

Two more entries explain the interactive feel. crossterm is a cross platform terminal control library, used for colour and cursor handling, and rlimit plus ctrlc handle signal handling and process limits. When a scan is running and you want to stop it, the behaviour you are relying on comes from those two crates rather than from application logic you can read in the README.

A maintainer status field in the manifest is set to actively-developed, which matches the repository metadata showing a push in early September 2026 and a release, v2.13.1, published in December 2025.

Directory listings, ignored extensions and rate limiting

The v2.13.1 release notes are worth reading because they describe two behaviours that change results rather than just internal cleanup. The release fixed several rate limiting bugs and, in the same pull request, added new heuristics for identifying directory listings. It also added web fonts to the list of ignored extensions, contributed by a first-time contributor.

Each of those touches a decision the tool makes about what counts as a finding. Rate limiting bugs change how fast requests go out and therefore how a target perceives the scan. Directory listing heuristics change whether a response is classified as a listing worth showing or a page worth recursing into. The ignored extension list changes what appears in output at all, and web fonts are exactly the kind of asset that floods a results table with entries nobody wants.

The presence of both rate limiting crates, leaky-bucket and rlimit, alongside the fixed bugs in that release, says the project treats request pacing as a first class feature rather than an afterthought. For an engagement where the target is rate limited or monitored, that pacing is the difference between a scan that finishes and a scan that gets you blocked. The same release added Android and Termux install instructions to the documentation, which suggests the project keeps extending its own platform coverage.

The container ships a wordlist with the binary

The Dockerfile is small enough to read in one pass, and it answers a question the README leaves open: where does a containerised run get its default wordlist. The build stage starts from Alpine, upgrades the package cache, installs OpenSSL, then downloads the latest release zip, extracts only the feroxbuster binary from it, and separately fetches a single wordlist file from SecLists into the build stage.

COPY --from=build /tmp/raft-medium-directories.txt /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt
COPY --from=build /tmp/feroxbuster /usr/local/bin/feroxbuster
ENTRYPOINT ["feroxbuster"]

The release stage copies both artifacts into place and then drops root privileges, which is the part that matters if you run this in CI or in a shared lab environment. The image ships exactly one wordlist, which is a sensible default and also a narrow one; a deliberate enumeration run will want its own list mounted in.

Read that Dockerfile as the reference configuration for what a container invocation looks like. The entrypoint is the bare binary name, so arguments pass straight through with no wrapper, and the unprivileged user means any file you mount for output has to be writable by that user rather than by your own account.

The documentation deliberately left the README

The README opens with a tip explaining that documentation has moved. Instead of a 1300 line README, the project hosts its documentation on GitHub Pages, with the overview at the documentation site and installation pages split by platform, including a dedicated Android and Termux page. The example usage material lives there too, with demonstration GIFs for individual features rather than a single combined list.

That split has a practical consequence for anyone reading the source. The README now carries project identity, the attack description, install routes and update instructions, and delegates everything about flags, configuration and worked examples to the documentation site. The ferox-config.toml file mentioned in the apt section is documented there too, including the example configuration file shipped at the root of the repository as ferox-config.toml.example.

There is also a commercial edition at feroxbuster.pro, which the README lists as an official download source alongside the GitHub releases. The README carries a security notice about domain impersonation: the domain feroxbuster.com is not affiliated with the project or its maintainers, the project cannot vouch for files hosted there, and anyone who downloaded from it is advised to delete the files and reinstall from an official source. The official channels named are the GitHub releases page, the commercial site, and the package repositories listed in the README and the installation documentation.

Editorial conclusion

The next concrete step for an installation that already works is to read the entrypoint in the repository Dockerfile rather than the install guide: it pins the exact SecLists file the image ships and puts the binary at /usr/local/bin/feroxbuster, which tells you the wordlist path your container will use before you ever point the tool at a target.

Frequently asked questions

Official sources

1. epi052/feroxbuster on GitHub
2. License: MIT
3. Project website
4. README
5. Releases