Web-Fuzzing-Box: a payload and dictionary collection for web fuzzing

What Web-Fuzzing-Box actually is

This is a repository of text files, not a program. The README describes it as "A collection of web fuzzing dictionaries and payloads, including: brute force attacks, directory and file enumeration, web vulnerabilities". The primary language reported for the repository is HTML, which is a side effect of payload files that contain HTML fragments rather than an indication of a web application inside. There is no homepage, no release, and no package manifest, so the unit of distribution is a git clone.

The intended user is someone who already has a fuzzing or interception tool and needs input data. The README points to two write-ups by the author that use these dictionaries as real-world case studies, and it credits the CaA project as a source for some parameters, directories and filenames. If your workflow is Burp Intruder, ffuf, wfuzz, or a custom script that reads a wordlist line by line, the value here is the corpus. If you want a tool with a command line and a scan report, this repository is not that, and no amount of reading the tree will make it one.

The directory layout and what each branch covers

The README's own tree output is the best map of the project, and it is worth reading closely because the folder names encode the taxonomy. Four top-level groups carry the content: Brute, Dir, Vuln, Web, plus an Other folder.

Brute holds credential and identifier material: Application for service and application dictionaries, Basic_401_Login.txt for 401 authentication, Full_Name for name pinyin, Password, Ports, Security_Product, Subdomain, Top_Password, Test_Chinese_Mobilephonenumber.txt and Username. Dir holds discovery material split into Others, Burpsuite, Wooyun (historical vulnerability directories and files) and Yujian, a Chinese dictionary. Vuln is organised by vulnerability class: Api_Bypass, File_Upload, Logic, File_Include, Image_Dos, JWT_Attack, Jsonp, Open_Redirect, Sql_Injection, Traversal_Directory, Xml_Bomb and Xss. Web covers protocol and application surface: File_Path, Funcation_Name.txt (spelled that way in the tree), HTML, Headers, Http_Methods.txt, Integer_Overflows.txt, Javascript_Filename.txt, Lcoalhost.txt (also spelled that way in the tree), Dict, URL and ViewState_Key.txt. Other contains 2W_Words.txt and Chinese province mobile number segments.

The naming is uneven, and that matters when you script against it. Two entries contain typos in the tree output, and the folders mix English and Chinese labels. Treat the layout as documentation of intent rather than a stable interface.

Getting the files and running a first enumeration pass

There is no install step in the README, because there is nothing to build. The README gives no release archive or package name to install instead, so the way to obtain the data is to clone the repository. The default branch is main.

git clone https://github.com/gh0stkey/Web-Fuzzing-Box.git

After the clone you should see the top-level directories Brute, Dir, Other, Vuln and Web, alongside README.md and README_CN.md. The next step is to pick one file and inspect it before feeding it to a fuzzer, since line counts and encodings vary across folders. The README itself does not document how to combine the files with a tool; its case studies are the reference for how the author used them with a proxy.

A concrete first use is directory enumeration against a host you are authorised to test, taking the wordlist from the Dir folder and pointing your existing fuzzer at it. The exact flags depend on the fuzzer you already run, and the README does not supply an invocation. What the repository supplies is the file path and the entries inside it. If you want a request budget before you start, count the lines in the file you chose first, because a folder such as Dir/Wooyun can hold several lists and the README gives no sizes.

Where the collection stops short

The most concrete limitation is that the repository does not state a licence. The material reports the licence as unknown, and the README contains no licence section. For a corpus that people copy into internal tooling, that is a real gap: you cannot tell from the repository what obligations attach to redistribution, and the README does not resolve it. Anyone embedding these files in a product or a public tool should treat that as an open question rather than assume permissive terms.

The second limitation is maintenance signal without a maintenance promise. The last push was on 2026-03-23, so the repository is not dormant, but there are no releases and no changelog. A wordlist repository does not need semantic versioning to be useful, yet a user pinning a dependency has nothing to pin to except a commit hash. If a file changes, you find out by diffing.

The third is scope. These are payloads and dictionaries, not exploit logic. The Xml_Bomb and Image_Dos folders in particular describe payload categories that can damage a target or a test environment if fired blindly, and the README offers no guidance on safe handling. The repository also cannot tell you whether a payload still works against a current framework version. A JWT attack list or a SQL injection list ages with the software it targets, and nothing in the tree records when a given file was last validated.

How it compares with fuzzDicts and other wordlist projects

The obvious alternative in the related searches is fuzzDicts, another collection of fuzzing dictionaries distributed the same way, as files in a git repository. The difference is curation angle rather than mechanism. Web-Fuzzing-Box is organised around named vulnerability classes and around Chinese-language targets: the Yujian directory, the Chinese province mobile number segments, the name pinyin dictionary and the Wooyun historical directory list all point at testing Chinese web applications. A general wordlist project tends to optimise for breadth of common paths across the English-speaking web.

That means the two are not substitutes so much as different priors. If your target is a Chinese e-commerce or government-adjacent application, the Brute and Dir branches here encode assumptions that a generic SecLists-style list will miss, and the README's case studies are written against that context. If your target is a global SaaS product, the reverse holds, and the Chinese-specific material is dead weight in your request budget.

A second difference is the payload folders. Projects that ship only directory wordlists stop at discovery. Web-Fuzzing-Box also carries vulnerability-shaped payload sets, which makes it closer to a combined dictionary and payload kit. That is convenient, and it also means the repository inherits the safety problems of payload kits: some folders are not safe to run unattended.

Upgrade cost, licence and the price of adopting a data repository

Upgrade cost here is low in engineering terms and non-trivial in process terms. There is no dependency to bump and no migration to run. You pull, you diff, you decide whether the new lines change your results. The last push was on 2026-03-23, and there are no releases, so there is no version boundary to reason about. Teams that vendor the files into their own repository should record the commit hash they copied, because that is the only version identifier available.

The licence is the larger issue. The material reports the licence as unknown, and the README does not state one. That is a fact about the repository, not a legal conclusion, and it is not legal advice. What it means practically is that you cannot answer the redistribution question from the repository alone. If you plan to ship these files inside a commercial product, inside a hosted service, or inside another open source project, resolve that question before the files become load-bearing. For internal testing on systems you are authorised to test, the practical exposure is different, but the repository still does not tell you the terms.

One more cost: file sizes. The README lists a 2W_Words.txt under Other, and the tree gives no line counts for anything. Before you point a fuzzer at a folder, count the lines, because request volume against a live target is your problem and not the repository's.

Editorial conclusion

Adopt Web-Fuzzing-Box if you already run a fuzzer or an interception proxy and want ready-made wordlists for login brute force, directory and file enumeration, or payload families such as XSS, JWT attacks and XML bombs, and you are willing to read each file before use. Do not adopt it if you need a versioned, licence-clear dependency, or if you expect it to send requests for you. Before relying on it, verify the licence, since the repository does not state one, and open the specific file you plan to use, because directory names describe intent and not encoding, size or coverage.

Frequently asked questions

Official sources

1. gh0stkey/Web-Fuzzing-Box on GitHub
2. Issues
3. README