# Wapiti 3.3.2 for black-box web vulnerability scanning

> Wapiti is a Python web vulnerability scanner for security engineers, system administrators, and developers who need to inspect a deployed application from the outside. It crawls URLs and forms, sends attack payloads through GET, POST, multipart, and JSON requests, and records findings in reports or SQLite sessions.

**wapiti-scanner/wapiti** — Web vulnerability scanner written in Python3

- Repository: https://github.com/wapiti-scanner/wapiti
- Website: https://wapiti-scanner.github.io/
- Stars: 1,893 · Forks: 276
- Language: Python
- License: GPL-2.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/wapiti-scanner-wapiti

## What Wapiti scans and who should use it

Wapiti addresses the problem of finding common web application weaknesses without access to the application source code. The README describes it as a black-box scanner, so it examines a deployed application through its HTTP interface. This makes it relevant to penetration testers, security engineers, system administrators, and developers who own a site or have explicit permission to test one. The intended audience is also reflected in the project metadata, which lists end users, developers, and system administrators as classifications.

The scanner is not limited to one vulnerability family. Its documented modules cover SQL and XPath injection, LDAP injection, reflected and permanent XSS, file disclosure, command execution, XXE, CRLF injection, open redirects, SSRF, unusual HTTP methods, CSRF, cookie flags, HTTP security headers, backup files, directory and file enumeration, Shellshock, Log4Shell, Spring4Shell, upload vulnerabilities, CMS detection, network devices, and other web security checks. A separate `csp` module evaluates Content Security Policy configuration, while `http_headers` checks response headers.

Wapiti also supports REST APIs described by an OpenAPI or Swagger file. That makes it useful for teams that need to test both conventional HTML applications and documented API surfaces. The choice still depends on coverage. A finding means that a response matched a module’s detection logic, not that the scanner proved every possible security property of the application. The project’s `permanentxss` module, for example, rescans the target after an XSS module runs so it can look for payloads that persist and appear elsewhere.

## The crawler and attack payload flow

Wapiti’s operating model is visible in its README description of a fuzzer. It crawls pages, extracts links and forms, then attacks the discovered scripts by sending payloads and watching for error messages, special strings, or abnormal behavior. The flow starts with a seed URL and produces a set of HTTP requests and responses that attack modules can examine. The crawler also has controls for scope, crawl depth, parameter handling, exclusions, and maximum scan time.

The attack layer supports GET and POST methods. It also supports multipart requests and can inject payloads into uploaded filenames. The README additionally states that Wapiti can inject payloads into JSON request bodies. This is materially different from a scanner that only submits conventional HTML forms, because the request representation and parameter location both affect where a test can reach application code.

The session mechanism stores scan and attack state in SQLite databases, allowing a scan or attack to be suspended and resumed. Reports can be generated as HTML, XML, JSON, TXT, CSV, or Markdown. Terminal output can use color and several verbosity levels, while attack modules can be enabled or disabled. Payload customization is also simple: the README says that adding a payload can be as little as adding a line to a text file.

Wapiti can constrain a scan to a domain, folder, page, or URL. It can exclude URLs from crawling and attacks, which is important when a logout endpoint or administrative action must not be triggered. It also supports first URLs outside the normal scope, automatic removal of URL parameters, parameter limits intended to prevent endless loops, custom headers, custom User-Agent values, and SSL certificate verification controls. These controls make the crawler configurable, but they also mean that an incomplete scope or exclusion policy can reduce coverage.

## Authentication, proxies, and browser support

Authentication is handled through several mechanisms. Wapiti supports Basic, Digest, and NTLM HTTP authentication, and it can fill login forms. Cookies can be imported from Chrome or Firefox or obtained with the `wapiti-getcookie` tool. For authentication cases that do not fit the built-in flow, the `--form-script` option accepts custom Python code.

Network access can use HTTP, HTTPS, or SOCKS5 proxies. The project also includes Playwright as a dependency and documents the use of a Firefox headless browser for crawling. That browser path can help with pages whose behavior depends on JavaScript, although the README describes the JavaScript URL extraction support as very basic. Browser-cookie extraction and headless crawling add operational requirements that are not present in a minimal HTTP-only installation.

Wapiti can inspect JavaScript for URLs, understand recent HTML tags, and scan APIs from an OpenAPI file. The project metadata lists `playwright`, `browser-cookie3`, and `wapiti-swagger` among its dependencies. The Dockerfile uses Python 3.13 and installs the package into a slim image, with `wapiti` as its entrypoint. This packaging route is relevant for repeatable deployments, but the image alone does not document every runtime dependency needed for browser interaction, so operators should check the installation documentation before assuming that headless crawling works immediately.

The scanner also offers Wappalyzer-based technology fingerprinting and related CVE information. That is useful for inventory and prioritization, but it remains an external-data and detection feature. The README does not claim that technology identification proves exploitability.

## Wapiti installation from the repository

Once installed, the executable is `wapiti`. The README does not include a complete first-scan command, so it would be unsafe to invent a target URL, flag, module list, or output filename. The project’s homepage and `INSTALL.md` are the documented places to obtain fuller invocation guidance.

For a controlled first use, the operator needs an authorized target, a defined scope, and a deliberate module set. The crawler can begin with URLs outside the scan scope, but that should be reserved for cases where the seed page is known to be necessary. Proxy settings, authentication, cookie import, custom headers, and certificate verification should be configured before starting a long-running scan.

The repository’s Makefile also exposes development commands. It builds a test image and runs it, while an integration test invokes a shell script under `tests/integration`. Those commands are project maintenance commands rather than application scanning examples, and the README does not document their runtime output.

