Nikto has been doing roughly the same job for a quarter-century: hammering a web server with thousands of pre-canned requests and telling you which ones came back with something useful. It is loud, it is old, it writes to stdout like it’s 2004 — and it still ships pre-installed on Kali Linux because nothing else quite replaces a fast, scriptable server-configuration scanner that runs from a Perl interpreter.
This guide covers what Nikto actually does in the current v2.5.0 release, how to run it without wasting an afternoon on noise, which tuning categories matter, and where it stops being the right tool. If you’ve been using it as a reflexive nikto -h before moving on to Burp, you’re leaving most of the scanner on the table.
What Nikto Actually Is
Nikto is an open-source command-line scanner written in Perl, built on top of LibWhisker2 — a Perl HTTP library originally authored by Rain Forest Puppy (RFP) that predates most modern TLS stacks. The project was started by Chris Sullo in 2001 and is currently maintained by David Lodge. The code is GPL-licensed; the signature database is not, and cannot be redistributed separately from the tool.
The scanner’s job is server-level reconnaissance. It fires 7,000-plus HTTP requests at a target looking for things a misconfigured web server is likely to leak: default install files, backup artifacts with predictable names (.bak, .old, ~), outdated server banners with known CVEs, insecure HTTP methods (PUT, DELETE, TRACE), missing security headers, weak TLS configurations, and a large catalogue of historically vulnerable CGI scripts. It is a signature scanner, not a crawler. It does not log in, it does not execute JavaScript, and it does not understand application business logic. The distinction matters more than most first-time users realize.
The current stable release is v2.5.0, shipped in late 2023 and still the latest tagged version as of writing. Development continues on the main branch with ongoing work on the response-matching DSL — the repo now documents BODY:, HEADER:, COOKIE:, and the recently added CODE: matchers, combinable with && for compound test definitions. This is where Nikto’s “pluggable” claim earns its keep: the test database is not hardcoded, and custom checks are a text-file edit away.
Installing and Orienting
On Debian, Ubuntu, or Kali, apt install nikto gets you a working scanner. macOS users can install via Homebrew. For anything beyond casual use, clone from GitHub — the packaged versions lag the repository by months, and the signature database benefits from being current.
git clone https://github.com/sullo/nikto
cd nikto/program
./nikto.pl -update
./nikto.pl -VersionThe -update flag pulls fresh databases and plugin signatures directly from cirt.net. The -Version flag tells you the software version, plugin version, and database version separately — worth checking before blaming the tool when a known check fails to trigger.
A first scan is deliberately dull:
nikto -h https://target.example.comThat runs every enabled plugin against the target. Expect a wall of output, most of it informational. The default run is a bad way to learn what Nikto does because it buries the interesting findings in header advisories and robots.txt noise.
A Real Workflow
The scanner becomes useful when you stop running it in default mode. Three adjustments do most of the work:
Tune the scan. The -Tuning flag restricts checks to specific categories. -Tuning 123 runs only interesting files, misconfigurations, and information disclosure — the three categories that produce most of the genuinely actionable findings on an unknown target. The reverse flag, -Tuning x6, runs everything except denial-of-service checks, which is the sane default for any production target.
Control output. -o report.html -Format htm writes a browsable report; -Format json gives you something to pipe into tooling. Multiple formats can be requested in one run with a comma-separated list.
Evade noisy WAFs. -evasion accepts a string of encoding techniques — random URI encoding, directory self-reference, case changes, request spacers. None of these will fool a modern WAF, but they’re useful when you’re specifically testing whether a signature-based filter catches obvious patterns.
A realistic tuned scan looks closer to this:
nikto -h https://target.example.com -p 443 \
-Tuning x6 -Display V -o scan.json -Format json \
-maxtime 30m -ask noThat’s a verbose scan excluding DoS tests, capped at 30 minutes, writing JSON output, and skipping the interactive prompt about submitting updated findings back to CIRT. In scripted environments, -ask no is mandatory — the default prompts will hang a CI pipeline.
The Tuning Categories You Should Actually Know
The -Tuning flag is where most scans live or die. Nikto groups its checks into 15 categories referenced by a single character each, and you combine them freely. The reference below matches the categories documented in the current wiki and man page.
The tuning string parses left-to-right, and once x appears, it applies to everything following it. -Tuning x69 means “all tests except DoS and SQL injection,” not “all tests plus reversed 6 plus 9.” This bites people routinely.
Where Nikto Actually Stops
Nikto is not a modern DAST scanner and was never trying to be one. It does not authenticate to login forms beyond HTTP Basic, it does not render JavaScript, it cannot follow single-page application routing, and its SQL injection checks (category 9) are shallow signature lookups — not the parameterized, boolean-based fuzzing a tool like sqlmap performs. Treating the 9 category as real SQLi coverage is a mistake.
The scanner is also extremely loud. Every request is logged in access logs, many requests hit URLs that do not exist and generate 404 storms, and the default user-agent string announces itself openly. Against a target with any IDS or WAF worth the name, you will be blocked within minutes. That is not a bug — Nikto was written for authorized testing where getting blocked means the client’s controls are working. If stealth matters, this is the wrong tool.
Two other limits worth flagging: SOCKS proxies are not supported in the current release (HTTP proxies via -useproxy are fine), and the scanner’s signature database skews toward older web stacks. You will get excellent coverage of Apache 2.2 install defaults and mid-2010s CGI scripts; you will get thinner coverage of a modern containerized Go service behind a reverse proxy.
Where It Still Wins
Against those limits sit genuine strengths. Nikto runs on anything with a Perl interpreter, which in 2026 means every Linux distribution, every macOS install, and any WSL environment without ceremony. A full default scan against a single target completes in roughly 5–15 minutes depending on latency — fast enough to run during reconnaissance without blocking the rest of your workflow. The output is plain text and parseable JSON, so wiring it into a CI pipeline or a chained tool is a matter of minutes. Against legacy infrastructure — which still represents a large share of real engagement targets — it finds things newer scanners miss because they assume a modern stack.
The pluggable test database is also a quiet superpower. The response-matching DSL means writing a custom check for an organization-specific misconfiguration is a text-file edit, not a development project. Few scanners in this category are that trivially extensible.
FAQ
Is Nikto still maintained? Yes. The repository at github.com/sullo/nikto has active commits on main, and the signature database receives regular updates. The pace is slower than commercial scanners, but the project is not abandoned.
Does Nikto replace Burp Suite or OWASP ZAP? No. It complements them. Nikto handles the server-configuration layer in a few minutes so you can spend your Burp time on application logic, which is where real vulnerabilities increasingly live.
Can I run it against a site I don’t own? Only with written authorization. Unauthorized scanning is illegal in most jurisdictions regardless of intent, and Nikto’s request patterns are distinctive enough that attribution is easy.
How does Nikto compare to Nuclei? Nuclei covers similar ground with YAML-based templates and a far larger active community. For greenfield use in 2026, many teams have migrated scanning pipelines to Nuclei. Nikto remains valuable for legacy coverage and for the specific checks its database does better.
The Verdict
Nikto is not the scanner you reach for if you only have one. It is the scanner you reach for first, because a tuned run completes while you’re still reading the target’s landing page, and it will tell you whether the server is running something obviously broken before you invest real time. For internal assessments of older infrastructure, for compliance scans that need documented server-level coverage, and for scripted CI pipelines that just need a known-good baseline check, it remains a sensible choice a quarter-century after it was written.
Install it. Learn the tuning flags. Don’t use the default scan.
