WAPITI(1)

📦
version 3.2.10 · 2 versions
, in ubuntu resolute

💅 WAPITI(1) — the manual page, bestie edition

okay so you opened the manual for wapiti (that's a General Commands Manual situation, section 1, we love a section 1) and honestly? you're about to have a great time. it's a web application vulnerability scanner written in Python, and it's lowkey iconic. let's get into it 🦋

✨ NAME ✨

wapiti — a web application vulnerability scanner in Python 💖

🌸 SYNOPSIS 🌸

wapiti -u BASE_URL [options]

that's it. that's the whole vibe. give it a base URL, sprinkle some options, go 🎀

🫶 DESCRIPTION 🫶

so, Wapiti lets you audit the security of your web applications. periodt.

it does "black-box" scans — meaning it does not go read your source code, bestie, no. it just scans the webpages of the deployed webapp, out there in the wild, looking for scripts and forms where it can inject data. main character energy, honestly.

once it gets that list, Wapiti acts like a fuzzer — it injects payloads and sees if a script is vulnerable. 💅

important!! Wapiti is useful only to discover vulnerabilities. it is not an exploitation tool, ok? it finds the door, it doesn't walk through it.

and for the exploitation part? some well known applications can be used — like the recommended sqlmap. Wapiti finds it, sqlmap does the rest. dynamic duo 🫶

🌈 OPTIONS SUMMARY 🌈

here's the whole menu. it is essentially what you will get when you launch Wapiti without any argument. more detail on each option can be found in the following sections. no skipping, we're doing all of them 🧚

🎯 TARGET SPECIFICATION

  • -u, --url URL
  • --data URL_ENCODED_DATA
  • --scope {url,page,folder,subdomain,domain,punk}

⚔️ ATTACK SPECIFICATION

  • -m MODULES_LIST
  • --list-modules
  • -l, --level LEVEL
  • --cms {drupal,joomla,prestashop,spip,wp}

🕵️ PROXY AND AUTHENTICATION OPTIONS

  • -p, --proxy PROXY_URL
  • --tor
  • --mitm-port PORT
  • -a, --auth-cred CREDENTIALS
  • --auth-user USERNAME
  • --auth-password PASSWORD
  • --auth-method {basic,digest,ntlm}
  • --form-cred CREDENTIALS
  • --form-user USERNAME
  • --form-password PASSWORD
  • --form-url URL
  • --form-data DATA
  • --form-enctype ENCTYPE
  • --form-script FILENAME
  • -sf, --side-file FILENAME
  • -c, --cookie COOKIE_FILE_OR_BROWSER_NAME
  • -C, --cookie-value COOKIE_VALUE
  • --drop-set-cookie

💾 SESSION OPTIONS

  • --skip-crawl
  • --resume-crawl
  • --flush-attacks
  • --flush-session
  • --store-session PATH
  • --store-config PATH

🕸️ CRAWLING

  • -s, --start URL
  • -x, --exclude URL
  • -r, --remove PARAMETER
  • --skip PARAMETER
  • -d, --depth DEPTH
  • --max-links-per-page MAX_LINKS_PER_PAGE
  • --max-files-per-dir MAX_FILES_PER_DIR
  • --max-scan-time MAX_SCAN_TIME
  • --max-attack-time MAX_ATTACK_TIME
  • --max-parameters MAX
  • --swagger URL
  • --headless {no,hidden,visible}
  • --wait TIME

🚀 PERFORMANCE

  • -S, --scan-force {paranoid,sneaky,polite,normal,aggressive,insane}
  • --tasks TASKS

📡 ENDPOINT OPTIONS

  • --external-endpoint EXTERNAL_ENDPOINT_URL
  • --internal-endpoint INTERNAL_ENDPOINT_URL
  • --endpoint ENDPOINT_URL
  • --dns-endpoint DNS_ENDPOINT_DOMAIN

🌐 HTTP AND NETWORK OPTIONS

  • -t, --timeout SECONDS
  • -H, --header HEADER
  • -A, --user-agent AGENT
  • --verify-ssl {0,1}

📝 OUTPUT OPTIONS

  • --color
  • -v, --verbose LEVEL
  • --log OUTPUT_PATH

📊 REPORT OPTIONS

  • -f, --format {json,html,txt,xml}
  • -o, --output OUTPUT_PATH
  • -dr, --detailed-report LEVEL

🎀 OTHER OPTIONS

  • --no-bugreport
  • --version
  • --update [--wapp-url WAPP_DB_URL, --wapp-dir WAPP_DB_PATH]
  • -h

🎯 TARGET SPECIFICATION 🎯

  • -u, --url URL — the URL that will be used as the base for the scan. every URL found during the scan will be checked against the base URL and the corresponding scan scope (see --scope for details, bestie).

this is the only required argument ✨. and heads up: the scheme part of the URL must be either http or https. no funny business.

  • --data URL_ENCODED_DATA — if you need to attack only a specific POST request, you can hand this option a url-encoded string. it will be used as POST parameters for the URL specified by the -u option. cute, specific, targeted 💅
  • --scope SCOPE — this defines the scope of the scan and the attacks. valid choices are:
    • url : will only scan and attack the exact base URL given with -u option.
    • page : will attack every URL matching the path of the base URL (every query string variation).
    • folder : will scan and attack every URL starting with the base URL value. this base URL should have a trailing slash (no filename).
    • domain : will scan and attack every URL whose domain name match the one from the base URL.
    • punk : will scan and attack every URL found whatever the domain. think twice before using that scope. like, genuinely think twice. 😭

⚔️ ATTACKS SPECIFICATION ⚔️

  • -m, --module MODULE_LIST — set the list of attack modules (modules names separated with commas) to launch against the target.

default behavior (when the option is not set) is to use the most common modules.

common modules can also be specified using the "common" keyword.

if you want to use common modules along with XXE module you can pass -m common,xxe.

activating all modules can be done with the "all" keyword (not recommended though — we said what we said 🙈).

to launch a scan without launching any attack, just give an empty value (-m "").

you can filter on http methods too (only get or post). for example -m "xss:get,exec:post". iykyk 🔥

  • --list-modules — print the list of available Wapiti modules along with a short description then exit. a little menu, a little peek, then bye 👋
  • -l, --level LEVEL — so in previous versions Wapiti used to inject attack payloads in query strings even if no parameter was present in the original URL. while it may be successful in finding vulnerabilities that way, it was causing too many requests for not enough success. 😮‍💨

this behavior is now hidden behind this option and can be reactivated by setting -l to 2.

it may be useful on CGIs when developers have to parse the query-string themselves.

default value for this option is 1.

  • --cms CMS_LIST — this option can only be used when the module cms is selected.

it allows one to specify the CMS to scan from the list {drupal,joomla,prestashop,spip,wp}.

multiple choices are allowed, all the CMS will be scanned if this option is not set. slay 🎀

🕵️ PROXY AND AUTHENTICATION 🕵️

  • -p, --proxy PROXY_URL — the given URL will be used as a proxy for HTTP and HTTPS requests. this URL can have one of the following scheme: http, https, socks.
  • --tor — make Wapiti use a Tor listener (same as --proxy socks://127.0.0.1:9050/) 🧅✨
  • --mitm-port PORT — if used, this option will launch a mitmproxy instance listening on the given port instead of using an automated crawler to explore the target.

configure your browser to use the intercepting proxy then explore the target manually. Ctrl+C in the console when you are done. you're the crawler now, bestie 💅

  • -a, --auth-cred CREDENTIALS — (DEPRECATED) set credentials to use for HTTP authentication on the target (see available methods bellow).

given value should be in the form login%password (% is used as a separator).

  • --auth-user USERNAME — set username to use for HTTP authentication on the target (see available methods bellow).
  • --auth-password PASSWORD — set password to use for HTTP authentication on the target (see available methods bellow).
  • --auth-method TYPE — set the authentication mechanism to use. valid choices are basic, digest and ntlm.

NTLM authentication may require you to install an additional Python module. just a lil heads up 🫶

  • --form-cred CREDENTIALS — (DEPRECATED) set credentials to use for web form authentication on the target.

given value should be in the form login%password (% is used as a separator).

  • --form-user USERNAME — set username to use for web form authentication on the target.
  • --form-password PASSWORD — set password to use for web form authentication on the target.
  • --form-url URL — if --form-data is not set, Wapiti will extract the login form at the given URL and fill it with the provided credentials.

otherwise raw credentials are sent directly to the given URL.

  • --form-data DATA — raw body to send to the form URL specified with --form-url.
  • --form-enctype ENCTYPE — send data specified with --form-data using the given content-type (default is "application/x-www-form-urlencoded").
  • --form-script FILENAME — use a custom Python authentication plugin 🐍
  • -sf, --side-file FILENAME — use a .side file generated using Selenium IDE to perform an authenticated scan.
  • -c, --cookie COOKIE_FILE_OR_BROWSER_NAME — load cookies from a Wapiti JSON cookie file. see wapiti-getcookie(1) for more information.

you can also import cookies from your browser by passing "chrome" or "firefox" as value (MS Edge is not supported 🙈).

  • -C, --cookie-value COOKIE_VALUE — set cookies from a valid user cookies.

you can import all the session cookies by copying the value of the cookies sent with headers from a request sent by an authenticated user.

for example:

--cookie-value "PHPSESSIONID=5f4dcc3b5aa765d61d8327deb882cf99;cookie_2=somevalue"
  • --drop-set-cookie — ignore cookies given in HTTP responses. cookies that have been loaded using -c will be kept. so it's giving "i don't want your new cookies, i'm loyal to the ones i already have" 🍪

💾 SESSIONS 💾

so since Wapiti 3.0.0, scanned URLs, discovered vulnerabilities and attacks status are stored in sqlite3 databases used as Wapiti session files.

default behavior when a previous scan session exists for the given base URL and scope is to resume the scan and attack status. it remembers. it's an elephant, basically 🐘

following options allows you to bypass this behavior:

  • --skip-crawl — if a previous scan was performed but wasn't finished, don't resume the scan.

attack will be made on currently known URLs without scanning more.

  • --resume-crawl — if the crawl was previously stopped and attacks started, default behavior is to skip crawling if the session is restored.

use this option in order to continue the scan process while keeping vulnerabilities and attacks in the session.

  • --flush-attacks — forget everything about discovered vulnerabilities and which URL was attacked by which module.

only the scan (crawling) information will be kept. selective memory, we respect it 💅

  • --flush-session — forget everything about the target for the given scope. full amnesia era.
  • --store-session PATH — specify an alternative path for storing session (.db and .pkl) files.
  • --store-config PATH — specify an alternative path for storing particular module (apps.json and nikto_db) files.

ok bestie that's part 1, and there is so much more coming — do not go anywhere 🌸

✨ CRAWLING ✨

ok bestie so this is where you tell Wapiti how to walk around the site, and honestly it's giving very in control 💅

  • -s, --start URL — if for some reason Wapiti isn't finding any URLs (or like, not enough of them) from the base URL, you can just hand it extra URLs to kick the scan off with. Those URLs get a depth of 0, same as the base URL. You can call this option multiple times, no limit. You can also pass it a filename and Wapiti will read URLs from that file (it has to be UTF-8 encoded, ok?), one URL per line. 🦋
  • -x, --exclude URL — blocks the given URL from being scanned at all. The classic use case is excluding your logout URL so it doesn't nuke your session cookies (that only matters if you gave a cookie file with --cookie). You can apply this several times. And the excluded URL you pass in can contain wildcards for basic pattern matching. 🌸
  • -r, --remove PARAMETER — if that parameter shows up in a scanned URL, it gets automatically removed (yes, the URLs literally get edited). This one can also be used several times.
  • --skip PARAMETER — the parameter stays in URLs and forms, it just won't get attacked. Super useful when you already know a parameter is not vulnerable and you're not trying to waste your whole afternoon on it.
  • -d, --depth DEPTH — when Wapiti crawls a site it assigns a depth value to every URL it finds. The base URL, plus any extra starting URLs (-s), get a depth of 0. Every link found inside those gets a depth of 1, and so on, forever, into the void. The default maximum depth is 40, which is genuinely enormous. This limit exists so the scan eventually stops at some point, bestie. For a fast scan, a depth lower than 5 is the recommendation. ⭐
  • --max-links-per-page MAX — another way to shrink the number of URLs the crawler discovers. Only the first MAX links on each webpage get extracted. Ngl this one isn't super effective, because the same link can appear on different webpages anyway. It's useful in rare conditions, like when there's a lot of webpages with no query string. 🙈
  • --max-files-per-dir MAX — caps how many URLs get crawled under each folder found on the webserver. Heads up: a URL with a trailing slash in the path is not necessarily a folder, and Wapiti will treat it as if it is. Like the option above, this is only useful in certain situations.
  • --max-scan-time SECONDS — kills the scan after SECONDS seconds if it's still going. Handy for automating scans from another process (continuous testing vibes). ⏰
  • --max-attack-time SECONDS — every attack module stops after SECONDS seconds if it's still running. Also handy for automating scans from another process (continuous testing again).
  • --max-parameters MAX — any URLs and forms with more than MAX input parameters get thrown out before the attack modules even launch. bye 👋
  • --swagger URL — pulls API requests out of the Swagger file you specify. Those extracted requests get added to the crawler. ✨
  • --headless MODE — decide whether to crawl with the Firefox headless browser or not (not is the default). Using it lets you catch XHR requests, but it makes crawling slower. The possible values are:
    • no: the legacy crawler is used
    • hidden: the headless crawler is used but the Firefox window is hidden
    • visible: headless Firefox is used and it's visible (this can be useful to interact with it if it gets stuck)
  • --wait TIME — wait the specified number of seconds before analyzing a webpage. Headless mode only, bestie. 🧚

🚀 PERFORMANCE

ok so, math time, but it's for your own good 💖

  • -S, --scan-force FORCE — the more input parameters a URL or form has, the more requests Wapiti sends. That sum can grow rapidly, and attacking a form with 40 or more input fields can take a truly unhinged amount of time. So Wapiti uses a mathematical formula to reduce the number of URLs scanned for a given pattern (same variable names) as the number of parameters grows. The formula is:
maximum_allowed_patterns = 220 / (math.exp(number_of_parameters * factor) ** 2)

where factor is an internal value controlled by the FORCE value you pass in. The available choices are: paranoid, sneaky, polite, normal, aggressive, insane.

Default value is normal, which is 147 URLs for 1 parameter, 30 for 5, 5 for 10, and 1 for 14 or more.

insane mode just straight up removes the calculation of those limits — every URL will be attacked. 😭

paranoid mode will attack 30 URLs with 1 parameter, 5 for 2, and just 1 for 3 and more. 🎀

  • --tasks TASKS — sets how many concurrent tasks Wapiti should use. It leverages Python's asyncio framework for this. 🔥

🌐 ENDPOINT OPTIONS

So some attack modules use an HTTP endpoint to check for vulnerabilities. For example, the SSRF module injects the endpoint URL into webpage arguments to check whether the target script tries to fetch that URL. The default HTTP endpoint is http://wapiti3.ovh/. Keep in mind: the target and your computer both have to be able to reach that endpoint for the module to work. On internal pentests the endpoint may not be accessible to the target, which is why you might prefer to set up your own endpoint instead. 💅

  • --internal-endpoint URL — you might want to specify an internal endpoint that's different from the external one. The internal endpoint is what Wapiti uses to fetch the results of attacks. If you're behind a NAT, this could be a URL for a local server (for example http://192.168.0.1/).
  • --external-endpoint URL — sets the endpoint URL, the one the target will fetch in case of vulnerability. Using your own endpoint can reduce the risk of getting caught by NIDS or a WAF. 👑
  • --endpoint URL — this one sets both the internal and external endpoint URL to the same value. one option, both jobs, iconic ✨
  • --dns-endpoint DNS — specifies the DNS endpoint to use for the log4shell attack module. The default value is dns.wapiti3.ovh. 🦋

🛜 HTTP AND NETWORK OPTIONS

  • -t, --timeout SECONDS — how long to wait (in seconds) for an HTTP response before considering it a failure.
  • -H, --header HEADER — set a custom HTTM header to inject into every request Wapiti sends. This option can be used several times. The value should be a standard HTTP header line (parameter and value separated with a : sign).
  • -A, --user-agent AGENT — Wapiti's default behavior is to use the same User-Agent as the TorBrowser, which makes it discreet when crawling standard websites or .onion ones. But sometimes you have to change it to bypass some restrictions, so here's the option for that. 🕵️♀️
  • --verify-ssl VALUE — by default Wapiti does not care about certificate validation. That behavior can be changed by passing 1 as the value to this option.

🌈 OUTPUT OPTIONS

Wapiti prints its status to standard output. These two following options let you tune that output. 💖

  • --color — the output gets colorized based on the severity of the information: red is critical, orange is for warnings, green is for information. 🚦
  • -v, --verbose LEVEL — sets the verbosity level for the output. Possible values are quiet (O), normal (1, the default behavior) and verbose (2).
  • --log OUTPUT_PATH — on top of getting information from the console, you can also log the output to a local file. Debug information gets stored in that file too, so this option should mainly be used to debug Wapiti. 🐛

📄 REPORT OPTIONS

Wapiti generates a report at the end of the attack process. Several report formats are available. 💅

  • -f, --format FORMAT — sets the format of the report. Valid choices are json, html, txt and xml. Even though the HTML reports were rewritten to be more responsive, they still are impracticable when there's a lot of found vulnerabilities. ngl, fair warning.
  • -o, --output OUTPUT_PATH — sets the path where the report will be generated.
  • -dr, --detailed-report LEVEL — sets the level of detailed report for the output. Possible values are (1): adds the HTTP responses obtained for successful attacks in the report, and (2): also adds the HTTP requests and responses for all crawled pages in the report. 🍓

🌟 OTHER OPTIONS

  • --version — print the Wapiti version, then exit.
  • --no-bugreport — if a Wapiti attack module crashes from a non-caught exception, a bug report gets generated and sent for analysis so Wapiti's reliability can be improved. Note that only the content of the report is kept. You can still prevent reports from being sent using this option.
  • --update — update particular Wapiti modules (downloads a fresh version of the apps.json and nikto_db files), then exit. You can combine it with --store-config to specify where to store the downloaded files. You can also combine it with --wapp-url to update the Wappalyzer DB from a custom git repository, or with --wapp-dir to update it from a local Wappalyzer DB directory. ✨
  • -h, --help — show detailed options description. More details are available in this manpage though. 👑 (yes, the manpage is the moment)

📜 LICENSE

Wapiti is covered by the GNU General Public License (GPL), version 2. Please read the LICENSE file for more information.

Copyright (c) 2006-2024 Nicolas Surribas.

💜 AUTHORS

Nicolas Surribas is the main author, but the whole list of contributors is found in the separate AUTHORS file.

🌐 WEBSITE

https://wapiti-scanner.github.io/

🐞 BUG REPORTS

If you find a bug in Wapiti, please report it to https://github.com/wapiti-scanner/wapiti/issues

👀 SEE ALSO

The INSTALL.md file that comes with Wapiti contains every information required to install Wapiti.

ok that's the whole page bestie, you're officially Wapiti-literate 🎀 this was WAPITI(1), dated April 2026 — go forth and scan responsibly, mwah 💅💖

📦 where this page comes from