gobuster "Error: the server returned a wildcard response" on authorized target

TL;DR

The app answers every path with the same page, so gobuster cannot distinguish hits from misses. Record the wildcard signature (status plus body length) with a manual request, then calibrate with --wildcard or exclude it explicitly with status and length filters.

Error: the server returned a wildcard response

Use this when

• Gobuster aborts with the wildcard response error.
• The target is a SPA or a server that serves the app shell for unknown paths.
• The engagement covers directory discovery on the target.

Not for this skill when

• Unknown paths return real 404s. You do not have a wildcard problem.
• The target is out of scope. Do not enumerate it.
• You want vhost or DNS discovery. Those are different gobuster modes with different fixes.

Steps

1. Request a random nonexistent path: curl -s -o /dev/null -w "%{http_code} %{size_download}" YOUR_TARGET_HOST/this-path-does-not-exist-12345. Verify: you have the wildcard signature (status + size).
2. Rerun with calibration: gobuster dir -u YOUR_TARGET_HOST -w /path/to/wordlist --wildcard. Verify: gobuster prints a calibration line and proceeds.
3. If auto-calibration misses, exclude explicitly: -b 200 for the wildcard status, plus length filtering on the wildcard size. Verify: results contain only real, differing responses.
4. Spot-check findings by fetching them manually. Verify: each reported path returns content distinct from the wildcard page.
5. If the app wildcards everything including sizes, switch to content-based filtering in ffuf (-fs on the wildcard size). Verify: findings shrink to genuine pages.

Variant phrasings

gobuster wildcard response error

Compact phrasing.

gobuster server returned wildcard

Alternate wording.

gobuster dir wildcard calibration

The fix-oriented search.

Compatibility: gobuster v3.x. --wildcard auto-calibration exists in recent builds; older ones need manual -b/length exclusion.

Why it happens

Single-page apps and catch-all server configs return HTTP 200 with the app shell for any path. Gobuster's default logic treats any 200 as a hit, so without calibration every guess "succeeds" and the run is meaningless.

Edge cases / pitfalls

• Wildcard status can differ from 200 (some apps 302 everything to login). Calibrate against the actual signature, not an assumed 200.
• Calibrating once at scan start is not enough if the app's wildcard page changes (A/B tests, rotating banners). Re-check on long runs.
• Excluding by size alone can hide real pages that coincidentally match the wildcard size. Combine status, size, and spot checks.
• Document the wildcard signature in your notes; the client should know their 404 handling leaks no information either way.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstlUY5Xaytvn9WOM_oGdvTA