FuzzingTool v3.14 releases: web penetration testing tool


FuzzingTool is a web penetration testing tool, that handles with fuzzing. After the test is completed, all possible vulnerable entries (and the response data) are saved on a report file.

Changelog v3.14

New features

  • Added a replay proxy option --replay-proxy PROXY;
  • Added a Matcher option to match responses by regex -Mr REGEX;
  • Added Filter:
    • Exclude responses by status codes -Fc STATUS;
    • Exclude responses by regex -Fr REGEX;
  • Added recursion jobs feature:
    • Plugin scanners now can enqueue payloads for the next job when needed;
    • Added directory recursion feature (--recursion) on path fuzzing;
    • The user can set the maximum recursion level from jobs (--max-rlevel RLEVEL);
  • Added option to set multiple plugin scanners (when use multiple --scanner argument);
  • Added plugin scanners:
    • Backups;
    • Wappalyzer;

Removed features

  • Removed the use of multiple http methods;
  • Removed Find plugin (replaced by match by regex);


  • Fixed a bug with match logic on Matcher, when set multiple match options and only one is considered;
  • Fixed a bug with DnsZone plugin when set an invalid hostname;
  • Fixed a split string error on function split_str_to_list;

CLI output changes

  • When do a subdomain fuzzing, the ip address will no longer be shown on cli output. It’ll only be stored in the report file;
  • Added a progress bar (credits to Dirsearch for the idea)

Other changes

  • Changed the program binary name from FuzzingTool to fuzzingtool;
  • Now the Dictionary object will enqueue Payload objects into the payloads queue;
  • Each Payload has his own recursion level attribute (Payload.rlevel) to tell about the job recursion level;
  • Now the wordlist creation and build are threaded;

Code refactored

  • Added HttpHistory object to store the information about the request and response into the result object, including the ip address when do a subdomain fuzzing;
  • Moved some functions from http_utils module to UrlParse class;
  • Removed inspect_result method from scanners. Now they will append results in the _process method;
  • Removed decorator append_args, no longer needed;
  • Updated fuzz types and created a class to store the plugin categories on utils/consts;
  • Moved both logger and reports to persistence directory;
  • Updated the order of the parameters on PluginFactory methods;
  • Moved the api to outside of a specific folder;
  • Moved the argument build functions to utils/argument_utils;


$ pip install FuzzingTool


List of Execution Parameters

Argument Required Description Default
-h, --help Misc Show the help menu and exit
-v, --version Misc Show the current version and exit
-r Yes/No Define the file with the request data (including target)
--scheme No Define the scheme used in the URL http
-u Yes/No Define the target URL
--data Yes/No Define the POST data
--proxy No Define the proxy
--proxies No Define the file with a list of proxies
--cookie No Define the HTTP Cookie header value
--timeout No Define the request timeout None
-f Yes Define the wordlist file with the payloads
--prefix No Define the prefix used with payload
--suffix No Define the suffix used with payload
--upper No Set the uppercase flag for the payloads
--lower No Set the lowercase flag for the payloads
--capitalize No Set the capitalize flag for the payloads
-V, --verbose No Enable the verbose mode
--delay No Define the delay between each request 0
-t No Define the number of threads used in the tests 1
--allowed-status No Define the allowed status codes for responses to be saved on report 200
-o No Define the report format txt


Data Fuzzing

GET Request

In this example, you set the GET variable ‘id’ as an entry for the fuzzing test. The parameter values are read from the file ‘sqli.txt’.

$ ./FuzzingTool.py -u http://mydomainexample.com/post.php?id= -f /home/profile/wordlists/sqli.txt -o blind_sqli.csv

If you want to test more than one parameter, you can just do something like that on url:

POST Request

In this example, you set the POST variables ‘login’ and ‘passw’ as entries for the fuzzing test; and also sets the fixed value ‘login’ for ‘user’ variable.

$ ./FuzzingTool.py -f /home/profile/wordlists/sqli.txt -u http://mydomainexample.com/controller/user.php –data ‘login&passw&user=login’

Keep in mind: FuzzingTool will ask you for a data comparator, to be used for exclude responses based on length or time. But the app looks first for the response status code before look at these elements. So, if you are testing Blind SQLi Time-Based, make sure to allow status code 500 if the server raises internal server error responses.

URL Fuzzing

You can set the payload mode on the URL for the fuzzing test. It’s based on the variable ‘$’ position too.

Path Scanning

Example for path scanning (added suffixes to the payload):

$ ./FuzzingTool.py -f /home/profile/wordlists/paths.txt -u http://mydomainexample.com/$ –suffix .php,.html

If your file paths.txt looks like this:


Your payloads will be:


You can also make subpath scanning, see these urls:

http://mydomainexample.com/scripts/$ # <– subpath inside ‘scripts’ directory
http://mydomainexample.com/$/admin.php # <– enumerate paths


Copyright (c) 2021 Vitor Oriel