17 Findings in 4 Seconds: SecurityClaw's Web Scanner Finds Every Planted Misconfiguration

What We Tested

The setup was a Python SimpleHTTPServer running on localhost:18080. Deliberately misconfigured. Five intentional problems planted in the file system — the kind of real-world mistakes that ship to production regularly.

The five planted misconfigurations:

• backup.zip — A backup archive left accessible at the web root. Development habit that turns into a data disclosure incident (CWE-530).
• test.php — A debug/test file left in production. Common in every codebase. Sometimes executes arbitrary code.
• .git/HEAD — The git repository left accessible over HTTP. This one gets its own section below.
• /server-status — Apache's internal status endpoint exposed. Shows active connections, running worker processes, request history, and client IPs.
• readme.txt — Version info and credentials in a text file at the root. You'd be surprised how often this ships.

We ran the Nikto campaign with default settings: nikto -h http://localhost:18080 -nointeractive -maxtime 60s. No custom tuning, no tweaked thresholds. This is the out-of-the-box SecurityClaw web scan experience.

What It Found

Scan time: 4 seconds. 17 total findings. 5/5 planted misconfigs detected. 12 additional real issues on the server. 2 documented false positives (covered below).

The detection rate on the planted misconfigurations: 5/5 (100%). The two false positives were technology-stack mismatch — Nikto fired checks designed for Apache and PHP against a Python SimpleHTTP server. Those are documented below.

The Standout Finding: .git/HEAD — The Misconfiguration That Hands Attackers Your Codebase

Of the five findings, the exposed .git/HEAD is the one that warrants a full stop.

When a web server exposes the .git/ directory over HTTP, it's not just a single file at risk. Git's object storage model means an attacker can reconstruct the entire repository — including every file in every commit, every config entry, every environment variable ever committed, every secret deleted from the working tree but preserved in history.

The attack chain is straightforward. Tools like git-dumper automate the reconstruction from a single exposed .git/HEAD entry. The attacker starts with HEAD, follows refs to packed-refs, walks the object database, and rebuilds the working tree locally. This takes minutes.

What's at risk in a typical application repo:

• Database credentials in config/database.yml or .env
• API keys and service tokens in deployment scripts
• Private keys committed "temporarily" in 2019 and never properly rotated
• Internal hostnames, infrastructure topology, internal API endpoints
• Business logic and algorithms competitors shouldn't have

The misconfiguration is common because it happens by accident during deployment. Developers who deploy directly from a git checkout — instead of a build artefact — often deploy the .git/ directory alongside the application code. Nginx and Apache don't block directory traversal by default unless explicitly configured.

The fix is two lines of Nginx config:

Or for Apache, add to .htaccess:

Nikto found this in 4 seconds. A bug bounty hunter who discovers it in your production environment will find it in the same timeframe — and you won't know until a report lands.

The False Positive Story — Why It's Part of the Job

Nikto generated 2 false positive findings, and they're worth explaining rather than burying:

• Weblogic /%2e/ directory traversal probe — Nikto fires this check because Oracle WebLogic had a well-documented directory traversal vulnerability via URL-encoded %2e sequences. Our target was a Python SimpleHTTP server. Not applicable.
• PHP info disclosure (/?=PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C10000) — Nikto probes for a PHP internal ID that triggers the info disclosure page on misconfigured PHP installations. Our server doesn't run PHP. Not applicable.

These are not Nikto failures. Nikto is a breadth scanner: it fires many technology-specific probes and returns everything that responds. The analyst — or in SecurityClaw's case, the AI orchestration layer — handles the filtering. Nikto correctly identifies that these endpoints respond; it takes stack awareness to know the response doesn't represent a real vulnerability.

SecurityClaw's AI layer resolves this by correlating the detected server technology against the probe type. A Weblogic traversal check against a Python server is immediately flagged as not applicable before it reaches the final report. This is the value of the AI layer: Nikto's recall is high, the AI layer's precision closes the gap.

SecurityClaw AI Layer — What It Adds

The Nikto run surfaces raw findings. The AI layer converts them into actionable intelligence:

• Stack-aware FP filtering — Identifies server type from HTTP headers and filters probes that don't apply to the detected stack.
• Severity prioritisation — The .git/HEAD finding gets escalated above the missing-header findings. Not all HIGH findings are equally urgent in context.
• Cross-tool correlation — If TruffleHog has already run on the same campaign target and found no secrets, the AI layer notes that the exposed git history was scanned and was clean. If TruffleHog found a secret, the AI layer connects "git history exposed via HTTP" to "same git history contains a leaked AWS key" — and that's now a critical finding, not a medium.
• Remediation specificity — Rather than "fix the header," the AI layer generates deployment-specific guidance: Nginx config block, Apache directive, or framework-specific middleware call depending on what it's detected.

Real-World Context: Why Nikto Still Matters in 2026

Nikto has been around since 2000. It's not stealthy, it's not subtle, and it won't win any awards for precision. It fires a fixed database of checks and returns everything that responds. In an era of sophisticated active recon tools, it might seem dated.

It isn't. Here's why:

It's fast. 4 seconds for a full server audit. That means it runs on every deployment without slowing your pipeline. If you're only running web security scans quarterly, you're not running them often enough.

The misconfigurations it catches are real. Backup files, debug endpoints, exposed git repos, missing security headers — these are in production environments right now. They're not hypothetical. They appear in bug bounty programmes at an embarrassingly consistent rate.

It catches what humans forget. Nobody remembers to check for backup.zip on every deploy. Nikto does. Nobody audits for server-status exposure in the deployment checklist. Nikto does.

For security practitioners building their first automated scanning pipeline, The Web Application Hacker's Handbook remains the definitive reference on the web misconfiguration attack surface — covering how attackers locate and exploit the exact class of findings Nikto surfaces here. Black Hat Python (2nd Edition) complements it with hands-on exploit development for Python-based targets specifically.

What to Run on Your Own Server

Before your next deployment, run this from your staging environment:

If you don't have Nikto installed: sudo apt install nikto on Debian-based systems, or brew install nikto on macOS. It ships with Kali Linux by default.

What to look for immediately:

• Any response from /.git/HEAD — this is critical, fix immediately
• Backup files (backup.zip, *.bak, *.old) — delete or block access
• Debug/test files (test.php, phpinfo.php, debug.html) — should never be in production
• Missing security headers — X-Frame-Options, X-Content-Type-Options, Strict-Transport-Security are table stakes

SecurityClaw runs Nikto as part of a broader campaign — alongside TruffleHog for secrets, npm-audit for supply chain, and manual AI analysis. Individual tools give you point-in-time snapshots. The campaign layer gives you a continuously updated security picture.

Run SecurityClaw on Your Infrastructure

See what SecurityClaw is building — and follow the demo series as we publish results across the tool suite:

Learn about SecurityClaw →

SecurityClaw is in active development. The demos section documents real campaign results as the platform matures.