Installation on Debian, Ubuntu, RHEL, and Arch
On Debian and Ubuntu, nikto is in the main repository and installs without adding any PPA:
``` apt install nikto ```
On RHEL 9 and Rocky Linux 9, it lives in EPEL:
``` dnf install epel-release && dnf install nikto ```
On Arch:
``` pacman -S nikto ```
If you need the absolute latest build - useful when you are testing against a recently disclosed CVE that older package versions do not yet cover - clone directly from the project repository:
``` git clone https://github.com/sullo/nikto.git cd nikto/program perl nikto.pl -Version ```
The git version as of mid-2026 identifies itself as 2.1.6+. The database files live under `databases/` and you update them with:
``` perl nikto.pl -update ```
Run that update before any serious engagement. Stale databases mean missed checks.
apt install nikto
nikto -VersionBasic Scan Syntax and What the Output Tells You
The minimal invocation is:
``` nikto -h https://target.example.com ```
Nikto resolves the host, identifies the server banner, and begins firing requests. A typical result block looks like this:
``` + Server: Apache/2.4.51 (Ubuntu) + /admin/: Admin login page/section found. + OSVDB-3233: /icons/README: Apache default file found. + Cookie session created without the httponly flag + Retrieved x-powered-by header: PHP/8.1.2 ```
Each line prefixed with `+` is a finding. Lines with `OSVDB-` codes reference the now-archived Open Source Vulnerability Database - the numbers still appear in Nikto output for historical continuity but cross-referencing them requires a search engine or CVE mapping. The more useful identifiers are the plain-English descriptions.
Nikto does not attempt to be stealthy. It fires hundreds of requests in sequence and will appear in any competent WAF or IDS log within seconds. This is intentional - Nikto is a tool for authorized testing, not covert reconnaissance. If you need to slow it down to avoid triggering rate limits on a production host during a maintenance window, use the `-pause` flag:
``` nikto -h https://target.example.com -pause 2 ```
That inserts a 2-second delay between requests. It makes a 20-minute scan run for over an hour, but it keeps the server logs cleaner and reduces the chance of hitting a circuit breaker.
nikto -h https://target.example.com -pause 2Specifying Ports, SSL, and Virtual Hosts
By default Nikto scans port 80 for plain HTTP and port 443 for HTTPS. If your application runs on a non-standard port, specify it explicitly:
``` nikto -h target.example.com -p 8443 -ssl ```
For a server hosting multiple virtual hosts, the `-vhost` flag sets the Host header independently of the IP you are connecting to:
``` nikto -h 192.168.1.50 -vhost staging.example.com -ssl ```
This matters when you are scanning a server before DNS propagation is complete, or when you need to scan a specific vhost on a shared IP without touching the others. In our experience, skipping `-vhost` on shared hosting produces results that belong to the wrong application entirely - a common source of false positives in penetration test reports.
To scan multiple targets from a file, one host per line:
``` nikto -h targets.txt ```
The file can contain bare hostnames, IPs, or full URLs including port notation like `https://host:8443`. Nikto processes them sequentially.
nikto -h 192.168.1.50 -vhost staging.example.com -ssl -p 8443Tuning Scans with the -Tuning Flag
The `-Tuning` flag is the most important option most people skip. Without it, Nikto runs all test categories, including injection tests and file upload checks that will modify application state on a live server. The tuning codes are:
``` 0 - File Upload 1 - Interesting File / Seen in Logs 2 - Misconfiguration / Default File 3 - Information Disclosure 4 - Injection (XSS/Script/HTML) 5 - Remote File Retrieval - Inside Web Root 6 - Denial of Service 7 - Remote File Retrieval - Server Wide 8 - Command Execution / Remote Shell 9 - SQL Injection a - Authentication Bypass b - Software Identification c - Remote Source Inclusion x - Reverse Tuning (exclude the listed tests) ```
For a safe read-only recon scan against a production host, restrict to information disclosure and misconfiguration checks:
``` nikto -h https://target.example.com -Tuning 23b ```
That runs categories 2 (misconfigurations), 3 (information disclosure), and b (software identification) only. It will not attempt injections, file uploads, or command execution.
For a full-scope internal test on a staging environment where you want everything:
``` nikto -h https://staging.example.com -Tuning x6 ```
The `x` reverses the selection, so `x6` means "run everything except denial of service tests." Running DoS tests against anything you want to keep running is obviously not recommended.
When combining tuning codes, order does not matter - `23b` and `b23` produce the same result.
nikto -h https://target.example.com -Tuning 23bAuthentication: Basic Auth, Form Login, and Cookies
Many applications sit behind authentication. Nikto supports HTTP Basic Auth directly:
``` nikto -h https://target.example.com -id admin:password123 ```
For session-based authentication where you need to supply a cookie, grab the session token from your browser's developer tools after logging in manually, then pass it with `-c`:
``` nikto -h https://target.example.com -c "PHPSESSID=abc123def456; auth_token=xyz789" ```
For form-based login, Nikto does not have a native form-submission flow. The practical workaround is to authenticate in a browser or with curl, extract the session cookie, and feed it to Nikto. A one-liner to get a session cookie via curl and then run Nikto against an authenticated session:
``` COOKIE=$(curl -s -c - -X POST https://target.example.com/login \ -d 'username=admin&password=secret' | grep -oP 'PHPSESSID\s+\K\S+') nikto -h https://target.example.com -c "PHPSESSID=$COOKIE" ```
This only works when the login endpoint returns a straightforward Set-Cookie header. CSRF-protected forms require a two-step curl chain that fetches the token first. In our experience, for complex authentication flows, running Nikto inside an authenticated Burp Suite proxy session is cleaner than scripting around cookie extraction.
nikto -h https://target.example.com -id admin:password123
nikto -h https://target.example.com -c "PHPSESSID=abc123def456"Output Formats: Plain Text, CSV, HTML, and XML
Nikto's default output goes to stdout. For anything you need to archive or process programmatically, use `-o` with a filename and `-Format` to specify the format:
``` nikto -h https://target.example.com -o results.xml -Format xml ```
Available formats: `csv`, `htm`, `xml`, `txt`, `nbe` (Nessus NBE format for import). The XML output is the most useful for pipeline integration because it can be parsed with standard tools:
```
grep '
For a quick human-readable report that you can send to a developer without asking them to interpret terminal output, the HTM format produces a self-contained HTML file:
``` nikto -h https://target.example.com -o report.html -Format htm ```
For CSV output that feeds into a spreadsheet or a SIEM ingestion pipeline:
``` nikto -h https://target.example.com -o findings.csv -Format csv ```
The CSV columns are: Hostname, IP, Port, URI, HTTP Method, Description, Test Links, OSVDB. You can filter immediately with awk:
``` awk -F',' '$8 != "" {print $4, $6}' findings.csv ```
That prints only findings that have an OSVDB reference, which tends to filter out the informational noise.
nikto -h https://target.example.com -o results.xml -Format xml
nikto -h https://target.example.com -o report.html -Format htmRunning Nikto Through a Proxy
When you need to route Nikto traffic through Burp Suite or another intercepting proxy - useful when you want to capture and replay interesting requests - use the `-useproxy` flag:
``` nikto -h https://target.example.com -useproxy http://127.0.0.1:8080 ```
This sends all Nikto requests through Burp's proxy listener. You can then inspect what Nikto sent, identify the requests that triggered interesting responses, and manually probe those endpoints with more precision.
For SOCKS5 proxying through an SSH tunnel, Nikto does not natively support SOCKS but `proxychains` handles it:
``` ssh -D 1080 -N user@jumphost & proxychains nikto -h https://internal.target.example.com ```
The `/etc/proxychains.conf` or `~/.proxychains/proxychains.conf` needs `socks5 127.0.0.1 1080` in the ProxyList section. This is the standard approach when scanning an internal web application through a bastion host.
One limitation: when routing through a proxy, Nikto's SSL verification sometimes produces false negatives on certificate checks. Add `-nossl` only if you have already verified the certificate separately and are using the proxy purely for traffic capture.
nikto -h https://target.example.com -useproxy http://127.0.0.1:8080Integrating Nikto into CI/CD Pipelines
Running Nikto as part of a deployment pipeline catches regressions - a misconfigured header introduced in a new server config, a debug endpoint accidentally exposed in a new release. The key constraint is that Nikto's exit code is 0 on completion regardless of findings, so you need to parse the output to fail a build.
A shell function that fails the CI job if Nikto finds anything above informational level:
``` #!/bin/bash nikto -h https://staging.example.com -Tuning 23b -o /tmp/nikto_out.csv -Format csv HIGH=$(grep -c 'OSVDB' /tmp/nikto_out.csv) if [ "$HIGH" -gt 0 ]; then echo "Nikto found $HIGH issues with OSVDB references" cat /tmp/nikto_out.csv exit 1 fi ```
In a GitLab CI pipeline, this becomes a stage after deploy-to-staging:
```yaml security-scan: stage: verify script: - nikto -h $STAGING_URL -Tuning 23b -o nikto.csv -Format csv - if grep -q OSVDB nikto.csv; then cat nikto.csv; exit 1; fi artifacts: paths: - nikto.csv when: always ```
For teams building automated security workflows at scale, platforms like taskbotshub.ai provide AI-driven orchestration that can chain Nikto scans with downstream remediation tasks - filing tickets, triggering rollbacks, or alerting on-call based on finding severity parsed from the XML output. This is useful when you have dozens of microservices each with their own staging endpoint and cannot realistically review Nikto output manually for every deployment.
Keep scan scope tight in CI. Running `-Tuning x6` (everything except DoS) against a staging environment that shares infrastructure with production is a reliable way to cause an incident. Restrict to `23b` in automated runs and reserve full-scope scans for scheduled manual testing windows.
nikto -h $STAGING_URL -Tuning 23b -o nikto.csv -Format csvNikto Configuration File: nikto.conf
The global configuration file is at `/etc/nikto.conf` on most distributions, or `nikto/program/nikto.conf` when running from a git clone. It controls defaults that you would otherwise repeat on every command line.
Key settings to review and configure for your environment:
``` # Set your default output format FORMAT=xml
# Set a realistic timeout - default 10 seconds is too short for slow apps TIMEOUT=20
# Set the user agent - useful for distinguishing scanner traffic in logs USERAGENT=Mozilla/5.0 (MyUnix Security Scanner)
# Exclude specific URLs from scanning (regex) EXCLUDE=/logout|/delete|/admin/reset
# Set a default proxy if your test network requires one PROXYHOST=127.0.0.1 PROXYPORT=8080 ```
The `EXCLUDE` directive is particularly important. If your application has destructive endpoints - account deletion, data purge, logout - Nikto will happily hit them repeatedly. Excluding `/logout` prevents Nikto from invalidating your session mid-scan. Excluding `/admin/delete` prevents accidental data loss during a test.
The configuration file also controls the database directory path (`DBDIR`) which matters when you are running multiple Nikto versions on the same machine or maintaining a custom plugin database alongside the standard one.
TIMEOUT=20
USERAGENT=Mozilla/5.0 (MyUnix Security Scanner)
EXCLUDE=/logout|/delete|/admin/resetCommon False Positives and How to Handle Them
Nikto generates false positives. This is not a flaw - it is a side effect of signature-based scanning against applications that rewrite URLs or return custom 404 pages with 200 status codes. Knowing the common patterns saves time.
The most frequent false positive: a web application that returns HTTP 200 for every URL (custom 404 handling) causes Nikto to flag hundreds of "found" files that do not actually exist. Nikto attempts to detect this with a random URL probe at startup, but custom 404 pages that vary response body while keeping status 200 can defeat this detection.
Verify any file-existence finding manually:
``` curl -I https://target.example.com/icons/README curl -I https://target.example.com/this-file-definitely-does-not-exist-12345 ```
If both return identical Content-Length values, you are looking at a catch-all handler and those file-found findings are false positives.
Another common false positive: Nikto flags missing security headers on a load balancer endpoint that strips those headers from backend responses. The application itself may set them correctly but the scanner sees the stripped version. Always confirm header findings against the actual response path:
``` curl -I -L https://target.example.com | grep -i 'strict-transport\|x-frame\|content-security' ```
The `-L` flag follows redirects, which matters because security headers on the 301 response are irrelevant - you want to see the final destination's headers.
If you are building a project or service name around your security tooling and need a domain, checking availability through a service like nicename.me makes sense before committing to a naming convention - a properly named internal security scanning project is easier to reference in runbooks and audit logs than a generic hostname.
curl -I https://target.example.com/icons/README
curl -I -L https://target.example.com | grep -i 'strict-transport\|x-frame\|content-security'Nikto vs Alternatives: When to Use Something Else
Nikto is fast to deploy and requires no configuration to produce actionable output, but it is not the right tool for every situation.
For authenticated application scanning where you need to map all application routes, spider forms, and test business logic, OWASP ZAP or Burp Suite Professional handle session management and form interaction that Nikto does not. Nikto has no built-in spider - it fires requests at known paths and does not discover application-specific routes.
For infrastructure-level scanning across many ports and services, nmap with the `http-*` NSE scripts provides more granular control:
``` nmap -p 80,443,8080,8443 --script http-headers,http-security-headers,http-auth-finder target.example.com ```
For pure SSL/TLS configuration testing, `testssl.sh` produces far more detailed certificate and cipher suite analysis than Nikto's SSL checks:
``` testssl.sh --severity HIGH https://target.example.com ```
Nikto's strongest use case remains broad-coverage web server reconnaissance - quickly identifying whether a server is running a vulnerable software version, exposing default files, or missing basic security headers. It covers a lot of ground in under five minutes, which makes it the right first tool before deciding whether deeper scanning is warranted. It is not a replacement for a full application security assessment.
nmap -p 80,443,8080,8443 --script http-headers,http-security-headers target.example.com
testssl.sh --severity HIGH https://target.example.com