Nikto
web server scan, JSON output. Part of AuditCore's automated security audit pipeline — runs on every scan in the Pro tier and above, with findings normalized into a single severity-rated table.
What is Nikto?
Nikto is one of the oldest open-source web server scanners (first released in 2001) and still useful for what it does well: finding outdated web server software, default files, dangerous CGI scripts, server misconfigurations, and a long tail of legacy issues that modern scanners overlook. AuditCore runs Nikto in the injection phase as a complement to ZAP — Nikto's database of 6,700+ checks includes things ZAP doesn't (Apache version-specific paths, default IIS files, legacy PHP scripts, vendor-default admin pages).
Where Nikto shines: finding 'forgotten' artifacts. The /phpmyadmin/ left from a 2018 dev install. The /admin.php that Drupal 6 used to ship by default. The /test.cgi that Bugzilla left behind. The /backup.tar.gz that someone copied to webroot 'just for a second'. Nikto's database has been curated for 23 years and includes patterns that newer scanners simply don't think to check.
Where Nikto is showing its age: it's noisy (lots of '200 OK' findings on apps that return 200 for everything including 404s), it's slow (HTTP/1.1 only, no HTTP/2 multiplexing), and many checks are for software that doesn't exist anymore. We run it with `-Tuning x4567890ab -nointeractive -Format json -timeout 10` to filter to high-value tunings (file upload, configuration, info disclosure, injection, RFI, command exec, default files, server overflow, identification, auth bypass).
We deduplicate Nikto's findings against ZAP and Nuclei — there's significant overlap on common patterns (exposed `.git`, missing security headers, info disclosure). When all three tools agree, the finding is high-confidence. When only Nikto reports something, treat it as 'worth investigating' rather than 'definitely vulnerable' — Nikto's age means it has a higher false-positive rate than modern scanners.
What it tests
- Outdated web server versions (Apache, nginx, IIS, lighttpd)
- Default files left from CMS / framework installs (~3,500 patterns)
- Dangerous CGI scripts (legacy `phpinfo.php`, `test.cgi`, `info.php`)
- Server misconfigurations (directory listing, OPTIONS allowing PUT/DELETE)
- Information disclosure (PHP errors, version banners in HTTP headers)
- Default vendor admin paths (printers, IoT devices, NAS)
- Backup file patterns (`.bak`, `.old`, `.swp`, `~`, `.tar.gz`)
- Common authentication bypass paths (URL trickery for old apps)
- SSL/TLS info (overlap with SSLyze — we deduplicate)
- User-enumerable paths (e.g., `?author=N` patterns predating WordPress scanner)
Where it runs in the AuditCore pipeline
Phase 4/5 · Injection & Active Tests
Active payload-based scanning — SQL, NoSQL, command, template, XXE, SSRF, prototype pollution, race conditions, AI prompt injection, business-logic abuse, plus full ZAP / Nuclei / sqlmap.
Source: scanners/nikto_scanner.py
Sample findings
Apache 2.2.22 — multiple known CVEs
High. Server header reveals Apache 2.2.22 (released 2012, EOL 2017). Vulnerable to CVE-2017-15715 (mod_negotiation), CVE-2017-9788 (mod_auth_digest memory leak), and several others. Mitigation: upgrade to Apache 2.4.x current. If you can't upgrade, suppress the Server header (`ServerTokens Prod`).
/phpmyadmin/ exposed without auth
Critical if reachable. phpMyAdmin login page accessible from the public internet. Even with authentication, brute-forcing the DB user is a real risk and historic phpMyAdmin CVEs allow auth bypass. Mitigation: restrict by IP allow-list, put behind VPN, or ideally don't run phpMyAdmin in production at all.
OPTIONS method allows PUT and DELETE
High. Web server responds to OPTIONS with `Allow: GET, POST, PUT, DELETE, OPTIONS`. If WebDAV is enabled and not authenticated, attackers can upload arbitrary files. Mitigation: disable WebDAV unless explicitly needed; if needed, require authentication.
Backup file at /database.sql.bak
Critical. Web-accessible SQL dump file. Likely contains schema and possibly seeded data including hashed passwords. Mitigation: remove from webroot immediately; consider what's leaked already (rotate any credentials present); add backup file patterns to nginx/Apache deny rules.
Other injection & active tests scanners
FAQ
Is Nikto still relevant in 2026?
Yes, but with caveats. For modern SaaS apps on cloud infrastructure, Nikto finds less than ZAP/Nuclei. For legacy enterprise apps, hosted PHP, on-prem appliances, and forgotten WordPress installs — Nikto still finds things others miss because it's been maintained for 23 years and remembers patterns from every era of the web.
Why does Nikto report so many false positives?
Nikto fires every check it knows against every host it scans. If your app returns HTTP 200 for unknown paths (single-page apps often do this), Nikto interprets that as 'page exists' and reports thousands of findings. AuditCore's reporting layer attempts to filter the most obvious cases, but you may still see noise. Treat low-severity Nikto findings as 'verify manually'.
How does Nikto compare to OWASP ZAP?
ZAP is broader and more accurate for modern web apps. Nikto is deeper for legacy patterns and server-level checks. They overlap maybe 30%. AuditCore runs both and deduplicates — when both flag the same issue, confidence is high; when only one flags it, treat with appropriate skepticism.
Will Nikto trigger my WAF?
Yes. Nikto sends thousands of weird HTTP requests in quick succession. Cloudflare, AWS WAF, and most CDNs will rate-limit or challenge it. If your AuditCore Nikto findings look unusually quiet, your WAF is working. To audit behind the WAF, configure the WAF to allow-list AuditCore's IPs (we publish them in the trust page).
Can I disable Nikto if I don't want it running?
Not currently via the UI — it's part of the standard Pro+ pipeline. If you have a specific reason to exclude it (e.g. WAF rate-limiting causing scan failures), contact us and we'll add a per-domain exclusion.