## Where Wapiti has limits and failure modes

The largest limitation is inherent in black-box testing. Wapiti does not inspect application source code, so it cannot directly reason about authorization boundaries, data flow, custom server-side logic, or vulnerabilities that require a precise internal condition. Its results depend on reachable pages, forms, parameters, request formats, and the behavior visible in HTTP responses. A clean scan does not establish that the target is free of vulnerabilities.

Payload-based detection can also produce false positives or false negatives. The modules look for error messages, special strings, and abnormal behavior, but application responses may be customized, rate-limited, cached, or inconsistent. A timeout can indicate a possible time-based injection issue, but it can also result from network instability or an overloaded server. The README does not document a formal confidence model for individual findings.

The scan itself can be destructive or disruptive even when the project is used for authorized testing. It supports command execution detection, file disclosure, directory enumeration, login form brute forcing, file upload tests, and database injection modules. Scope exclusions and crawl limits are therefore operational requirements, not optional refinements. The README gives examples such as excluding a logout URL and limiting parameter values, but it does not promise that every state-changing or logout-like route will be recognized automatically.

Windows use is documented through WSL rather than as a native Windows installation path. The supported Python versions are also narrower than the full range of current Python releases. Browser-based crawling, imported cookies, proxy routing, and custom authentication can add dependencies and failure points. The project’s black-box model is a poor fit when the organization needs source-assisted findings or proof that an endpoint is unreachable only because of application-specific authorization.

## Wapiti versus source-assisted security analysis

Wapiti is an external HTTP-oriented alternative to source-code security tools and manual unit-level review. Its distinctive approach is to simulate attacker input against a running application. It discovers links and forms, sends payloads through supported request methods, and interprets the responses. A source-assisted tool can instead follow symbols, configuration, and code paths inside a repository or application bundle. Those approaches answer different questions: Wapiti asks what an exposed service appears to reveal over HTTP, while source analysis can identify unsafe code that may not currently be reachable.

Another practical comparison is with a conventional web crawler. A crawler primarily maps URLs and content. Wapiti retains crawling as a foundation, but adds attack modules, anomaly detection, authentication support, session persistence, vulnerability reporting, and payload handling. That makes it more suitable for an authorized assessment workflow, while also making scans heavier and more dependent on careful configuration.

Wapiti is not a complete replacement for manual review either. The README does not describe a guarantee of completeness, formal compliance evidence, or automatic remediation. Its report formats and CSV or JSON output can support triage, but the engineering team still has to validate findings, understand impact, and define retesting criteria.

## Maintenance, upgrades, and GPL-2.0 implications

The repository is not archived, and its last push was on 2026-10-05. Recent releases include 3.3.2 on 2026-08-19, 3.3.1 on 2026-07-27, and 3.3.0 on 2026-05-13. Those facts support a recently changed project, but they do not by themselves establish compatibility with a particular deployment or a guaranteed maintenance schedule.

Upgrades can affect the Python runtime, dependency ranges, browser integration, and module behavior. The project metadata declares Python `>=3.12,<3.15` and pins several dependencies with version ranges, including Playwright, HTTPX, SQLAlchemy, and mitmproxy. An upgrade plan should therefore include checking the supported Python version and reviewing dependency changes, especially when a scan depends on proxy behavior, cookies, or headless Firefox crawling.

The package is identified as GPL-2.0 and the repository contains a `LICENSE` file. Distribution and integration implications depend on how the software is used and modified, so organizations needing license compliance should review the license with their own policy or legal contact. This article does not provide legal advice. The practical maintenance point is narrower: operators should expect to track package releases and dependency compatibility rather than treating the scanner as a static executable.

## Conclusion

Wapiti fits teams that need repeatable black-box checks against an owned or authorized web application and can operate its crawler and attack modules. It is a poor fit for source-code analysis, applications requiring manual authentication logic without custom scripts, or scans that need certainty beyond payload-based detection. Verify the target scope, authentication setup, proxy and browser dependencies, module selection, and report handling first; the documented starting command is `pip3 install .`, followed by the project’s `wapiti` executable against an authorized target.

## FAQ

### What is Wapiti used for?

Wapiti is used to scan a deployed web application for vulnerabilities from the outside. It crawls pages and forms, sends payloads, and reports responses that match its attack modules.

### Which Python versions does Wapiti require?

The README requires Python 3.12, 3.13, or 3.14. The project metadata declares `requires-python = ">=3.12,<3.15"`.

### Can Wapiti scan a REST API?

Yes. The README says that Wapiti can scan REST APIs given an OpenAPI or Swagger file. The project metadata includes `wapiti-swagger` as a dependency.

### Does Wapiti support authenticated scans?

Yes. Wapiti supports Basic, Digest, and NTLM HTTP authentication, login-form filling, browser cookie import, and custom Python authentication through `--form-script`.

### Does Wapiti inspect source code?

No. The README describes Wapiti as a black-box scanner. It examines deployed pages, links, forms, requests, and responses rather than studying application source code.

## Sources

- [License: GPL-2.0](https://github.com/wapiti-scanner/wapiti/blob/master/LICENSE)
- [Project website](https://wapiti-scanner.github.io/)
- [README](https://github.com/wapiti-scanner/wapiti/blob/master/README.md)
- [Releases](https://github.com/wapiti-scanner/wapiti/releases)
- [wapiti-scanner/wapiti on GitHub](https://github.com/wapiti-scanner/wapiti)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/wapiti-scanner-wapiti