## 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.

```text
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/pst_lUY5X_aytvn9WOM_oGdvTA